Re: rtlinux dma get_buffer_contents number of bytes transferred

I see that they do work, I was trying to call them too soon in time, that is
consistent with the other postings on the list about the mite behavior for
block transfers.

For example, when I register a comedi callback with TRIG_WAKE_EOS, using an
800 nsec scan and convert clock, I receive interrupts to the callback
approximately every 34 microseconds - that roughly coincides with a 4K block
transfer size other posters have discovered.  Setting the cmd.flags for
TRIG_WAKE_EOS or TRIG_RT has no effect on this behavior.

When I setup my own 1 msec (for example) RT thread to poll the DMA status of
my 800 nsec scan clock, even with a call to comedi_poll() in there,
get_buffer_contents() will return 0 fifteen times in a row before it returns
values such as 4020, 15 more 0's then 4032, 17 more 0's then 4224, 15 more
0's then 3978, etc.

I was hoping to find a way to put my RT interrupt handler "in between" each
800 nsec data conversion so it would examine every new piece of data and
react to it at a fast rate.   That is, I'd like to use DMA as a faster
alternative to programmed IO using the comedi_read command.

I tried setting up the DMA with

cmd.convert_src= TRIG_INT
cmd.begin_src= TRIG_INT

then in the RT handler,

inst->insn= INSN_INTTRIG
comedi_do_insn(dev,inst)

in order to allow the RT thread to initiate the conversions, but that didn't
work out as I expected, it didn't seem as if I received any triggers at all
based on reading the buffer.

Can DMA be used as a faster alternative to programmed IO on the NI card when
the mite chip is controlling the transfers?

Alex




>>Those functions should work when called from kcomedilib also.  The number
>>of bytes transferred will only get updated when the mite generates an
>>interrupt though.  To do better would require supporting comedi_poll() for
>>dma transfers in the driver (which would actually be pretty trivial to do
>>at this point).
>>
>>- -- 
>>Frank


On Saturday 06 March 2004 10:01 pm, Alex Fielding wrote:
> I am using cmd (comedi 0.7.67) to initiate a continuous A/D acquisition
> in an RTLinux (3.1) kernel module (with the ni_pcimio driver and a
> National Instruments PCI-MIO-16E-1 board).  After some review of the
> list I've managed to successfully read the preallocated buffer (by first
> performing a comedi_map(), cmd.data=NULL, and
> cmd.data_len=map_size*sizeof(sampl_t)), but I am still unclear on the
> best way to periodically read and flush out the buffer contents.
>
> I have seen several posts to this mailing list indicating that
> get_buffer_contents, get_buf_head_pos, and get_buffer_offset do not
> return the number of bytes transferred when called on the kernel side
> (kcomedilib) (in my test program I get values of zero returned all the
> time).  I also have seen references to calling mite driver routines and
> minimum block sizes for the dma transfers but I am not entirely clear on
> what's happening there.  Will someone explain?
>
> I need to know the number of bytes transferred accurately.  When running
> continuous acquisition in user-space we call get_buffer_contents and
> mark_buffer_read.  How can I accomplish the similar task in the
> real-time kernel module?
>

Received on 2004-03-15Z03:38:50