Subject: QUESTION: real-time, interrupt latency & atom process
To: None <tech-kern@netbsd.org>
From: Dr. Magnus Sethson <magnus@sethson.net>
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?
/thanks
--
Dr. Magnus Sethson
Email: magnus@sethson.net, magse@ikp.liu.se
EOF