Hello,
I'm new to this list, so let's introduce myself: I'm doing measurements
(heart and respiratory rhythms, apnoea detection) in the context of
polysomnography, which requires getting data on long intervals (8+ hours).
Up to now, I'm using a National Intruments Lab-PC card, and the driver
(module ) found on the LLP page. I've rewritten a lot of code for the
Digital IO part, and hooked some functions to drive a device of my own.
Basically, it is a standard device driver, accessed through the VFS layer.
There is an ISR handler, which fills buffers, and a "read" routine
performing the transfer to user space. Acquisition rate is rather low (20
samples/second), but though I got problems in time intervalles ranging
from one to three hours (between 70 000 and 180 000 samples)
Why could a system acquire 180 000 samples and then fail ? My hypothesis
is that, although the duration of one acquisition is around 50 millisecs,
and the observed latency time is from 50 to 200 microsec, there is still a
chance that an acquisition is not serviced in time. To investigate it, I
wanted to switch to RT-Linux. (linux-2.0.36, compiled, installed, tested,
OK)
As the most crititical part is the interrupt handler, and to avoid
rewritting a lot of code (I'm in a hurry to get results :-( ), I just
changed the request_irq() call to a request_RTirq(), so that my card
interrupt is serviced in real-time. First tests show the interrupt latency
is better, but that no other tasks could run, so the question :
-is such an approach valid ? (my driver implement buffering, so the
operations to give data to the user don't need RT characteristics)
-did someone implement it and could give an example ?
-there are two forms of cli : r_cli and s_cli. Doc does not mention
difference, what is it ?
-the 'read' routine does a sleep_on with timeout. Could it still be used ?
Please consider I want to change as little as possible from the driver,
and just ensure garanteed latency response time for the interrupt handler,
and no more (which would require rewritting the user-space application)
Thanks in advance
Pascal A. Dupuis
--
The generation of random numbers is too important to be left to chance.
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
