- From: Yoshiya Matsuzaka <ymatsuzaka_at_hotmail.com>
- Date: Thu, 18 May 2006 11:37:33 +0900
Hi, Thanks for your e-mail. Now my question about the time base of sampling is cleared. I have additional questions. > For boards and/or drivers that support asynchronous acquisition, the > comedi core installs an IRQ handler which has hard realtime priority. > The handler communicates to client code that new samples have > arrived via function callbacks. Q1. What happens if the ISR for the DAQ card in use is not given hard realtime priority? This can happen when the DAQ card is sharing IRQ with other PCI devices (e.g. In my PC, PCI-DAS1602/16 shares the IRQ with NIC. When I run an application that calls comedi_command, I get the warning "cannot switch shared interrupt to RT priority"). In this case, do I lose some of the data? >> boards (e.g. ni_pcimio.o) do not seem to be dependent on this module. >> Modprobing DAQ modules does not load comedi_rt_timer.o, even under real >> timer >> kernel (I am using RTAI 3.1). Is it that most of the DAQ modules use the >> on-board timer to pace the sampling? > Yes, they use the DAQ card's on-board timer, unless you decide to use > comedi_rt_timer which basically uses the PC motherboard's timer, > ultimately to affect the same result (more or less). Q2. Then, if the sampling is paced by on-board timer, COMEDI drivers can sample the data at constant interval even under non-realtime kernel. Correct? And finally, this is my comment. I like the idea of using the on-board timer. The PC can achieve faster sampling rate with less load to CPU than by pacing the sampling by RTOS's timer. I still have some difficulty in using COMEDI, but it is a lot less than writing the driver by myself. Yoshiya Matsuzaka
Received on 2006-05-18Z01:37:33