- From: Jan Gukelberger <g.u.g.i_at_gmx.de>
- Date: Thu, 07 Apr 2005 14:39:41 +0200
On Wed, 2005-04-06 at 12:28 +0200, Jan Gukelberger wrote: > Hi all, > > I'm recording the AIN channels of a MC PCI-DAS6025 board (cb_pcidas64) > with a comedi_cmd. > While one application thread writes the recorded data into a file, > another thread must read the most recent sample from time to time. > As it's impossible to comedi_data_read a subdevice while executing a cmd > (it yields EBUSY), I mmap'ed the device's streaming buffer so I can read > both buffer front and back. > > Now the problem is that the samples do only arrive in 4k junks in the > buffer which means that the buffer front can be up to 256ms old > (4kS/16channels/1000Hz). This is way too much latency for my needs. So > I've inserted a comedi_poll instruction before reading the buffer front, > but this always fails with EINVAL, AFAICT because the cb_pcidas64 driver > doesn't implement the POLL ioctl. > > Now my question(s): > Is this a hardware limitation or could this be implemented? > Are there any other possibilities, e.g. tuning the size of sample junks > or something like that? ok, for the second question, I've just come across INSN_CONFIG_BLOCK_SIZE. So it should be possible to at least decrease the maximum time gap between acquisition and a sample appearing in the mmap'ed streaming buffer. Would setting BLOCK_SIZE to some extremely small value like 32 have any negative consequences? Probably yes, so what problems would I have to expect? Anyway, this would be a hack as COMEDI_POLL is exactly what I'd really need. Frank: Do you have any PCI-DAS 60xx docs that indicate whether the driver could implement POLL'ing on this hardware? > > It would be quite annoying if I'd have to make an RTAI module for such a > basic data recording function that could easily be done in hardware. > > Thanks in advance for any comments, > Jan
Received on 2005-04-07Z11:39:41