DPRG
DPRG List  



[DPRG] microsecond resolution realtime with Linux 2.6

Subject: [DPRG] microsecond resolution realtime with Linux 2.6
From: Chris Jang cjang at ix.netcom.com
Date: Sat Apr 22 20:47:38 CDT 2006

The last few weeks, I've been trying to get real time performance from a 
uClibC/buildroot Linux 2.6 system. For my application, that means low 
microsecond timing resolution. The motor control system relies on bit 
banged TTL serial so timing constraints are somewhat rigid. (Yes, this is 
a bad design - I freely admit that.)

Anyway, I think it is finally working and stable. Here's a diagram of the 
system on the robot.

http://golem5.org/robot1/images/design20060422.jpg

When I first came up with this, I thought it was new and different. But 
actually it is very old school. The Linux HOWTO for Yodaiken's RTLinux (of 
FSMLabs) devotes a section to this approach.

    user space process  ----realtime FIFO---->  special hard RT process

Robert Love, who wrote the pre-emptive Linux kernel patch (now mainstream 
in 2.6 kernels), says that soft RT is often good enough. The experience 
I've had with my robot supports this. However, the downside is increased 
time spent tuning the system and testing it. You have to really be aware 
of all of the event processing loops and I/O going on, as well as arrival 
and service rates for each loop. As a system grows, it is increasingly 
difficult to know that it will work in all situations.

But the good news is that it does work. Vanilla Linux is good enough to 
give microsecond resolution soft real time performance entirely in user 
space. You don't need a special hard RT platform or to write any device 
drivers. You can stay out of the kernel and still get the performance you 
need. It may take some work, though.

When I started my robot, I considered using the free for non-commercial 
QNX/Neutrino distribution, RTLinux, or RTAI (another hard RT Linux 
system). In the end, I went with vanilla Linux 2.6. I believe that for 
most amateur robots, Linux 2.6 is good enough to satisfy real time timing 
constraints. It is not perfect - there are still failures. But if life and 
limb are not at risk, then it is ok.

More information about the DPRG mailing list