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

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 gt provides basic framework
• Rtai_sched -gt provides periodic or one shot
  scheduling
• Rtai_mups -gt provides simultaneous one-shot and
  periodic schedulers
• Rtai_shm -gt allows memory sharing (both
  inter-linux and intra linux)
• Rtai_fifos -gt adaptation of the RTLinux FIFOs

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 variablesstructure
  s, 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
SMPMUP 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 Linuxlt-gtLinux,
  Linuxlt-gtRTAI,RTAIlt-gtRTAI

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