RTEMS Timeline Tool

The main objective of the tool is to log the behaviour of an RTEMS application executing in a board or in a simulator. The data collected is then presented in a graphical mode , providing an easy way to observe the execution flow of the RTEMS system when running an RTEMS Application . This tool can help in the detection of eventual flaws as well as possible optimizations to the system by monitoring both temporal (e.g. which task is executing at a given point in time) and spatial changes (e.g. memory usage) in the system. The development of this tool arises from the fact that crucial systems (by example: space systems) present a high-level of criticality in consequence it is vital that the temporal behaviour of an RTEMS application is study in detail.

Some of the information that is monitored regards the:

  • Task execution flow;
  • System calls;
  • Software interrupts;
  • Hardware interrupts;
  • Memory usage;
  • CPU usage;

The RTEMS Timeline Tool was developed in such a way, that it can log all the moments that happen the following events (if they are selected to be monitored by the tool):

  • Schedulability analysis (Task execution flow);
  • RTEMS API calls (System calls);
  • Interrupt Generation (Hardware and Software interrupts);
  • Configuration Tables:
    • RTEMS Workspace address;
    • RTEMS Workspace size;
    • RTEMS Workspace free memory;
    • Heap size (given to libc);
  • Stack and Memory usage;

In particular, all the RTEMS API primitives can be monitored, including, for example:

  • rtems_semaphore_obtain;
  • rtems_semaphore_release;
  • rtems_semaphore_create;
  • rtems_semaphore_delete;
  • etc; 

or even,

  • rtems_task_create;
  • rtems_task_delete;
  • rtems_task_suspend;
  • rtems_task_wake_after;
  • rtems_task_wake_when;
  • etc;

It is also possible to monitor the interrupt occurrence and internal scheduling events , such as:

  • thread priority changes (due for example, to semaphore inherence/ceiling protocols);
  • thread insertion in the ready queue;
  • thread removal from the ready queue;
  • thread context switch;
  • thread begin;
  • etc;

Other context dependent parameters, such as:

  • thread maximum stack size;
  • dynamic memory allocation;

can also be monitored.