Timeline Tool

[Karl Krach]

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.

Which sources do you plan to make public?

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

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
>