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 1003.13 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_schedreal 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 1003.1c and a part of the 1003.1b.

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 ??