Capture Engine GUI - Was: WikiWish

Pavel Pisa ppisa4lists at pikron.com
Fri Jul 14 07:13:01 UTC 2006


On Friday 14 July 2006 05:22, Chris Johns wrote:
> This is my fault. I never really made a public announcement about the
> Capture Engine. You are not the first person to have made this statement.
>
> I suppose I considered it a work in progress which it is. The Capture
> engine filters are designed for a GUI and a GUI needs a TCP interface.
> The design should allow a filtered system to be monitored without the
> trace engine generating too any events that the system becomes unstable.
> Added to this I see a need to extend what is captured in the kernel. We
> need to be able to see other kernel calls. This is a little more complex
> as a new API needs to be added to RTEMS that does not change the current
> performance.
>
> With a remote capture system logging real time data I hope we can
> attract research for post processing type tools.

Hello Chris,

some way to transfer trace data out of the system would
be extremely great. I have already that on my infinite
ideas/projects list.

There is interesting free tool from UPV which does
that for RTLinux. It could be adapted for RTEMS.

http://rtportal.upv.es/apps/rtga/
http://rtportal.upv.es/apps/rtga/rtga/

There has been developed even POSIX standard
compliant TRACE implementation in the frame
of the OCERA project

http://rtportal.upv.es/apps/trace/

May it be, that part of it could be reusable
for RTEMS.

There is group of people working on scheduling
toolbox for Matlab TORSCHE at our university department
(address bellow) as well. It provides tools for
off-line schedulability analysis, verification
and schedulers design. It would be great if the design
can be done in TORSCHE and results of the real
system run could be viewed in its viewer.

http://rtime.felk.cvut.cz/scheduling-toolbox/

This tool has already been successfully used
for optimization of some real world problems to divide
and order some DSP like computation steps between
more hardware computation units (in the FPGA) to
achieve highest throughput. The static scheduling
of tasks for MP RTEMS system comes to the mind there.

I do not expect, that you have time to work
on this now but I want to archive these ideas
and pointers for possible future reuse.

If work on integration could smelt by some computer/scheduling
science like notion and problems or could be used for
some real world reputable applications, may it be
that our department bosses would allow to invest
some of my colleagues project funded time to the
cooperation on integration. But it is like fighting
with wind mills to argue with them what should be
done to prepare benches and environments for future
applications in many cases.

Best wishes

                Pavel

                Pavel Pisa
        e-mail: pisa at cmp.felk.cvut.cz
        www:    http://cmp.felk.cvut.cz/~pisa

                Czech Technical University
                Faculty of Electrical Engineering
                Department of Control Engineering
                http://dce.felk.cvut.cz/



More information about the users mailing list