Re: [Xenomai-help] RTDM driver questions

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2108 bytes --]

witzel.thomas@domain.hid wrote:
> Hello All,
> 
> I'm working on a RTDM driver for a PCMCIA DAQ card. I have already implemented 
> all the basic infrastructure, some ioctls for setting the sampling rate and 
> interrupt sources and have also implemented the interrupt handling (there is 
> some issues with the irqs that I might ask about later). 
> My question is how to best give the data from the driver to the user space data 
> acquisition program. Should I allocate some kernel space and mmap it to the user 
> address space and then use a signal of some kind to inform the user space 
> application when the space is half full ? Any suggestions how this is best done 
> are welcome.

Already had a look at the interfaces comedi provides for this? Do you
know of Alexis' ongoing effort to port comedi over RTDM? There is some
code in the Xenomai SVN as a branch. I'm not up-to-date with its
development, but if you are interested, I guess Alexis will be happy to
comment on this.

Generally spoken, mmap can make sense if you have a significant amount
of data to transfer, not "just" a few kbyte/s. RTDM has the elementary
support for such device interfaces now, and this has already been used
for a frame-grabbing driver.

> 
> Also I'm using now a clock on the DAQ card to trigger an interrupt at which I 
> read the samples of the card. The card itself (ancient) has only a very small 
> FIFO and I also want to do some DIO on the PCs parallel port for each sample 
> that I read from the DAQ card, so thats why I decided for this design. Would it 
> be better to use a timer from xenomai to do the sample clocking rather than an 
> irq generated by the clock on the DAQ card (performance or otherwise) ?

The on-board timers surely have lower jitters than software-driven
timers can provide. Depending on your application, this can make a
difference. On the other hand, application-driven acquisition timing can
be easier to implement (less synchronisation issues). Again, I would
suggest a look at comedi if and how such capabilities are used there.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]