Real Time Application Interface (RTAI) Zubair Ahmad - Ilhan Akbas

Content OS Requirements Linux Kernel Core RTAI Description LXRT Future Directions

OS Requirements Software components relying on a platform offering both real time support and "standard" general purpose API The Platform needs a real-time executive and a comprehensive OS The Linux OS exports the same application service level but suffers from a lack of real time support. Some options:  Native real time support in Linux  Linux Modifications for real time constraints (KURT): no outstanding background.  Linux and real time sharing resources ( L4Linux) : experimental project.  Linux as a task of a real time executive: RTLinux, RTAI, eCos, Nucleus.

Real time support in Linux Linux has support for the POSIX real-time extensions POSIX API and the real-time kernel offer distinct services (multi- user, multi-tasking) Hard real-time tasks in Linux using POSIX approaches provide little efficiency Linux kernel uses coarse-grained synchronization allowing a kernel task exclusive access for long times Does not preempt execution of any task during system calls High priority tasks are made to wait for low priority ones Time slices, batch operations, frequent hardware reorder requests

Linux Kernel Core Linux, offers to the applications at least : HW management layer dealing with event polling or Processor/peripheral Interrupts Scheduler classes dealing with process activation, priorities, time slice, soft real-time Communications means among Applications (at least FIFO).

Real-Time Application Interface It is a module in dormant state ready to overtake Linux Not a RTOS. Makes Linux kernel fully pre-emptable. Adds the features of RTOS to Linux. interrupt dispatcher: traps the peripherals interrupts and if necessary re-routes them to Linux. Hardware abstraction layer (HAL): Gets information from Linux and traps fundamental functions. Provides few dependencies to Linux Kernel. Minimizes intrusion on the standard Linux kernel Localizes interrupt handling and emulation code Linux is a background task for RTAI

Real-Time Application Interface Offers some services related to: HW management layer dealing with peripherals. Scheduler classes dealing with tasks, priorities, hard real-time. Communications means among tasks & processes (at least FIFO).

RTAI Block Description The software architecture of RTAI is made of:  1 I/F to Linux HW Management (HAL): basically a data structure.  3 basic components (dispatcher, scheduler, fifo's).  1 I/F (set of functions) used in user tasks to initialize and start the components. From a Linux point of view these entities populate modules.

Control flow in a RTAI/Linux system

Virtual Interrupt Control Cli () and Sti () RTAI functions set flags recording incoming and ignored interrupts Sti () records incoming interrupts Cli () records ignored interrupts RTAI registers all interrupts and signals them at an appropriate time

Real-Time Application Interface HAL supports five core loadable modules  Rtai –> provides basic framework  Rtai_sched -> provides periodic or one shot scheduling  Rtai_mups -> provides simultaneous one-shot and periodic schedulers  Rtai_shm -> allows memory sharing (both inter-linux and intra linux)  Rtai_fifos -> adaptation of the RTLinux FIFO’s

Scheduling a task in real time insmod /home/rtai/rtai insmod /home/rtai/modules/rtai_fifo insmod /home/rtai/modules/rtai_sched insmod /path/rt_process insmod – Load a module (could be used with ldmod)

Stop application and remove RTAI rmmod rt_process rmmod rtai_sched rmmod rtai_fifo rmmod rtai rmmod – unload module (remod could be used)

RTAI Mounting Sets up the global hard lock handler Hard locks all CPUs Redirects rthal interrupts enable/disable and flags save/restore to its internal functions doing it all in software Recovers from rthal a few functions to manipulate 8259 PIC and IO_APIC mask/ack/unmask staff Redirect all hardware handler structures to its trapped equivalent Changes the handlers functions in idt_table to its dispatchers Releases the global hard lock Linux appears working as nothing happened but it is no more the machine master

RTAI Modules To use RTAI, the modules with RTAI capabilities must be loaded:  rtai  rtai_sched  rtai_fifos  rtai_shm  lxrt  rtai_pqueue  rtai_pthread  rtai_utils

rtai core module initializes all of its control variables&structures, makes a copy of the idt_table and of the Linux irq handlers entry addresses and initializes the interrupts chips (ic) management functions. must be mounted by calling rt_mount_rtai(). Linux work toward the hardware is filtered by rtai,the only master of the hardware.

rtai_sched real time scheduler module Distributes the CPU to different tasks. The first initialized task will run to completion unless a task with a higher priority is elected or it terminates or the task calls a blocking system function. 3 different schedulers: - UP, only for uniprocessors - SMP, for multiprocessors - MUP, only for multiprocessors

Uniprocessor Scheduler Process with the highest priority gets the CPU. It is a multi-list priority based scheduler. Linux is a real-time task as any other but remains at the lowest priority level. Implementation of the scheduler is split between two complimentary functions:  rt schedule(): Invoked by different facilities to enforce a scheduling change to reflect a modication in the state of a process.  rt timer handler(): Exclusively targeted at dealing with the timer interrupt.

SMP&MUP Scheduler SMP can schedule tasks to more than one CPU. Different degrees of additional services can be dealt with on a specific CPU. SMP scheduler remains a priority driven scheduler. MUP scheduler views a multiprocessor machine as a collection of many uniprocessors. Each CPU can have its timer programmed differently. With MPU, a CPU can run in periodic mode while another running in one-shot mode.

rtai_fifos Implements the fifo services for RTAI. Forms a synergy between the real-time system side and the Linux side. (managing data logging and displaying). rtai_fifos module performs creation, destruction, reading and writing functions for the real-time task interface. Linux user processes see rt-fifos as ordinary character devices. No more required in RTAI, but kept for compatibility reasons and because they are very useful tools to be used to communicate with interrupt handlers. Once you have your interrupt handler installed you can use fifo services to do all the rest.

FIFO Within a kernel module, FIFO API identifies a FIFO using its ID. A real-time task can collect data in real-time while making this data available to a normal Linux process. A sample of the API available to modules:  rtf create(): Creates fifo with a given size and ID.  rtf destroy(): Destroys a fifo.  rtf reset(): Empties the content of a fifo.  rtf put(): Puts data in a fifo.  rtf get(): Gets data from the fifo.  rtf create handler(): Associates a handler to deal with the addition of data to the fifo in an asynchronous way. Semaphore primitives have been added to provide for the synchronization of the access to the fifos.

rtai_shm Allows sharing memory among different real time tasks and Linux processes. It is another mechanism available to users, like fifos. The services are symmetrical. The first allocation does a real allocation, any subsequent call with the same name just maps the area to the user space or return the related pointer to the already allocated space in kernel space. Freeing calls have just the effect of unmapping till the last is done.

lxrt The LX(Linux)RT(RealTime) module Implements services to make RTAI schedulers functions available to Linux processes. Makes it possible to share memory, send messages, use semaphores and timings: Linux Linux, Linux RTAI,RTAI RTAI

LXRT User Space Services By LXRT, user space tasks can call on exported RTAI services like they call on exported Linux system calls. The services exported to userspace using LXRT are all the services previously only available to loadable modules. One can use the same functions and semantics in either user space or kernel space with the same effect. To test real-time applications in user space prior to inserting them as kernel modules. User space applications using LXRT to access RTAI services are not hard-real-time tasks, they are only soft-real time tasks.

Posix RTAI Modules There are multiple Posix standards for real-time. RTAI Posix module implements c and a part of the b. rtai_pthread.o provides hard real-time threads, where each thread is a RTAI task. All threads execute in the same address space and can work concurrently on shared data. rtai_pqueue.o provides kernel-safe message queues. POSIX API and the real-time kernel offer distinct services (multi- user, multi-tasking) Hard real-time tasks in Linux using POSIX approaches provide little efficiency

Memory Management Support for higher-level languages which require new and delete operators. The algorithm provides for real-time memory allocation. Initially reserves a chunk of memory from the kernel. Thereafter, chunks of memory are provided upon request to the callers of rt malloc() using a deterministic algorithm. Freeing of the request memory is done using the rt free() call.

Watchdog To further insure that RTAI is a safe environment Can be used to insure that no one task will freeze the system because of its misbehaviors. Using watchdog facility it is possible to:  ensure that infinite loops and task scheduling overruns do not handicap the system's ability to continue operating  suspend offending tasks or even kill them.

Future Directions More ports of RTAI to other architectures. Extensive framework for C++ programming for RTAI. Real-time RAM filesystem. POSIX I/O layer to support filesystem. Integration of RTNet and socket layer. Integration of Linux Trace Toolkit hooks. Using RTAI services on RTLinux. Standalone RTAI. Standard real-time development environment. Multiple interrupt priorities. Latency verification of code paths.

Questions ??