EUROS doesn´t have a monolithic structure, but is rather built on the principle of modularity. This approach facilitates the implementation of custom-tailored system software configurations by omitting or adding of adequate modules. The core components of EUROS are the Microkernel operating on the Microcontroller Abstraction Layer (MCAL) complemented by the Input/Output (I/O) System. Additional basic components are the Process Manager containing the implemented communication and synchronization services and the C/C++ Library providing the basic POSIX interface. Building on top of those basic components EUROS can be extended by a large number of additional system components, thus creating a powerful real-time operating platform.

Microcontroller Abstraction Layer

The Microcontroller Abstraction Layer (MCAL) is a very basic component in EUROS RTOS, which implements a generic interface to facilitate the interaction between the real-time operating system as a whole and the underlying hardware, thus fostering its portability. The main purpose of this layer is to encapsulate all hardware specific details and make sure that EUROS RTOS has access to a unified set of functions regardless of the type of the target microcontroller.

As the component closest to the underlying hardware, the MCAL is consequently strictly hardware dependent. The functionality of the MCAL component can be classified into two groups:

Microcontroller Core

Abstraction of the hardware specific CPU features:

  • Clock unit
  • Power Unit
  • Trap/Exception
  • Prolog
  • Programmable Interrupt Controller
  • Cashing
  • MMU/MPU interface
  • Encryption unit
  • General Purpose Timer (GPT)
  • Watchdog
  • 64bit arithmetic


Abstraction of the hardware specific features related to the included peripherals like used memories, I/O’s and communication controllers:

  • Flash memory
  • Digital I/O
  • Analog Digital Converter
  • Digital Analog Converter
  • Timer Unit
  • UART
  • SPI
  • I2C
  • CAN
  • USB
  • Ethernet

This classification suggests that some parts of the MCAL can be reused and there are parts, which are strictly specific to a given hardware platform.

It should be noted that it is not always possible to draw an exact distinction line between “family specific” and “target specific” features. For example some microcontroller derivate can offer a special instruction set extensions for 64bit arithmetic that may not be present in other chips of the same family.

It should also be noted that the MCAL abstraction layer does not include the so called “startup code”. The motivation behind this is that startup code usually performs initialization steps that are specific for a given target board and are not generic to the entire microcontroller family. Therefore the startup code itself is part of the EUROS board support package and not of the hardware abstraction layer.


The Microkernel component, which always must be part of a specific system configuration, can be also the only component of the system software, because it provides all needed routines providing basic real-time functionalities. Those include services for interfacing of the MCAL, interrupt state transitions, services for interrupt handler management, timer services, software watchdog services, object management services, scheduler services and tasks control services. Furthermore, the major set of services provided by the Microkernel is also utilized by the remaining EUROS software components if included in a configuration.

The Microkernel is responsible for providing a generic interface to those parts of the underlying hardware used directly by it, however, it does not control the respective hardware components directly, but through a tailor-made MCAL, which as a separate component encapsulates all hardware-specific functionalities.

Since the task management and scheduling are part of the Microkernel, it provides the necessary minimum for an application built on it to run. Those services are complemented by the additional ones like system memory management and basic inter-process communication.

Input-/Output System

The Input/Output System (I/O System) implements a driver interface for complex devices used for handling of managed I/O requests for all device drivers classes in a uniform way including data buffering, execution initiation, completion of the I/O request, eventual time-out handling, status evaluation and notification of the commissioning task after the termination of the request.

The device driver interface is based on the so-called “peripheral-controller-concept” introduced in order to systematize the diversity of the available peripheral components and thus essentially to simplify the implementation and maintenance of device drivers as a whole. An available application can be easily ported to different microcontroller architecture as a part of a more advanced technological level in one single step, simply through a re-compilation.

In addition, the I/O-System uses the services provided by the MCAL for the respective specific peripheral chip.

Process Manager

The Process Manager contains a set of system services used primarily for the inter-task communication, -coordination, -synchronization and for memory management of the application. Signal, event-flag, mailbox, pipeline and semaphore system objects are provided for inter-task interactions.

Regarding the memory management, an application can choose among memory structures like mega-pools, memory pools and fixed-size buffers, which will best suit the application’s need.

ANSI C/C++ Library

The C/C++ library complies with the ANSI-C standard and is built as reentrant. It is installed once in a system and can be used by all tasks simultaneously. The C/C++ stream functions allow access to device drivers and to the file system. The C/C++ library also allows the stream functions to interface also other system components.

Additional components

The EUROS core functionality can be extended by a big variety of available file systems, protocol stacks, graphics libraries, middleware and more.

Learn more