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: Sun Apr 23 05:35:45 CDT 2006

> What hardware platform are you running Linux on?

It is x86. My robot has two Soekris net 4801-50 boards (the older ones) 
booting off compact flash. These single board computers are intended for 
routers. They have a 266 MHz Geode CPU with 128 MB RAM. Each board has 
three network interfaces (only need one), two serial ports, and about a 
dozen GPIO pins. I've abused the boards quite a bit and yet they still 
survive with minimal damage.

Please excuse me Ed for I am continuing with a response to another's 
email. It's still technically pertinent to your question, though. And to 
the other person, perhaps I violate etiquette by replying to the group. I 
just thought that there is value to others.

The kernel is built without virtual memory support. I'm also not using a 
hard disk of any kind. Everything runs off of a ramdisk and compact flash. 
By doing this, I hope to avoid interrupts being turned off during mass 
storage access. Anyway, the electronics enclosure is sometimes exposed to 
significant shock that would probably crash a hard disk.

For my robot, if there is interrupt latency in the millisecond range, that 
is not really a big deal so long as timing during bit banging has 
microsecond resolution. I think that many mechantronic or biological 
systems operate in the 10 Hz to 60 Hz range. So Stanley "thinks" at 10 Hz 
according to the PARC talk. Nikon stabilized optics work at something 
around 22 Hz (this is hearsay and I may remember it wrong) corresponding 
to natural body sway. This is why I think that many robotics teams use 
Linux even though it is not really intended to be an RTOS. The overall 
system frequency required is pretty low so you can get away with it.

So, yes, in the general case (which includes a lot), vanilla Linux 2.6 is 
not enough for microsecond resolution timing. It is not possible to 
guarantee when something happens. It is not a hard RTOS, obviously. But 
for robotics applications where the system frequencies are low, I believe 
this is good enough.

More information about the DPRG mailing list