Real Time Application Interface (RTAI)

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

2. Content • OS Requirements • Linux Kernel Core • RTAI Description • LXRT • Future Directions

3. 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.

4. 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

5. 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).

6. 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 abstractionlayer (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

7. 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).

8. 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.

9. Control flow in a RTAI/Linux system

10. 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

11. 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

12. 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)

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

14. 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

15. 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

16. 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.

17. 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

18. 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.

19. 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.

20. 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.

21. 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.

22. 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.

23. 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

24. 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.

25. 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

26. 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.

27. 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.

28. 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.

29. Questions ??