Subject: QUESTION: real-time, interrupt latency & atom process
To: None <>
From: Dr. Magnus Sethson <>
List: tech-kern
Date: 11/13/2001 11:07:43
Controlling robots and machines using a real-time operating system is 
allways an interesting topic. I would like to use simple measurement cards 
for robot control, preferable hosted in a PC running an OS like NetBSD.

The working principle is very simple. The measurement card generates an 
interrupt for every sampling event, normally at 10-2000Hz. That interrupt 
must be handled immediately, downloading sampling data from the AD:s 
register or FIFO. Also it must make some simple regulator/trajectory 
calculations, typically 5-10 rows of C-code including both floating point 
and integer operations.

More advanced measurement card have large buffers that does not need to be 
downloaded that often. However, these buffered "high-end" cards is most 
often not suitable for control, even if the vendors claim that.

In control every sample need to handled directlly. Often several analog 
input channels are put togheter as "one sample". (example: 5 channels are 
downloaded as 5x16bit, short integer at a rate of 400Hz) The interrupt 
function typically reads some 16bit words from the ISA or PCI buss, makes 
som simple calculations and returns some 16bit values to one to four ports 
on the ISA or PCI bus. To make the robot work, this repitive task is time-
critical both in terms of constant sampling time and completeness (the 
function must complete every time)

My question: have any one concidred this in NetBSD? Is it possible to make 
small changes to the kernel so that it is guaranteed that an interrupt is 
serviced whithin a certain time interval (typically <50us). Also is it 
possible to make sure that the small function/thread/process serving the 
interrupt is not interrupted itself (an atom function)?

Beeing a member of staff at a university I might concider puting some 
students on a project like this. Is it possible to achive anything like 
this? Can anyone comment on the amount of work needed? Can anyone point out 
where in the code of the current NetBSD kernel any changes might be needed?


Dr. Magnus Sethson