Last edit: on October 5, 2006 11:48 (4892 days, 6 hours and 4 minutes ago) (diff)
Rtai.Dk | RecentChanges | Preferences | DIAPM RTAI
see also Configure Kernel
From the RTAI mailinglist: 
- I used RTAI in a large project for a customer. we were basically a 2 person low level dev team, and a 2 person application software team.
- my experiences:
- installing RTAI for the first time is no picknick.
- the documentation is not up to date (24.1.11)
- the INSTALL document was not 100% correct/complete
- better use the "RTAI User Manual", which is not included in the tar ball, but can be found on the website www.rtai.org
- the INSTALL document fails to report a number of gotchas that you fall into by default. for example when configuring the kernel:
- SMP kernel is enabled by default. if you don't have an SMP machine RTAI freezes on insmod.
- ditto for kernel frame pointers
- and Local APIC emulation for single CPU machines.
- since most projects use specialized hardware you have to make sure that there are drivers for linux and hope that you can use them, since they are not real time by default. to make drivers realtime you have to write your own. I did so for a number of PCI devices, and it is very time consuming. of course this is only an option if you have the pci chip interface documentation. otherwise your system is still not real time: bad luck.
- RTAI refused to fire interrupt handlers for 1 certain PCI slot if they were configured for real-time interrupts. configuring it as a linux interrupt magically works. when we swapped the PCI boards, it turned out that the driver was ok, but the RTAI interrupt handling was not.
- on one pc we could remap IO space, while on another one we could not.
- i do not deny the useability of rtai, but it is still not an easy to learn solution. Time is money, so for a lot of solutions it makes good business sense to buy a working platorm, and start working on that. also for a lot of solutions, customers want accountability. if for some reason the rtai platform fails, I as a developer do not want to be held responsible for code i did not write.
- also avoid kernel-hacking options
- disable BIOS USB Legacy Support. Sometimes enabling CONFIG_USB_UHCI_HCD in kernel also helps (see [mailinglist])
- ? disable "Loadable module support" -> "Set version information on all module symbols" (from README.INSTALL) ?
- disable REGPARM option (from kernel 2.6.x?) (see [mailinglist1], [mailinglist2])
- disable CONFIG_4KSTACKS for fusion < 0.7.5 (What about RTAI 3 ? ; In which kernel versions is this option available and where can it be found ? This option is available at least in 126.96.36.199; It does not seem to be available in 2.4.27; see [mailinglist])
- maybe there is a problem about TSC emulation in RTAI 3 (3.0-test1 .. 3.1-test5). This is no problem when your linux kernel is compiled for PentiumClassic (aka 586TSC) or above. But you need TSC emulation when you use 586/K5/5x86/6x86/6x86MX or below.
- some systems use smi (see [mail1], [mail2])
- geode is supported but need some addition special configuration (AFAIR smi related modules need to be loaded; search mailinglist for details)
- there may be problems with PCI MSI (Message Signal Interrupt) in ADEOS (see [xenomai-core mailinglist], Feb 2006).
- in the kernel configuration file use CONFIG_MODVERSIONS=n, otherwise you compile your kernel and after that, when compiling rtai the makefile will tell you hours later, that you should have compiled the kernel without CONFIG_MODVERSIONS set. Alternatively use "make menuconfig" to disable "Loadable module support -> Set version information on all module symbols / Module versioning Support". The menu entry names seem to differ depending on the kernel version (problem seen with rtai3.4 and kernel 2.6.12)