RTAI

from Wikipedia, the free encyclopedia

RTAI ( R eal T ime A pplication I nterface) is an extension of Linux to a realtime operating system . RTAI was designed by Paolo Mantegazza from Dipartimento di Ingegneria Aerospaziale at the Technical University of Milan . Right from the start, RTAI was further developed as an open source project by a larger community of developers. Today, in addition to Mantegazza, who continues to work as a coordinator, Philippe Gerum in particular is a very active employee.

There are now a number of diverse related or collaborative projects such as RTnet (a real-time network protocol) and Linux Trace Toolkit .

A big plus point of RTAI is that with the LXRT variant it is possible to run hard realtime tasks in user space and thus to use the protective mechanisms of Linux. This is done without major losses in terms of latency and without great overhead . In other real-time systems that run exclusively in the kernel space , an error in the program flow can have devastating effects.

RTAI is used by a large number of developers in many countries as the basis for their developments in the real-time area, but just like RTLinux, it naturally has no direct significance for the standard office desktop computer user.

architecture

RTAI Linux is based on a normal Linux kernel, which is expanded with the RTAI patch (Realtime Application Interface). As can be seen in the figure, the patch inserts a real-time kernel between the hardware (processor) and the Linux kernel. This takes over the interrupt management of the processor. This means that software on the kernel level can no longer block or release interrupts. RTAI replaces the commands cli () and sti () used for this with macros and is thus able to interrupt the kernel code.

RTAI architecture

The Linux kernel itself is also a real-time task. However, it has the lowest priority (idle task) and is only executed when the real-time tasks have nothing to do. After running a real-time task, all registers are restored so that the kernel does not notice the interruption.

Realtime Hardware Abstraction Layer RTHAL

In order that deterministic interrupt latencies can be achieved, the interrupt management must be transferred to RTAI. The rerouting of the interrupt control is realized with the help of the Realtime Hardware Abstraction Layer (RTHAL). RTHAL is integrated into the source code of the Linux kernel with the RTAI patch.

The following figure shows the possible communication paths within a modified kernel. In case A, the abstraction is transparent, i.e. the interrupt control is still with the Linux kernel, which corresponds to the use of a standard kernel. At B, direct control over the interrupts is withdrawn from the Linux kernel and assigned to real-time expansion.

RTAI architecture

RTAI works autonomously from Linux on the hardware. Intercepted interrupts are also passed on to RTHAL so that the kernel can react accordingly. RTAI is implemented through various kernel modules. As long as these modules are not loaded, the Linux kernel retains interrupt control (case A). The direct interrupt control is only transferred to RTAI when the RTAI modules are loaded (case B). In this way, the real-time extension can be added to the kernel and removed again at will during runtime. Thanks to this modular structure, sources of error can be isolated more easily. For example, if an RTAI system works incorrectly, you can simply remove the RTAI modules to test whether the problem is with Linux or RTAI.

RTHAL essentially consists of a structure of function pointers which point to the interrupt handling functions of the Linux kernel when the system is started. When loading the RTAI modules, the function pointers are redirected to RTAI internal functions. In this way, RTAI takes over the interrupt control without the Linux kernel noticing anything. After removing the RTAI modules, the pointers of the rthal structure point back to the standard kernel functions.

Interrupt handling

When RTAI takes over the interrupt control, interrupt-specific function calls of the Linux kernel are redirected to RTAI internal functions with the help of RTHAL. For example, RTAI implements a replacement for the function pair sti()and cli(). These RTAI functions set flags in RTAI internal data structures to record whether Linux wants to be informed about incoming interrupts ( sti) or not ( cli). This ensures that the kernel cannot cli()deactivate any interrupts using the function . RTAI forwards the sti()interrupts requested with the function to the Linux kernel after the real-time interrupt handler has been executed.

The following figure uses a flow chart to show how an incoming interrupt is processed by RTAI. First, the RTAI dispatcher checks whether a real-time application has registered a handler for this interrupt. If appropriate interrupt handlers are available, these are executed.

Interrupt handling

Then RTAI uses the internal data structures to check whether the Linux kernel has also activated the interrupt with sti (). If the test result is positive, the Linux dispatcher is started and the processing of the interrupt is initiated on the kernel level. If the Linux kernel has not activated the relevant interrupt, RTAI immediately leaves the interrupt context and executes the interrupted program again.

Scheduler

RTAI supports three different scheduling variants. These are specialized either for use on uni- or on multiprocessor systems. All schedulers can be operated in the so-called oneshot or periodic mode. The various schedulers are implemented in the modules rtai_sched_up.ko, rtai_sched_smp.koand rtai_sched_mup.ko. The corresponding scheduler module is inserted into the kernel with insmod after the RTAI module rtai_hal.ko.

Uni-Processor Scheduler (UP)

This scheduler is intended for single-processor platforms that use the 8254 as a timer. The structure of the scheduler is quite simple. It essentially consists of several lists with different priorities, which it processes linearly. The task with the highest priority receives access to the CPU. The Linux kernel itself is also a real-time task, but with the lowest priority.

SMP scheduler (SMP)

The SMP (Symmetric Multiprocessing) scheduler is intended for multiprocessor systems that are either 8254 or APIC based. The APIC is the so-called Advanced Programmable Interrupt Controller in multiprocessor systems. Among other things, this has the task of assigning the occurring interrupts to the individual CPUs. Tasks can be linked to a CPU or run symmetrically on a cluster of CPUs. The scheduler can also be used on systems that only have one processor, but whose kernel was compiled with the SMP option.

Multi-Uni Processor Scheduler (MUP)

As the name suggests, this scheduler sees a multiprocessor system as a collection of several individual processors. This has the advantage that, in contrast to the SMP scheduler, each processor can program its timers independently of the others. So the periodic and oneshot mode timer modes can be different depending on the CPU.

timer

The execution of real-time tasks in RTAI is timer-controlled. RTAI offers the choice between the two timer modes Periodic and Oneshot mode. Periodic means that the timer triggers an interrupt at regular intervals, which initiates a rescheduling. This is in contrast to the oneshot method. The timer is programmed in such a way that it triggers exactly one interrupt after a defined period of time, which calls the scheduler. To generate another interrupt, the timer must be reprogrammed, which means more effort than with the periodic procedure. However, intervals of different lengths are possible after which a rescheduling can take place.

A mode must be selected when the program is initialized. This is done by calling one of the following two functions:

  • rt_set_periodic_mode() The timer runs in periodic mode.
  • rt_set_oneshot_mode() Timer runs in oneshot mode.

Intertask communication

For communication and synchronization between real-time tasks in the kernel space, RTAI provides the usual mechanisms for a real-time operating system. These are implemented in the kernel modules of the scheduler:

  • Mailboxes
  • Semaphore
  • Messages and remote procedure calls

Mailboxes

Asynchronous inter-process communication is possible with the help of mailboxes. A task can asynchronously send messages to another task's mailbox. When the recipient is ready to process the received messages, he can get them from the mailbox. In this case the mailbox works like a FIFO (first in first out), the functionality of which is completely decoupled from the respective task and does not require any synchronization mechanisms.

Here are the most important RTAI functions for working with mailboxes:

  • rt_mbx_init() Initializes a mailbox with a defined size.
  • rt_mbx_delete() Deletes the resources used by a mailbox.
  • rt_mbx_send() Sends a message of a defined size to the mailbox.
  • rt_mbx_receive() Receives a message of a specified size from a mailbox.

Semaphore

A semaphore is a type of key that a task needs, for example, to access a shared resource. If the semaphore has already been fetched by another task, the requesting task is put on hold until the current owner returns the semaphore. A semaphore contains a protected variable (binary or counting), which indicates the still free access to a resource. The tasks waiting for the semaphore are noted in a queue. If the semaphore is returned, the first task in the queue receives it.

The following functions are available for working with semaphores in RTAI:

  • rt_sem_init() Initializes a semaphore with a given value.
  • rt_sem_delete() Clears the given semaphore.
  • rt_sem_signal() Returns the semaphore.
  • rt_sem_wait() Waiting for a semaphore.

Communication with Linux processes

With FIFOs and shared memory, RTAI also provides two mechanisms that enable real-time tasks to communicate with normal Linux processes in user space.

FIFOs

A FIFO is a buffer memory that can be used to exchange data between an RTAI task and a normal Linux process in user space. Theoretically, a FIFO is bidirectional. In practice, however, only one direction is mostly used. Two FIFOs are used for the mutual exchange of data, one for sending commands and another for receiving the corresponding responses.

RTAI FIFO

Linux processes can access a FIFO like a normal file. Instead of a file, the function opens open()a special device node in the /devdirectory ( rtf0to rtf63). You can then use the functions read()and write()data to read and write. In the kernel space, the RTAI API provides the following functions for working with FIFOs for real-time tasks:

  • rtf_create () Creates a FIFO with a given size and number.
  • rtf_destroy () Deletes a FIFO.
  • rtf_reset () Clears the contents of a FIFO.
  • rtf_put () Writes data to the FIFO.
  • rtf_get () Reads data from the FIFO.
  • rtf_create_handler () Registers a handler that is executed when data is received.

Shared memory

As the name suggests, shared memory is a memory area shared by the Linux process and the RTAI task. Shared memory is mainly used when several Linux processes need access to the data of an RTAI task or a large amount of data has to be transferred from an RTAI task to a Linux process in a short time.

LXRT

In order to facilitate the development of real-time tasks, the LXRT module was introduced in RTAI. This module allows the development of real-time tasks in user space, with the option of accessing the RTAI API. This is a special feature that only exists in RTAI and can greatly simplify development, since errors in a user-space process usually do not affect the stability of the overall system. Errors in kernel modules can often lead to a crash of the entire system. In addition, in contrast to the kernel space, you can work with a normal debugger (for example GDB) in user space.

RTAI lab

The RTAI-Lab project expands Simulink and Scicos with a justification that allows real-time applications for RTAI to be graphically clicked together. It contains blocks for handling the techniques described above, such as intertask communication, or communication with Linux processes. In addition, analog and digital IO blocks are provided, with the help of which the real-time application can interact with the outside world. To do this, RTAI-Lab uses the drivers from the Comedi project, so all IO cards that are supported by Comedi are supported. From the model compiled in this way, C code is automatically generated, which can be compiled directly and started as a real-time task. A graphical user interface is provided for user interaction with this task, via which variables can be plotted but also changed.

Other solutions for real-time Linux

literature

  • Yaghmour, Karim: The Real-Time Application Interface , 2001 ( PDF )
  • Blattner, Jörg: Tough to take? Linux in real time , University of Zurich Winterthur 2005 ( PDF ( Memento from September 29, 2007 in the Internet Archive ))
  • Abbott, Doug: Linux for Embedded and Real-time Applications , Burlington (USA) 2003, Elsevier Science, ISBN 0-7506-7546-2
  • Düding, Dirk: A contribution to the use of real-time Linux variants in automation technology , dissertation, Dortmund 2003, University of Dortmund
  • Keller, Matthias: Investigation of approaches to CAN communication in real time under Linux , Bachelor thesis, TU Munich, 2006 ( PDF )
  • Bucher, Mannori, Netter: RTAI-Lab tutorial: Scilab, Comedi, and real-time control , 2008 ( PDF )

Web links