Real Time Application Interface (RTAI) Zubair Ahmad - Ilhan Akbas.
-
Upload
ethel-tate -
Category
Documents
-
view
225 -
download
0
Transcript of Real Time Application Interface (RTAI) Zubair Ahmad - Ilhan Akbas.
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 ??