No subject

[Manuel Coutinho]

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20071004/41d92c71/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic.JPG
Type: image/jpeg
Size: 38850 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20071004/41d92c71/attachment.jpe>