RTEMS for Real-Time Executive for Multiprocessor Systems, is an open source RTOS (real time operating system) that supports the APIs like POSIX. The scope of the RTEMS is varied. It is mainly used in aerospace, automotive and industrial automation. Currently RTEMS supports 18 processors achitectures. The main architectures that RTEMS supports are :
- ARM,
- PowerPC,
- Intel,
- SPARC,
- RISC-V,
- MIPS,
- and more
RTEMS includes multiple file systems, symmetric multiprocessing (SMP), embedded shell, and dynamic loading as well as a high-performance, full-featured IPV4/IPV6 TCP/IP stack from FreeBSD which also provides RTEMS with USB.
IIn this article I will only talk about multiprocessing properties of RTEMS. I think this is a subject that deserves to be treated especially for an open-source and certified RTOS for critical applications.
Tasks Management, Scheduler manager…
The concurrent programming is a form of programming in which several functions are called concurrently during overlapping time periods instead of sequentially with one completing before the next start. It is the principe of RTOS. The responsibility of choosing which tasks will be executed at any given time by the available processors, and for how long, falls on the operating system and, in particular, on an operating system component known as scheduler. In a real-time operating system (RTOS), the scheduler works according to algorithms. Since tasks are first-class entities in any modern OS, RTEMS provides an extensive API for task management.
In almost every RTOS there are functions that allow to create and make eligible for execution a new task. These same functions could inspect and change the scheduling parameters that drive the OS’s scheduling algorithms. As for the most of RTOS, another set of RTEMS functions exists to inspect and modify the scheduling parameters of a task after its creation. Another function exist at top level to suspend, resume a task and terminate it. The most of RTEMS modules not directly accessible to end-user implement a variety of real-time scheduling algorithms.
Regarding the scheduler manager, the configuration is optional and only necessary in very specific circumstances. By default, RTEMS uses the Deterministic Priority Scheduler algorithm in uniprocessor configurations. In case SMP is enabled and the configured maximum processors “CONFIGURE_MAXIMUM_PROCESSORS” is greater than one, then the Earliest Deadline First SMP Scheduler is selected as the default scheduler algorithm.
POSIX and RTEMS classic API
RTEMS operating system offers two main APIs for many of its functions, including task management and timekeeping, called classic and POSIX API. These two APIs serve different yet overlapping purposes. The focus of the POSIX interface is compliance with the international standard ISO/IEC/IEEE 9945 to support portable application development.
The Classic API aims to provide rich, expressive features useful to tailored real-time applications designed specifically to work with RTEMS. In addition, allows to access to OS features. Thus, application developers ought to choose between portability and expressiveness in deciding which API to use. The primary goal of TROS interface standardization efforts is to facilitate portable development by defining the function level interfaces and the behavior of a compliant implementation. An application that uses the interface correctly can be assured of proper execution in a RTOS with a standard compliant implementation. As shown in figure below, in RTEMS most of the implementation of RTOS services to satisfy these APIs is shared in an internal subsystem called the SuperCore located at cpukit/score in the RTEMS source code tree.
Multiprocessors and Multicores
As increases of clock speed and improvement of instruction execution strategy got closer to their limit, more than 20 years ago processor designers moved in another direction, that is, they started ti integrate multiple processors, all connected to a common memory bus, in the system. This gave rise to multiprocessors which further evolved into multicore processors. As its name says, a multicore processor embeds multiple execution cores, or just cores for short, in the same chip. Like in multiprocessors, all cores still have uniform access to a common shared memory. From the hardware design point of view, this poses significant challenges that are outside the scope of this book and will be only shortly summarized in this section, mainly focusing on the effects some of them have on software design and development.
RTEMS addresses these issues by providing simple and flexible real-time multiprocessing capabilities. The executive easily lends itself to both tightly-coupled and loosely-coupled configurations of the target system hardware. In addition, RTEMS supports systems composed of both homogeneous and heterogeneous mixtures of processors and target boards.
A major design goal of the RTEMS executive was to transcend the physical boundaries of the target hardware configuration. This goal is achieved by presenting the application software with a logical view of the target system where the boundaries between processor nodes are transparent. As a result, the application developer may designate objects such as tasks, queues, events, signals, semaphores, and memory blocks as global objects. These global objects may then be accessed by any task regardless of the physical location of the object and the accessing task. RTEMS automatically determines that the object being accessed resides on another processor and performs the actions required to access the desired object. Simply stated, RTEMS allows the entire system, both hardware and software, to be viewed logically as a single system
Multicore Scheduling Algorithms in RTEMS
Whe RTEMS is configured to run on a symmetric multiprocessor (SMP) or multicore system, several scheduling algorithms suitable for this kinf of system become available. By default, RTEMS works according to the global scheduling approach and puts all available cores under the control of a single scheduler instance, whose shceduling algorithm is specified in the configuration up to a maximum of 32 cores. However users can instruct the OS to use clustered scheduling instead, by explicitly instantiating all the scheduler instances they need in the application compile-time configuration. Partioned shceduling is supported as a special case of clustered scheduling in which each scheduler instance is in charge of exactly one core.
Conclusion
In this article, I wanted to present RTEMS real-time operating system especially with its multicore & multiprocessor aspects. RTEMS is a popular and open-source RTOS and mostly used in the domains: Aerospace, Automotive and Industrial automation. So using RTEMS becomes essential in the areas in which computing power and determinism are the critical parameters. There are also another RTOS that could be used such as proprietary RTOS VxWorks but RTEMS is the preferred RTOS by many developpers by its ease of use.