Code size (scalable operating system)

From 8 Kbyte (depending on required functionality)

RAM size

Data areas can be configured individually and contain dynamically created system objects; the minimum RAM memory needed by EUROS is 1 Kbyte

Microkernel architecture

Each basic as well as each additional system component provided by EUROS always requires recurring internal function, e.g. allocation and return of data blocks, chaining and unchaining of elements in queues, establishing of specific control structures for the different system objects, indexing and search services, etc. In order to avoid the multiple implementations of those functions in every single software component of EUROS, they are provided for use within the EUROS Microkernel just ones. This type of methodology is also referred to as “microkernel architecture”.

Object Orientation

The presence of multiple execution paths in the main memory referred to as “multitasking“ leads to an additional complexity while trying to coordinate and synchronize the execution of the tasks. Obviously, this must be one of the basic obligations of a RTOS since standard microcontroller in general does not provide mechanisms for solving of those problems. During the evolving of the real-time operating systems several mechanisms like mailboxes, semaphores, event flags, pipes, signals, etc. were established. Since in a multitasking environment all those mechanisms need to be reentrant within EUROS, it was decided to encapsulate them as objects – referred to also as “system objects”. Each system object consists of a tailor-made data control structure and set of specific services managing the usage of both the data structure itself and its dynamic payloads. The entirety of all implemented specific services constitutes the Application Programming Interface (API) of EUROS.
The notion of the object orientation was subsequently extended to all participants in the real-time process like tasks, device drivers, interrupt handlers, etc.

Principle of Locality

All system objects of the same type are stored in a distinguished system memory pool allocated during the system initialization time and taking into consideration their size and number. This approach eliminates both the internal and external memory fragmentation, while allocating a block for storing an object. In addition, this organization eliminates the need of a dynamic memory allocation using e.g. library function like maloc, which slows down the system responsiveness at runtime. The fact that object memory pools are instantiated during system initialization does not mean that individual objects have to be created at the same time. On the contrary, EUROS system objects can be created and deleted also dynamically but all this happens without using dynamic memory allocation, since blocks have been already allocated from an existing memory area. In addition, this organization introduces a clear structuring of the system objects and facilitates to the great extend the debugging of the system.

Cluster Approach

Conventional real-time operating systems manage their system objects individually. Consequently, the latter can be accessed only via a single system call, which leads in the majority of cases to an additional task context switch, a process, which inevitably “steals” costly execution time from the application. A unique concept, first implemented in EUROS, provides a hierarchical organization for the system objects. They can be optionally grouped together in so called “clusters", which corresponds to the structure of a hierarchical file management system, with the difference that a cluster directory not only takes over the role of a management structure (as in the case of a file directory), but is itself a self-contained system object. Thus individual objects or entire clusters can be created transparently by using a single system call. This significantly reduces the number of the eventual task context switches, and enhances the real-time parameters of the entire system. If necessary, a single object can be converted at run-time to a directory of a cluster. Each object in a cluster structure (similar to a file in a hierarchical file management system) can be reached by its unique pathname.

Flexible Interrupt Processing

Conventional interrupt handler routines - also referred as Interrupt Service Routines (ISR) - are statically generated as a parameterless function at the compile time. During the system initialization they are attached to the corresponding interrupt vector. It is obvious, that at the time of the invocation of the interrupt service routine, the current system environment is totally unknown to it. However, it is very desirable to have a defined system environment immediately after the interrupt has been acknowledged, since all problems related to the reentrancy can be elegantly solved. The EUROS answer to this challenge is to supplement the ISRs with a parameter, which can provide e.g. an address to a buffer, where the received data can be transferred. The introduction of an interrupt proxy – referred to as interrupt prolog -, placed in front of the actual interrupt handler provides the desired run-time parameters for it.
Each time after an interrupt invocation, the prolog is executed first and it sets the desired environment of the interrupt handler. The interrupt handler is then called from the prolog as a normal function which receives the submitted parameters and accesses an already known and save environment.
EUROS allocates memory for the prolog code and ensures that this memory is utilized after the interrupt prolog is no longer used. For all the involved actions system services are provided.
Special form of interrupt processing is offered to the user by the so-called software watchdog services. Watchdogs are logical system objects which are joined with a clock pulse. These can be used in manifold ways in order to realize software monitoring.

System States

In order to optimize the response time and to provide transparency for the entire process of interrupt and exception handling EUROS defines a state machine consisting of following four system states - Interrupt (I), Nested Interrupt (N), System (S) and Application (A). In addition, all possible transitions between them are implemented as system services as a part of the EUROS API. The introduced system states within EUROS are shown in the following figure, where the collective state X represents either one of the states N, S or A:


                                                                    EUROS internal states and interrupt handling


The system states differ not only in the amount of context information that is to be handled, but they also offer a trade-off between the performance and the scope of available services. They also provide an environment that enables kernel-specific services to be invoked in a safe way within the scope of the respective state. There are six possible state transitions functions, which are to be used when switching between the system states.

Dynamic linking and loading of applications

Usually the linking of an embedded application with the system software is done at compile time. The final application – containing the system software and the application code - is then loaded as a whole into the memory. In such a scenario the need to change the current application or even to load an additional one ends with the relaunching of the whole development cycle.
A version of EUROS implements a technique referred to as Dynamic Linking and Loading, which allows for applications to be loaded at run-time. In other words, EUROS provides a mechanism to link an application with all needed system components at load time. As an example, the present application may be stored in flash memory and the user may choose to extend the functionality of the current system just by loading of an additional application a run-time. A special program loader is involved, which also resolves all external references.


Special versions of EUROS RTOS called EUROSmp and EUROSmpi support multiple microcontrollers on a single hardware platform or in a network.

EUROSmp is an adaptable multi-processor RTOS that can be used in several modes: tightly coupled, distributed, and mixed (tightly-coupled plus distributed).

Read More »

EUROSmpi provides services that facilitate the implementation of applications for distributed systems.

Read More »