• RTAI User Manual
• Debian Etch Compile RTAI

The easiest way to configure, compile and install RTAI is doing it directly on the target architecture, avoiding many possible problems of cross-configuration and cross-compilation. If the target system doesn't have enough processing power or resources, it is possible to run a virtual machine on a workstation, emulating the target environment.

Download the last release of RTAI

Look in <RTAI>/base/arch/{arm|i386|ppc}/patches all the available kernel patches with the pattern: hal-linux-{version}-{arch}-{minor}.patch

Download the corresponding kernel sources

Apply the RTAI patch to the kernel sources:

• <RTAI>/base/arch/{arm|i386|ppc}/patches/hal-linux-{version}-{arch}-{minor}.patch

Run menuconfig starting from an old configuration.

The foundamental configurations to allow RTAI to work properly are:

• Loadable module support → Module versioning support: disabled
• Processor type and features → Symmetric multi-processing support: disabled
• Processor type and features → Interrupt pipeline: enabled
• Processor type and features → Use register arguments: disabled

Additionally, to increase the real time performance, it is better to remove all the power management features:

• Power management options (ACPI, APM) → Legacy Power Management API: disabled
• Power management options (ACPI, APM) → Software Suspend: disabled
• Power management options (ACPI, APM) → ACPI Support → ACPI Support: disabled
• Power management options (ACPI, APM) → APM BIOS Support → APM BIOS Support: disabled
• Power management options (ACPI, APM) → CPU Frequency scaling → CPU Frequency scaling: disabled
• Power management options (ACPI, APM) → Power Management support: disabled

@see kernel

make-kpkg --append-to-version -rtai --revision r1 --initrd kernel_image kernel_headers

• –append-to-version {label}: Append a significant label to this new kernel image.
• –revision {rev}: Set the revision number of this new kernel image

cd /usr/src/rtai-{version}
./configure
make
make install

This test verifies the architectural latency and jitter, up to the scheduling of a task.

/usr/realtime/testsuite/user/latency/run
/usr/realtime/testsuite/kern/latency/run

This test provides information about the maximum time RTAI needs to disable the interrupts. To do so the utility uses a repeated sequence of of suspend/resume and semaphore signal/wait under a relatively heavy load. Assuming a correct configuration of RTAI, the result gives an idea about the architectural switching time.

/usr/realtime/testsuite/user/switches/run
/usr/realtime/testsuite/kern/switches/run

This test is designed to verify the schedulers under intense load.

/usr/realtime/testsuite/user/preempt/run
/usr/realtime/testsuite/kern/preempt/run

• RTAI schedulers and hard real time in kernel/user space

RTAI provides two schedulers, both sharing similar interfaces. They differ for the types of schedulable objects:

• Linux schedulable objects are processes/threads/kthreads
• RTAI own kernel tasks are very light kernel space only schedulable objects proper to RTAI

The big advantage of RTAI's light kernel tasks is their fast switching time with respect to Linux kernel threads, but on the other side it's important to know that they operate outside any Linux environment. This behavior requires some special care if one needs to inter-operate with Linux. This attention has not to be payed with Linux kernel threads as they offer the advantage of being fully integrated in the Linux environment and ease any needed RTAI Linux interaction. So unless there is a real design constraint using the GNU/Linux co-scheduler is the best choice; or at least is the one which gives more freedom to the development process.

• LXRT-INFORMED FAQs

LXRT is a module that allows you to use all the services made available by RTAI and its schedulers in user space, both for soft and hard real time.

RTAI provides the standard services like resume, yield, suspend, make periodic, wait until etc. You will also find semaphores, mail boxes, remote procedure calls, send and receive primitives integrated into the state machine of the real time scheduler. Typically, the IPC function calls support:

• Blocking until the transaction occurs.
• Returning immediately if the other end is not ready.
• Blocking for the transaction until a timeout occurs.

A program that want to use LXRT has to call rt_task_init(name, …). The call differs from the real time counterpart (there are a few exceptions to the symmetry rule) in that, among other things, you provide a name for your program. The name must be unique and is registered by LXRT. Thus, other programs, real time or not, can find the task pointer of your program and communicate with it.

LXRT creates a real time task who becomes the “angel” of your program. The angel's job is to execute the real time services for you. For example, if you call rt_sleep(…), LXRT will get your angel to execute the real rt_sleep() function in the real time scheduler. Control will return to your program when the angel returns from rt_sleep().

There is not any code required for the real time component of your Linux task. LXRT uses the standard RTAI scheduler functions for that. In the QNX world, the “angel” is called a virtual circuit.

The inline functions declared in rtai_lxrt.h all do a software interrupt (int 0xFC). Linux system calls use the software int 0x80. Hence the approach is similar to a system call. LXRT sets the interrupt vector to call rtai_lxrt_handler(void), a function that saves everything on the stack, changes ds and es to __KERNEL_DS and then calls lxrt_handler, the function that does the work.

MBX *mbx
struct message_s {int field_a; int field_b;} message;
 
mbx = rt_mbx_init(nam2num("NAME_MBX"), 10*sizeof(message));
 
if (mbx != 0) {/* CANNOT CREATE MAILBOX*/}