Capture Engine GUI - Was: WikiWish

[Chris Johns]

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

The code to do this has been on my list since I did the initial commit. 
To me a remote interface is what is needed to get wider acceptance and 
usage. Further the filters and triggers can be complex to setup and a 
GUI would really help. The most basic thing it would add is a save.

A remote interface requires a TCP server interface which is not too 
hard, but it opens a complex issue relating to memory usage in the 
capture engine that has been documented in PR959:

  http://www.rtems.org/cgi-bin/gnatsweb.pl?cmd=view&pr=959

I will update the PR once we move to bugzilla with reason and solution.

> 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.
> 

Thanks.

> 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.

Nice. This is what I had in mind.

I see the host TCP protocol interface initially being written in a 
portable scripting type language. For example Python, or whatever (lets 
please not start a thread on the best language just yet). We can add 
more code to write to a file, fill a database, import into another 
system, develop a GUI over time as resources or support comes along.

Could we import data into this system if captured to disk ?

> 
> 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.
> 

I have some time but also have other RTEMS work in progress which is 
more important to me at the moment. If users would like to see me work 
on this please let Joel or I know. We would welcome support to see this 
code develop.

> 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.

I agree with you on this. The capture engine is a start but needs to 
grow as users see the benefit and demand more features. There has been a 
few times I taken a look at a trace to see basic task coding bugs 
causing tasks to do things I did not expect.

Regards
Chris