Performance example of ReaGOS


Ari Okkonen, OBP Research

Performance of  the ReaGOS real-time kernel is evaluated measuring the time it takes to pass a message back and forth between tasks of different priorities. Measured round-trip time is 12 µs in 75 MHz 80486, real mode. The test system is presented by the diagram used to configure the ReaGOS kernel and the full code of a measurement task. The total footprint of the test system is measured to include the setup and communication code required outside the OS. The footprint including the OS and the tasks is presented using excerpts of the linkage map. The system occupies 3.5 kB ROM, 202 B RAM not including C libraries and startup code.

Direct and indirect influences of RT-OS to system performance

The OS affects the system performance in two ways. First, the space occupied and the processor time spent by the OS itself are costs of using the OS. Second, the code in the tasks communicating with the OS uses the system resources, also. Depending on the design of the OS interface the responsibilites of the communication can be allocated several ways. A small and fast OS may require much code in the tasks, or a more comprehensive OS can support very lean tasks.

In this measurement the direct and indirect performance costs are summed together. The tasks do minimal operations in addition to communicating with the OS. The measured times include both OS and tasks, and the size of both tasks and the OS are summed together.

Test system

Annotated ReaGOS configuration diagram
Annotated configuration diagram of the test system

The test system consists of three tasks. Ask_count is a user interface. Tasks ping and pong are two cross connected instances of the same  program pong.

The pong program receives the input value c_in. If it is zero, the signal done is sent. Otherwise the the value (c_in - 1) is sent through c_out.

Performance is measured by transmitting a large enough number from the ask_count and measuring the time until the signal even or odd is indicated by the ask_count. Count 2 000 000 takes 11.5 seconds, so, it is safe to say that a round trip takes 12 µs.

Pong task description

A task running in the ReaGOS consists of an instance data block and an event handler function. The ReaGOS takes care of the responsibilites of the traditional main loop of the task. This arrangement has some advantages in testability, reusability, and performance.

The interface and the instance data of the pong task class is defined in the file pong.h. The event handler of the pong task class is defined in the file pong.c.


/* pong.h - pong () - 2002-09-20  */

#ifndef pong_h
#define pong_h


/* Interface declarations */


/* Internal storage declarations */

/* none */

/* Subprocess declarations */

/* none */



/* pong.c - pong () - 2002-09-20  */

#include "reactime.h"
#include "pong.h"

process_body(pong) /* void pong_function(pong_data * p){... */

initialization /* executed only in the system initialization */

s(done); /* done, if input value == 0 */
} else {
R_send(c_out) = v(c_in)-1; /* decremented value is sent */




The following excerpt of the map file consists of the ReaGOS parts and the tasks of the test system. The system is compiled using Turbo C 2.01 for x86 architecture.

 Start  Stop   Length Name               Class

003E4H 00469H 00086H PRZMAIN_TEXT CODE allows usage with DOS
0046AH 005B6H 0014DH PC_CLOCK_TEXT CODE clock driver
005B7H 00F62H 009ACH SPEEDM_TEXT CODE pre-emptive scheduler
00F63H 010E8H 00186H ASKCOUNT_TEXT CODE UI task
010E9H 0119BH 000B3H PONG_TEXT CODE pong.c

Detailed map of segments


The system occupies 3.5 kB ROM, 202 B RAM not including C libraries and C startup code.

Supporting solutions

The ReaGOS is only one part of a set of solutions for embedded software development. The main charter of the ReaGOS is to introduce pre-emptive scheduling and interface to interrupt servers including timing.

Hierarchical non-pre-emptive scheduling

If there is no inherent differences in urgency between a set of tasks, they can be combined to one task by applying a non-pre-emptive scheduler generated by Reagenix Programmer. Non-pre-emptive scheduling introduces less overhead. Moreover, the resulting hierarchical task structure is easier to manage.

State machine coding for event handlers

State machines are a natural way to describe control, communication, and monitoring sequences. State machines can be automatically converted to event handlers by the Regenix Programmer. Actions of the state machines are written in C. So, the transitions are the right place to call functions for nontrivial data processing.

Interface compatibility

The Reagenix programmer produces modules that directly interface to ReaGOS. Besides, the modules can be interfaced to any OS in straightforward way using the Reagenix Interface Kit. This applies, of course, to any task written originally for ReaGOS.

Unit testing

Reagenix Unit Tester can be used to excercise the tasks in isolation. Reagenix Programmer can be used to combine several tasks to larger units to test cooperation in host environment. Due to nature of the event handler architecture, standard tools (Cantata, LDRA,...) can be used for regression testing.