EUROS RTOS

TECHNICAL CHARACTERISTICS

Overview

Technical Characteristics

Functional Features

Benefits

Supported Architectures

Downloads

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.

Multiprocessing

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).

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

The object-oriented design of the operating system enables the transparent use of all system services, without regard to the distribution and number of system objects and microcontrollers.
The following multiprocessing modes are available under EUROSmp:

• Tightly Coupled Multiprocessing
In this arrangement, several microcontrollers enable parallel execution of multiple processes or tasks. This operating mode is characterized by maximum flexibility. It ensures a balanced load for the microcontrollers. Both code and data must be stored in a global memory area to which all microcontrollers have access. The power of the tightly coupled computer may be increased by adding microcontrollers. However, there is a penalty because the bus load increases due to use of the bus for accessing the global data. This leads in turn to a reduction of the system throughput. The gains and losses must be analyzed carefully when adding microcontrollers.

• Loosely Coupled Multiprocessing
Loosely coupled multiprocessing systems avoid the bus-usage drawbacks of tightly coupled systems. They use several autonomous microprocessors; information is exchanged via a shared memory or a network system. This configuration has a significant advantage in that each portion of the overall task is allocated to a specific functional unit. A message-passing mechanism is a simple and direct way to exchange data.
In loosely coupled multiprocessor systems it is generally not feasible to balance the workload for the microprocessors. However, with careful design and careful distribution of the tasks, this shortcoming can be mitigated.

• Mixed Multiprocessing
The mixed multiprocessing feature was introduced in order to avoid the drawbacks caused by tightly coupled configurations, while retaining the flexibility of loosely coupled multipro-cessing. The realization of this operating mode is possible only because of the object-oriented design of the operating system.
The basic idea of the mixed approach is to use the system objects to avoid excessive bus usage while at the same time avoiding starvation of some microprocessors because of the excessive use of some other microprocessors. This is done by careful deployment of the various objects. For example, only objects that are involved in high-level activities should be placed in global memory, so that they can be executed by all microprocessors. In contrast, tasks and drivers that control peripheral devices will be placed in a local memory area. This guarantees faster execution because the global bus is not used.
Under the EUROS mixed multiprocessing system, the management of system objects and the use of system services are both completely transparent to the application. This is an important consequence of the object-oriented design and implementation of the system.

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

The goal of a distributed system is the parallelization of program execution, in order to achieve shorter run times. In order for multiple processors to execute in parallel, communication and synchronization mechanisms are necessary. The EUROSmpi interface implements the services of the MPI 1.1 standard (MPI: Message Passing Interface), but not to the full extent.
The EUROSmpi interface can be roughly divided into the following functional categories:

• Initialization services
• Services to send and receive messages
• Services for synchronization, for example waiting for the arrival of messages
• Services for status queries

The allocation of the computer nodes can take different shapes. By definition, there are two basic types of distributed systems:

1. Homogeneous Systems.
Microcontrollers of the same architecture, usually tighty coupled, such as multiple processors in a parallel computer, which are connected by a special communication bus.

2. Heterogeneous systems.
Microcontrollers of arbitrary architecture, usually loosely coupled and distributed spatially, such as computer systems that communicate over an Ethernet line.

EUROSmpi is designed for both types, since it is not linked to a specific protocol or to a particular communication medium. Irrespective of whether the system is homogeneous or heterogeneous, the user merely provides the communication medium, which will take care of the transmission of messages through the network. This medium is hereinafter referred to as the transmission handler. All computer nodes that use EUROSmpi in a heterogeneous system must support compatible sematic specifications in order to ensure proper communication and handling of the messages passed.

EUROSmpi requires some precautions to ensure proper communication in heterogeneous systems:

• Conversion of the messages into a hardware-independent format in order to facilitate the data exchange between Little and Big Endian systems and between architectures with different word length.

• Conversion of the elements in MPI messages to a compiler-independent format.
These characteristics turn EUROSmpi into a powerful, unified basis for the development of distributed EUROS-based applications.

Hardware requirements:
• Ethernet controller in order to communicate with external media.
• At least 30 kB ROM.
• At least 3 kB RAM including at least 3 kB per node (more exact memory requirements depend on the dimensions of the MPI buffer allocated during the initialization).