Timeline Tool

[Manuel Coutinho]

Hi

> -----Original Message-----
> From: Karl Krach [mailto:mailinglists at blueSpirit.la]
> Sent: Sunday, October 07, 2007 2:37 PM
> To: Manuel Coutinho
> Cc: RTEMS-Users Mailinglist
> Subject: Re: Timeline Tool
> 
> Hello Manuel!
> 
> I'm also working on a TT, but it's only for my company's special
> purpose. We won't publish it, because it only will work on SPARC with
> RTEMS version 4.6.5. Which version and which BSPs are you going to
> support? (E.g. imho logging of interrupts cannot be platform
> independent.) We also have to integrate the data transfer into our own
> protocol. At the moment, everything is configured by the CONFIGURE_XXX
> defines in the user application and will be integrated into RTEMS with
> patches.

We plan to make the timeline tool as most as possible hardware independent.
Our target platform is the SPARC CPU family (ERC32 and LEONs) so most of the
tests will be conducted in this architecture.
Our hope is to integrate the timeline tool into the RTEMS source code (so as
to make it version independent). We are currently using RTEMS 4.7.1 version.

> 
> Which sources do you plan to make public?
> 

We plan to make everything public. All the timeline tool sources will be
made available.

> Last question: Which release date do you aspire? Maybe I can integrate
> your protocol in my PC front end (windview like) for later use.
> 

We plan to release the timeline tool within a few months.

Perhaps you could share some information with us regarding your timeline
tool (e.g. the protocol you are using and other technical issues).

If you have any other questions, please feel free to address them.

Kind regards
Manuel Coutinho

> Regards,
> 
>    Karl Krach
> 
> 
> Manuel Coutinho wrote:
> >
> > Hi
> >
> > Edisoft is developing (among other things related with RTEMS) a timeline
> > tool. This tool is designed to log information from the RTEMS
> > application and send it over Ethernet or serial cable to a host computer
> > that displays it to the user.
> >
> > A similar tool is provided by RTEMS in the capture engine. The tool we
> > are developing gets some ideas from the capture engine but can trace
> > more events (e.g. schedulability events, interrupt generation, etc).
> >
> > This email describes our approach to implement the timeline tool inside
> > the RTEMS source code. We hope to receive comments from the RTEMS user
> > and developer community in order to proceed with the necessary RTEMS
> > changes and implement the timeline tool.
> >
> > We are thinking of allowing the user to select the TT (timeline tool) by
> > means of an option during the configuration phase of RTEMS. Example:
> >
> > build-rtems>../rtems471/configure \
> > --target=sparc-rtems              \
> > --enablebsp=erc32                 \
> > --enable-rctt                     \
> > --enable-networking               \
> > --disable-posix
> >
> >
> > This will enable some macros in the code that will trigger the logging
> > of information.
> >
> > Example:
> >
> > #ifdef TIMELINE_TOOL
> >  log(event);
> > #endif
> >
> > As illustrated in the Figure in attachment, if the user chooses not to
> > use the TT, the additional code is not compiled and only the original
> > RTEMS source code is present in the final executable. If the user
> > requires the TT, the additional code inside the RTEMS source tree is
> > compiled and the events are monitored by the TT.
> >
> >
> > The timeline tool requires some RTEMS objects (one task, an extension,
> > etc) and a device driver (Ethernet or serial cable). RTEMS needs to know
> > these requirements to allocate the necessary memory space and initialize
> > the drivers. The application needs to be modified when using the
> > timeline tool to include these resources using, in particular, the
> > confdefs.h file.
> >
> > This option requires several RTEMS changes to the kernel. In particular,
> > this implies modifications in almost all RTEMS Managers. These changes
> > can be sub-divided into the following categories:
> >
> > 1.    Initialization Manager - the initialization manager has to be
> > modified in order to initialize the timeline tool. Small changes are
> > required here.
> >
> > 2.    Extension Manager - although some scheduling events can be caught
> > by the RTEMS Extension Manager, there are some events that remain
> > unmonitored. Such events are the thread insertion/removal to/from the
> > ready queue and priority changes (due, for example, to internal
> > semaphore inherence/ceiling protocols). These events are fundamental for
> > a thorough schedulability analysis. The RTEMS Extension Manager can be
> > extended to monitor these additional events. In order not to create
> > compatibility issues with existent applications, the RTEMS Extension
> > Manager will not be changed (at least, in a near future). Instead, a new
> > functionality will be added, mostly through the addition of a new
> > function: rtems_extension_createX.
> >
> > 3.    Other Managers - to monitor the API calls we envisage the
> > modification of mostly all API primitives so as to log the time the call
> > was made. This will require modifications throughout the native RTEMS
> > API source code. To change the monitored API calls (for example, to
> > monitor the rate_monotonic_period but not monitor the
> > rate_monotonic_get_status), it is required a recompilation of the TT
> > code inside RTEMS.
> >
> > 4.    Apart from the RTEMS Managers modifications, the integration of
> > the TT will also require changes in the build procedure to include (or
> > not) the TT code and to configure it.
> >
> > 5.    Small changes to the RTEMS Super Core will also be needed in order
> > for the TT to catch the RTEMS interval events (such as thread
> > insertion/removal from ready queue and priority changes due to semaphore
> > inherence/ceiling protocols). The required modifications inside the
> > Super Core to catch the additional internal events are very sensitive
> > since this code is a critical path and must be optimized. If the
> > Extension Manager is changed and extended to monitor these new events,
> > then a temporal overhead is always introduced because an "if" function
> > is always performed at these critical steps. However, if the Extension
> > Manager is not changed but only incorporates the new functionality
> > (e.g., through a rtems_extension_createX function), then the code
> > remains optimized (an #ifdef directive is performed).
> >
> >
> > Regards
> >
> > Manuel Coutinho
> >
> > Edisoft
> >