Seminar Report 2004 Real Time Systems with Linux/RTAI

Preamble: What is Real-Time?

The industrial and military sectors require varying levels of ‘real-time’

computer response depending on the specific nature of each task to be performed.
Consequently, three different definitions of ‘real-time’ can be illustrated by a
battlefield scenario where soldiers in the field provide ‘real-time’ data which is
ultimately sent to the commander’s ‘real-time’ tactical display which provides
information used to determine that a missile (using a ‘real-time’ computer system)
should be launched.

The ‘real-time’ data from the troops can be compared to the now familiar ‘real-
time stock quote’, providing information that was current within the last few seconds
or perhaps minutes. This can be referred to as ‘human real-time’ since short delays
in the tactical data provided from the field are obscured by the much longer human
delays associated with sorting and correlation. The video display observed by the
commander illustrates ‘soft real-time’, where the loss of an occasional frame will not
cause any perceived video degradation, provided that the average case performance
remains acceptable. Although techniques such as interpolation can be used to
compensate for missing frames, the system remains a soft-real time system because
the actual data was missed, and the interpolated frame represents derived, rather
than actual data.

Government Engineering College, Thrissur Page 1

Seminar Report 2004 Real Time Systems with Linux/RTAI

‘Hard real-time’ is illustrated by the control system of a high-speed missile

because it relies on guaranteed and repeatable system responses of thousandths or
millionths of a second. Since these control deadlines can never be missed, a hard
real-time system cannot use average case performance to compensate for worst-
case performance. Thus, hard real-time systems are required for the most technically
challenging tasks.

Since an embedded system often performs only a single task, the differences
between soft and hard real-time for these applications are not as critical as one
would think. However, as true multi-tasking operating systems, such as Linux,
are adopted for use in increasingly complex systems, the need for hard real-time
often becomes apparent. To further confuse the real-time issue, the general term
“Real-Time Operating System (RTOS)” is used to refer to one that can provide either
hard or soft real-time capabilities but not necessarily both. Thus all operating
systems labeled as “RTOS” are not created equally.

Government Engineering College, Thrissur Page 2

Seminar Report 2004 Real Time Systems with Linux/RTAI

The Real-Time Linux Solution

The real-time Linux scheduler treats the Linux operating system kernel as the
idle task. Linux only executes when there are no real time tasks to run, and the real
time kernel is inactive. The Linux task can never block interrupts or prevent itself
from being preempted. The mechanism that makes this possible is the software
emulation of interrupt control hardware. When any code in Linux tries to disable
interrupts, the real time system intercepts the request, records it, and returns it to
Linux. In fact, Linux is not permitted to ever really disable hardware interrupts, and
hence, regardless of the state of Linux, it cannot add latency to the interrupt
response time of the real time system.

When an interrupt occurs, the real time kernel intercepts the interrupt and
decides what to dispatch. If there is a real time handler for the interrupt, the
appropriate handler is invoked. If there is no real time interrupt handler, or if the
handler indicates that it wants to share the interrupt with Linux, then the interrupt is
marked as pending. If Linux has requested that interrupts be enabled, any pending
interrupts are enabled, and the appropriate Linux interrupt handler invoked - with
hardware interrupts re-enabled. Regardless of the state of Linux: running in kernel
mode; running a user process; disabling or enabling interrupts; the real-time system
is always able to respond to an interrupt. Real-time Linux decouples the mechanisms
of the real time kernel from the mechanisms of the general purpose Linux kernel so
that each can be optimized independently and so that the real-time kernel can be
kept small and simple.

Government Engineering College, Thrissur Page 3

Seminar Report 2004 Real Time Systems with Linux/RTAI

From a maintenance perspective, this de-coupling allows the Real-Time Linux

kernel to be easily and quickly adapted to follow changes in the mainstream Linux
kernel. Real-time Linux has been designed so that the real time kernel never waits
for the Linux side to release any resources. The real time kernel does not directly
request memory, share spin locks, or synchronize data structures, except in tightly
controlled situations. For example, the communication links that are used to transfer
data between real time tasks and Linux processes are non-blocking on the real time
side. There is never a case where the real time task waits to queue or dequeue data.

One of the fundamental design philosophies of Real-time Linux is to let the

Linux operating system do as much as is practicable. Typical examples include
system and device initialization, and blocking dynamic resource allocation. Any
thread of execution that can be blocked when there are no available resources
cannot have real time constraints. Real-time Linux relies on the Linux loadable
module mechanism to install components of the Real-Time system, which keeps it
extensible and modular. Loading a Real-Time module is not a real-time operation,
and so Linux can do it. The primary function of the Real-Time kernel is to provide
direct access to the raw hardware for real time tasks so that they can execute with
minimal latency and maximal processing resource, when required.

Government Engineering College, Thrissur Page 4

Seminar Report 2004 Real Time Systems with Linux/RTAI

There are two primary variants of hard real-time Linux available: RTLinux and
RTAI.

RTLinux was developed at the New Mexico Institute of Technology by

Michael Barabanov under the direction of Professor Victor Yodaiken.

Real-Time Application Interface (RTAI) was developed at the Dipartimento

di Ingeneria Aerospaziale, Politecnico di Milano by Professor Paolo Mantegazza.
Under both RTLinux and RTAI, all interrupts are initially handled by the real time
kernel and are passed to Linux only when there are no active real time tasks.
Changes to the Linux kernel are minimized by providing the kernel with a software
emulation of the interrupt control hardware. Thus, when Linux has disabled
interrupts, the emulation software will queue interrupts that have been passed on by
the real time kernel. This is achieved by installing a layer of emulation software
between the Linux kernel and the interrupt controller hardware, and replacing all
occurrences of cli, sti, and iret in the Linux source code with emulating macros.
When the Linux kernel would normally disable interrupts, this event is logged by the
emulation software, but interrupts are not actually disabled.

Government Engineering College, Thrissur Page 5

Seminar Report 2004 Real Time Systems with Linux/RTAI

When an interrupt occurs, the emulation software checks to see whether Linux
has interrupts enabled, if so the interrupt is delivered to the Linux kernel. If not, the
interrupt is held pending the Linux kernel re-enabling interrupts. In this way, the Linux
kernel does not have direct control over interrupts, and cannot delay the processing
of real time interrupts, as these interrupts do not pass through the emulation
software. Instead, they are delivered direct to the real time kernel. This also means
that the scheduling of real time tasks cannot be delayed by Linux.

Fundamentally, RTAI, RTLinux and applications written to take advantage of

them operate in the same way. The Real Time kernel, all their component parts, and
the real time application are all run in Linux kernel address space as kernel modules.
As each kernel module is loaded it initializes itself ready for system operation. The
kernel modules can be removed from the kernel on completion of the real time
system operation. Kernel modules can be loaded and unloaded dynamically, either
by an application or by taking advantage of the automatic module loading features of
Linux itself. The advantages of running the real time system in Linux kernel address
space is the task switch time for the real time tasks is minimized, and Translation
Look-aside Buffer (TLB) invalidation is kept to a minimum as are protection level
changes. Another advantage of making use of kernel loadable modules is that it aids
system modularity. For example, if the scheduler is unsuitable for a particular
application, then the scheduler module can be replaced by one that meets the needs
of the application.

Government Engineering College, Thrissur Page 6

Seminar Report 2004 Real Time Systems with Linux/RTAI

One of the main disadvantages of running in Linux kernel address space is

that a bug in a real time task can crash the whole system, as there is no separate
protected memory space for an individual RT task.

As mentioned earlier, there are two current ‘flavours’ of Real-Time Linux: RTAI
and RTLinux. We are here to discuss about the RTAI solution for the same.

Government Engineering College, Thrissur Page 7

Seminar Report 2004 Real Time Systems with Linux/RTAI

The RTAI Solution

RTAI provides deterministic and preemptive performance in addition to

allowing the use of all standard Linux drivers, applications and functions. RTAI was
initially developed by The Dipartimento di Ingeneria Aerospaziale Politecnico di
Milano (DIAPM) as a variant of the New Mexico Institute of Technology's (NMT)
RTLinux, at a time when neither floating point support nor periodic mode scheduling
were provided by RTLinux. Since then, RTAI has added many new features without
compromising performance.

RTAI's growing list of features now includes:

Ø POSIX 1003.1c compatibility (Pthreads, including mutexes and condition

variables)
Ø POSIX 1003.1b compatibility (Pqueues only)
Ø Traditional RTOS IPCs including: Semaphores, mailboxes, FIFOs, shared
memory, and RPCs
Ø Dynamic Memory Allocation - non-blocking in the Real-Time domain.
Ø PERL Bindings – which allow scheduling of soft real-time tasks from the PERL
scripting language, without the need to know any C or compiler specific
information.
Ø /proc interface – which provides information on the real-time tasks, modules,
services and processes extending the standard Linux /proc file-system
support.
Ø LXRT – which allows the use of the RTAI system calls from within standard
user space
Ø UniProcessor, Multi-UniProcessor and Symmetric Multi-Processor (SMP)
support

Government Engineering College, Thrissur Page 8

Seminar Report 2004 Real Time Systems with Linux/RTAI

Ø FPU support
Ø One-shot and periodic schedulers
Ø

RTAI's performance is very competitive with the best commercial Real Time
Operating Systems (such as VxWorks, QNX etc), offering typical context switch times
of 4 uSec, 20 uSec interrupt response, 100 KHz periodic tasks, and 30 KHz one-shot
task rates. The main limitation being imposed by the system hardware, rather than
the real-time software itself.

Like standard Linux, RTAI is open source and thus it can be downloaded from the
internet and manually patched into a Linux system, or, alternatively it can be easily
installed using the Lineo Industrial Solutions Group, Embedix-RealTime installation
CD which allows real-time Linux features, services, and tools to be applied on top of
an existing and already configured
Linux system.

Architecture

Government Engineering College, Thrissur Page 9

Seminar Report 2004 Real Time Systems with Linux/RTAI

When first envisioned in 1996, RTAI’s real-time technique required three

fundamental problems to be solved. First, the interrupts must be captured. Then, the
real-time schedulers and services must be implemented. Finally, the real-time
application needs a means to interface with RTAI’s schedulers and interrupt
handlers. The following chapters describe how RTAI has achieved these aims.

The Real-Time Hardware Abstraction Layer (RTHAL)

The first problem – that of capturing and redirecting the interrupts, was
addressed by creating a small Real-Time Hardware Abstraction Layer (RTHAL)
which intercepts all hardware interrupts and routes them to either standard Linux or
to real-time tasks depending on the requirements of the RTAI schedulers. Interrupts
which are meant for a scheduled real-time task are sent directly to that task, while
those interrupts which are not required by any scheduled real-time task are sent
directly to standard Linux where they are handled according to normal needs. In this
manner, the RTHAL provides a framework onto which RTAI is mounted with the
ability to fully pre-emptible Linux.

A key component of the RTHAL is the Interrupt Descriptor Table (IDT), which
provides a set of pointers, which defines to which processes each of the interrupts
should be routed. The IDT gives the ability to easily implement or disable all RTHAL
services, allowing the developer to easily track low level bugs under the same kernel
configuration, but with and without the HAL in place.

Upon activation of RTAI within the RTHAL, the following actions occur:

Government Engineering College, Thrissur Page 10

Seminar Report 2004 Real Time Systems with Linux/RTAI

Ø Generation of a duplicate copy of the standard Linux interrupt descriptor table

and interrupt handlers. This new IDT becomes the valid table when RTAI is
activated.

Ø Redirection of the RTHAL interrupts, interrupt enable/disable functions, and

flags save/restore functions to the trapped RTAI equivalents. Placement of all
the appropriate functions and data into a single structure, the RTHAL, makes
it easy to trap these items so that they can be dynamically changed from the
standard Linux entries to entries for the hard real time kernel.

Ø Change of the handler functions in the new idt_table to the RTAI dispatchers
so that it takes control of the system hardware and its interrupts.

Ø Provision of a timer and locking services for the real time domain. The timer’s
services provide control of the 8254 and APIC timers. Under these conditions,
Linux is run only as the idle task to the real time domain. RTAI handles the
Linux "real-time clock" properly by passing up the true clock value upon re-
activation of Linux, thus preserving the correct time settings and keeping Linux
oblivious to its presence.

Advantages and Disadvantages of the RTHAL

The main advantages of using a RTHAL approach compared to a relatively

kernel intrusive implementation such as that used by RTLinux include:

Government Engineering College, Thrissur Page 11

Seminar Report 2004 Real Time Systems with Linux/RTAI

Ø The changes needed to the standard Linux kernel are minimal, a few lines in
eleven source files plus configuration additions to three files in the build
structure, (Makefile, configuration files etc). This lower intrusion on the
standard Linux kernel improves the code maintainability, and makes it easier
to keep the real time modifications up-to-date with the latest release of the
Linux kernel.

Ø The real time extensions can easily be removed by replacing the interrupt
function pointers with the original Linux routines. This is especially useful in
certain debugging situations when it is necessary to remove the extensions,
and when verifying the performance of standard Linux with and without the
real time extensions.

Ø The Linux kernel suffers a slight, but essentially negligible, performance loss
when RTAI is added due to the indirection through pointers to the interrupt
mask, unmask and flag functions.

In consideration of both strengths and weaknesses, this technique has shown

itself to be both efficient and flexible because it removes none of the capability of
standard Linux, yet it provides guaranteed scheduling and response time for
critical tasks.

Real-Time Service Implementation

Government Engineering College, Thrissur Page 12

Seminar Report 2004 Real Time Systems with Linux/RTAI

The second problem -- that of providing real-time schedulers and services – is

addressed by leveraging the existing Linux module loading capability to provide the
real-time schedulers, FIFOs, shared memory, and other services as they are needed.
This module-based architecture yields a system that is easily expandable and
customizable according to only the services that you require. Thus, if you don’t need
shared memory or POSIX, you don’t load those modules.

Real-Time Task Implementation

The third problem is solved, again by using the module loading services of
Linux. Recall that the HAL and real-time modules of RTAI effectively run standard
Linux as the lowest priority task, with the ability (see below) to insert your application-
specific real-time task at a higher priority. In general real-time Linux tasks run with
kernel modules (although extended LXRT is changing this requirement) where they
have direct access to the HAL and RTAI service modules.

Those of you who are familiar with the Linux kernel will note that neither the
memory space occupied by the kernel or its associated modules, is provided any
protection against undesired read/write access. Thus, an improperly implemented
kernel module can over-write critical areas of system memory. This memory over-
write will generally require a system reboot, but it can, in exceptional circumstances
require a complete re-installation of the operating system.

Portable Real-Time Task Implementation

Government Engineering College, Thrissur Page 13

Seminar Report 2004 Real Time Systems with Linux/RTAI

While the issues related to unprotected system memory space are mostly
relevant during the development phase of a kernel module it certainly is a major
inconvenience during development, as once the system has been “damaged”, it is
difficult to debug and may only become operable again by rebooting.

To alleviate this, the developers of RTAI have produced the LXRT (Linux
Real-Time) module that provides the ability to develop real-time applications from
within standard user space using the same RTAI API.

RTAI now also includes the ability to provide hard real-time tasks from user
space using the extended-LXRT feature. Although this provides a protected MMU
context for the real-time task, it still lacks the necessary trap handler to provide fault
recovery during development. This is being address as part of the on-going
development.

Since Linux, like all UNIX systems requires that kernel modules be recompiled
for each version of the kernel that it will be linked to, real-time tasks are generally not
portable across machines running different kernel versions. This requirement means
that kernel module style real-time tasks can only be deployed on machines that run
the same kernel configuration as the development platform.

Consequently, if you wish to provide a kernel module based real-time

application, you must either:

Government Engineering College, Thrissur Page 14

Seminar Report 2004 Real Time Systems with Linux/RTAI

Ø Provide the application's source code so that the end user can compile and
then install the modules as required, or

Ø In addition to the application, you must provide an associated kernel (of the
correct version) to be compiled and installed by the user.

While either of these solutions is often technically acceptable, the use of LXRT
helps one avoid the kernel dependency issue altogether because it allows a real-time
task to run from standard user space – provided that the deployment platform
includes (and loads) RTAI and the LXRT features. In this case, it is an easy matter to
load the LXRT modules (in addition to those required for standard RTAI services)
and to provide the application as a standard user space task.

RTAI's Real-Time Services

Government Engineering College, Thrissur Page 15

Seminar Report 2004 Real Time Systems with Linux/RTAI

RTAI's full feature set can be broken down into a set of basic services – such
as the schedulers, FIFOs, and shared memory, and a set of advanced features such
as POSIX and dynamic memory allocation. Both basic and advanced services are
provided via kernel modules, which can be loaded and unloaded using the standard
Linux insmod and rmmod commands. Although the rtai module is required every
time any real-time service is needed, all other modules are necessary only when
their associated real-time services are desired.

For example, if you want to install only interrupt handlers, you only have to
load the rtai module. If you also want to communicate with standard Linux processes
using FIFOs, then you would then load the rtai_fifos module in addition to the rtai
module. These modules can be dynamically loaded and unloaded – however it is
necessary to pay attention to the order in which they are loaded and unloaded, as
some modules require the services of other. Alternatively, if the modules are installed
in a directory known to modprobe (e.g /lib/modules/<xxx>/misc) and depmod is run,
your real-time module along with all the RTAI modules it depends on may be loaded
by a single 'modprobe' of your application module.

Government Engineering College, Thrissur Page 16

Seminar Report 2004 Real Time Systems with Linux/RTAI

RTAI's basic services are provided by four modules, which allow hard real-
time, fully preemptive scheduling based on a fixed priority scheme. These four key
modules are:

Ø rtai - the basic RTAI framework, plus interrupt dispatching and timer support.
Ø rtai_sched – the real-time, pre-emptive, priority-based scheduler, chosen
according to the hardware configuration.
Ø rtai_fifos – FIFOs and semaphores
Ø rtai_shm - shared memory (note that you can also use the ‘mbuff’ module for
access to shared memory).

The advanced features of RTAI such as LXRT, Pthreads (POSIX 1003.1c) and
Pqueues (POSIX 1003.1b), can be added with these modules:

Ø lxrt - LXRT
Ø rtai_pthread (Pthreads - loaded for POSIX 1003.1c support)
Ø rtai_pqueues (Pqueues – loaded for POSIX 1003.1b message queues
support)
Ø rt_mem_mgr – dynamic memory management for real-time (note that this is
most often simply built-in to the scheduler).

Government Engineering College, Thrissur Page 17

Seminar Report 2004 Real Time Systems with Linux/RTAI

RTAI Schedulers

Although only one type of scheduler can be insmod'ed at any time, RTAI
includes several different types – each uniquely suited to a specific combination of
hardware and tasking requirements. It is generally not necessary for the user to
manually install the proper scheduler because the installation process is usually able
to determine the appropriate scheduler from the hardware configuration of the target
machine. It then copies and links the appropriate scheduler so that it is called by the
generic rtai_sched reference. However, in cases where the developer wants to
investigate other RTAI schedulers, or when he is determining which scheduler should
be installed onto the target platform, an understanding of each option is required.

The RTAI distribution includes three different priority based, pre-emptive real
time schedulers: the Uni-Processor (UP) scheduler; the Multi Uni-Processor
(MUP) scheduler; and the Symmetric Multi-Processor (SMP) scheduler, which
each incorporate standard RTOS scheduling services like resume, yield, suspend,
make periodic, wait until etc.

The implementation and functional usage for each of these schedulers is

described below :

Ø UP scheduler (located in the upscheduler directory)

Ø SMP scheduler (located in the smpscheduler directory)
Ø MUP scheduler (located in the mupscheduler directory)

UP scheduler

Government Engineering College, Thrissur Page 18

Seminar Report 2004 Real Time Systems with Linux/RTAI

This scheduler is intended for uni-processor platforms where the timer is

8254-based and supports either one-shot or periodic scheduling but not both
simultaneously. This should not be used on an SMP machine.

SMP scheduler

This scheduler is intended for multi-processor machines but can support either
the 8254 or APIC based timers and supports either single-shot or periodic scheduling
but not both simultaneously. Tasks can run symmetrically on any or a cluster of
CPUs, or be bound to a single CPU.

Depending on the hardware's architecture, either the 8254 or the local APIC
timer schedulers are chosen for SMP operations. The chosen one will be built and
then installed as the ‘generic’ rtai_sched.o module. RTAI supports true Symmetric
Multi Processing (SMP) architectures by providing dynamic task loading and IRQ
management similar to Linux' SMP operations. RTAI contrasts sharply to other real-
time Linux implementations, which do not support standard SMP load balancing
techniques.

Government Engineering College, Thrissur Page 19

Seminar Report 2004 Real Time Systems with Linux/RTAI

Under RTAI, by default all tasks are defined to run on any of the CPUs and
are automatically moved between CPUs as the system's processing and load
requirements change. However, to accommodate situations where manual task
distribution is able to manage the task loading more efficiently than the automatic
load distribution services, the developer also has the ability to assign individual tasks
to any single CPU or to a CPU subset. Additionally, any specific real-time interrupt
service can be assigned to any specific CPU, and because the ability to force an
interrupt to any specific CPU is not related to the SMP scheduler, these two
operations can be performed independently.

To assign individual tasks to any subset of the CPU pool – including just a
single CPU, use:

Ø rt_set_runnable_on_cpus or
Ø rt_set_runnable_on_cpuid

rt_set_runnable_on_cpus allows you to specify a set (pool) of CPUs (may be just

one) to run the task on. Only one will be selected, however.
rt_set_runnable_on_cpuid allows you to specify only one CPU, but note that if none
of the chosen CPUs are available, the calls will select another one if they can.

To assign any real time interrupt service to a specific CPU, use:

Government Engineering College, Thrissur Page 20

Seminar Report 2004 Real Time Systems with Linux/RTAI

Ø rt_assign_irq_to_cpu, and
Ø rt_reset_irq_to_sym_mode.

Hence, a user can statically optimize their application in instances where it is

thought to be better than using a symmetric load distribution.

MUP scheduler

The Multi-Uniprocessor scheduler is for multiprocessor platforms only and

supports both single-shot and periodic scheduling simultaneously. RTAI's Multi
Uni-Processor (MUP) real-time scheduler implementation is suitable for those
architectures, which include the Intel APIC functionality (i.e. Pentiums and
equivalent). The MUPS can be effectively used on MP machines
with just one CPU mounted on the motherboard.

The MUP is used in a multi-processor but non-true SMP environment where

real-time tasks are bound to a single CPU at task initialization. The tasks can be
moved to a different CPU by using the function rt_set_runnable_on_cpus, but only to
one specific CPU (i.e. not to a pool as can be done under the SMP schedulers).

Government Engineering College, Thrissur Page 21

Seminar Report 2004 Real Time Systems with Linux/RTAI

However, like the SMP schedulers, the MUP can use inter-CPU services
related to semaphores, messages and mailboxes. The main advantage of the MUP
scheduler comes from the ability to be able to use mixed timers simultaneously, i.e.
periodic and one-shot, where periodic timers can be based on different periods.

n o t e : To determine whether there is an APIC available, we could determine it from

"/proc/cpuinfo" and search for "apic" in the flags field. If an APIC is available, then
it is recommended to implement this scheduler. If it is not, then the 8254 scheduler
should be inserted.

n o t e : These SMP schedulers can be used on hardware which is physically uni-

processor but whose Linux kernel has been compiled for SMP configuration.

Be warned that the APIC based scheduler cannot be used for UP, unless you
have the local APIC enabled, i.e. an SMP machine with just one CPU mounted on
the motherboard. It is a fully symmetric scheduler, where at task init all real time
tasks default to using any available cpu. However you can chose either forcing a task
to a single cpu or to let it use any subset of those available by calling the function
"rt_set_runnable_on_cpus". That function set the task structure variable
"runnable_on_cpus" with the bit map of the usable cpus, which is defaulted to
"cpu_present_map", meaning that any available cpu can be used, at task
initialization.

Government Engineering College, Thrissur Page 22

Seminar Report 2004 Real Time Systems with Linux/RTAI

For the APIC timer based scheduler if you want to statically optimize the load
distribution by binding tasks to specific cpus it can be usefull to use
"rt_get_timer_cpu()" just after having started the timer, to know which cpu is using its
local APIC timer to pace the scheduler. Note that for the oneshot case that will be the
main timing cpu but not the only one. In fact which local APIC is shot depends on the
task scheduling out, as that will determine the next shooting.

For the 8254 timer based scheduler a statically optimized load distribution
could bind the 8254 interrupt to a specific cpu by using "rt_assign_irq_to_cpu" and
"rt_reset_irq_to_sym_mode", and then assign tasks in appropriate way to any cpu or
cpu cluster.

Actually there are two schedulers: the pessimistic one keeps the global lock
throughout any scheduling, while the optimistic one releases the lock.

n o t e : In the future it is expected that the MUP will provide the ability to force
critical real-time tasks onto the CPU cache on Pentium IIIs immediately after the task
switch.

Significant differences in performance should be seen only if you are lucky to

have more than 2 CPUs. The scheduler you decide to adopt must be copied in
rtaii_sched.c to be compiled by using "make". Then just do "make instapic" or "make
inst8254" at your choice. Clearly if you have APIC enabled that is the best choice.
The 8254 can be used also on truly UP.

Government Engineering College, Thrissur Page 23

Seminar Report 2004 Real Time Systems with Linux/RTAI

The MUP scheduler derives its name from the fact that real time tasks MUST
be bounded to a single CPU at the very task initialization. They can be afterward
moved by using the function "rt_set_runnable_on_cpus". The MUP scheduler can
however use any inter CPUs services related to semaphores, messages and
mailboxes. The advantage of using the MUP scheduler comes mainly from the
possibility of using mixed timers simultaneously, i.e. periodic and one shot, where
periodic timers can be based on different periods, and of possibly forcing critical
tasks on the CPU cache on PIIIs, in the future. With dual SMP one cannot say that
there is a difference in efficiency. MUP has been developed primarily for our not so
fast, a few KHz, PWM actuators, BANG-BANG air jet thrusters, coupled to a periodic
scheduler.

All the functions of UP and SMP schedulers are available in the MUP
scheduler, and MUP specific functions can be used under UP-SMP. Some default
action is implied in scheduler-specific features. The main difference can be seen for
functions whose name ends with "_cpuid". Such functions imply the specification of a
CPU number and came into play with the MUP scheduler whenever a cpuid had to
be declared. Typical examples are: task init and time conversions, when time formats
differ. Please note that there is a difference between "cpuid", i.e. the CPU number,
and "cpu_map", i.e. 1 << cpuid. Thus if you use task init with a cpuid on UP-SMP
schedulers you have it assigned to the only CPU available or mapped to the declared
one, while if you just task init on MUP your task is assigned to the CPU loaded with
less tasks, and so on.

Government Engineering College, Thrissur Page 24

Seminar Report 2004 Real Time Systems with Linux/RTAI

We have to be careful in relation to time conversion under MUP with

heterogeneous timers otherwise you'll put on the scheduler blames that are due only
to your misunderstanding on how it works. Clearly no problem arises if the same kind
of timers are used on all CPUs, and with the same period if they are periodic.
However the advantage of the MUP scheduler is really the possibility of having a
periodic and a one shot timer, or two periodic timers with different periods,
simultaneously, and you must use it for that case. The timing relies on the RTAI
support functions:

void rt_request_apic_timers(void (*handler)(void), struct apic_timer_setup_data

*apic_timer_data)

and

void rt_free_apic_timers(void)

The "struct apic_timer_setup_data { int mode, count; };" allows you to define
the mode and count to be used for each timer as:

mode : 0 for a oneshot timing, 1 for a periodic timing;

count : is the period in nanosec you want on that timer.

It is in nanosecond for ease the programming in relation to what said above. It

is used only for a periodic timer as for the one shot case the first shot defaults to the
Linux tick. The start of the timing should be reasonably synchronized internally.

Government Engineering College, Thrissur Page 25

Seminar Report 2004 Real Time Systems with Linux/RTAI

Conclusion

Are you...

Ø Tired of expensive real time operating systems?

Ø Looking for deterministic response to interrupts?

Ø Working with POSIX compliant or native RTAI real time tasks?

Ø Looking for real time system development in user space?

Ø Searching for friendly community support?

Ø All that on top of a general purpose operating system with penguins inside?

Then RTAI might be the realtime extension of your choice! RTAI is a true
community project. With the support of the OSS community, “Linux + RTAI” has now
become one of the most reliable Real Time Operating System solution with the least
TCO. With the above notions, its clear that Linux/RTAI is the next generation RTOS
solution which is going to be the future.

References

Government Engineering College, Thrissur Page 26

Seminar Report 2004 Real Time Systems with Linux/RTAI

1. “http://www.rtai.org/documentation/articles/history/history.pdf”, the RTAI history.

2. “http://www.rtai.org/documentation/articles/position_paper.pdf”, the RTAI

POSITION PAPER, NOV 2000 by P. Cloutier, P. Mantegazza, S.

Papacharalambous, I. Soanes, S. Hughes, Karim Yaghmour.

3. “http://www.rtai.org/documentation/articles/guide.html” , the RTAI beginners

guide.

4. “http://www.rtai.org/documentation/reference/rtai_man.pdf”, the RTAI manuals.

5. “http://www.rtai.org/documentation/reference/rtai_prog_guide.pdf”, the RTAI

programmers guide.

Government Engineering College, Thrissur Page 27