Re: rtlinux comedi_poll() and ni_pcimio with continuous DMA

I downloaded the comedi CVS tonight. It seems to help a little.

With the code (continuous acquisition) from last time (50 microsecond
interrupts) checking the continuous acquisition, I obtain some curious
result with pulses of data transfer:
// kernel log:
rtdma_mod.o: comedi buffer size= 65536 bytes
rtdma_mod.o: comedi buffer address= 0xd09d4000
rtdma_mod.o: command test 1 returned 0
rtdma_mod.o: command test 2 returned 0
comedi: cannot switch shared interrupt to RT priority
rtdma_mod.o: command exec returned 0
rtdma_mod.o: DMA thread: Start Task
rtdma_mod.o: 0, dt=   4352 nsec, poll= 0, get_buffer_contents= 0
rtdma_mod.o: 1, dt=  57216 nsec, poll= 0, get_buffer_contents= 0
rtdma_mod.o: 2, dt=  49952 nsec, poll= 0, get_buffer_contents= 0
rtdma_mod.o: 3, dt=  49856 nsec, poll= 0, get_buffer_contents= 0
rtdma_mod.o: 4, dt=  50528 nsec, poll= 30, get_buffer_contents= 30
rtdma_mod.o: 5, dt=  50848 nsec, poll= 282, get_buffer_contents= 282
rtdma_mod.o: 6, dt=  50272 nsec, poll= 278, get_buffer_contents= 278
rtdma_mod.o: 7, dt=  49376 nsec, poll= 272, get_buffer_contents= 272
rtdma_mod.o: 8, dt=  49152 nsec, poll= 72, get_buffer_contents= 72
rtdma_mod.o: 9, dt=  49376 nsec, poll= 0, get_buffer_contents= 0
rtdma_mod.o: 10, dt=  50240 nsec, poll= 0, get_buffer_contents= 0
rtdma_mod.o: 11, dt=  51744 nsec, poll= 0, get_buffer_contents= 0
rtdma_mod.o: 12, dt=  49856 nsec, poll= 182, get_buffer_contents= 182
rtdma_mod.o: 13, dt=  49952 nsec, poll= 276, get_buffer_contents= 276
rtdma_mod.o: 14, dt=  50816 nsec, poll= 280, get_buffer_contents= 280
rtdma_mod.o: 15, dt=  48288 nsec, poll= 194, get_buffer_contents= 194
rtdma_mod.o: 16, dt=  51296 nsec, poll= 0, get_buffer_contents= 0
rtdma_mod.o: 17, dt=  47648 nsec, poll= 0, get_buffer_contents= 0
...

In about 411 microseconds, I count 934 samples which is weird because that
corresponds to about a 400nsec sample time, whereas the fastest sample time
of the ni_pcimio is 800nsec, what I set it up for in the DMA command. If I
increase the interrupt to 100 microseconds, the bursty nature of the data
remains there.  What could be causing this?

My ultimate goal is to use the comedi_poll/get_buffer_contents to monitor a
software triggered acquisition such as might be initiated by:

 cmd.subdev = 0;
 cmd.flags = 0;
 cmd.start_src = TRIG_INT;  // instead of TRIG_NOW
 cmd.start_arg = 0;
 cmd.scan_begin_src = TRIG_TIMER;
 cmd.scan_begin_arg = 800;
 cmd.convert_src = TRIG_TIMER;
 cmd.convert_arg = 800;
 cmd.scan_end_src = TRIG_COUNT;
 cmd.scan_end_arg = 1;
 cmd.stop_src = TRIG_COUNT; // instead of TRIG_NONE
 cmd.stop_arg = 63;

When I setup the DMA in this manner (62-63 samples expected at 800ns/sample,
monitored every 50 microseconds), and try to trigger it in the real-time
interrupt, I get all zeros back.  Is there a better way to issue the
software trigger or setup the DMA with internal triggering to get data back?

// excerpt from real-time interrupt issuing software trigger to DMA:
     inst.insn= INSN_INTTRIG;
...
   tv1= clock_gethrtime( CLOCK_REALTIME);
   dt= tv1-tv0;
   ret1= comedi_poll(cm_device,0);
   ret2= comedi_get_buffer_contents(cm_device, 0);
   rtl_printf("rtdma_mod.o: %d, dt= %6d nsec, poll= %d, get_buffer_contents=
%d, software trig now\n", Count, dt, ret1, ret2);
   tv0= tv1;
   Count++;
   if (ret2!=0)
         comedi_mark_buffer_read(cm_device, 0, ret2);
   comedi_do_insn( cm_device, &inst); // trigger sample, we'll count how
many come back next time

// excerpt of kernel log when using software trig:
rtdma_mod.o: 0, dt=   4000 nsec, poll= 0, get_buffer_contents= 0, software
trig now
rtdma_mod.o: 1, dt=  57696 nsec, poll= 0, get_buffer_contents= 0, software
trig now
rtdma_mod.o: 2, dt=  49696 nsec, poll= 0, get_buffer_contents= 0, software
trig now
rtdma_mod.o: 3, dt=  49536 nsec, poll= 0, get_buffer_contents= 0, software
trig now
rtdma_mod.o: 4, dt=  49344 nsec, poll= 0, get_buffer_contents= 0, software
trig now
rtdma_mod.o: 5, dt=  50240 nsec, poll= 0, get_buffer_contents= 0, software
trig now
rtdma_mod.o: 6, dt=  50368 nsec, poll= 0, get_buffer_contents= 0, software
trig now
rtdma_mod.o: 7, dt=  49376 nsec, poll= 0, get_buffer_contents= 0, software
trig now
...

Regards,
Alex

----- Original Message ----- 
From: "Frank Mori Hess" <fmhess_at_users.sourceforge.net>
To: "Nils Juergens" <ju_at_isf.rwth-aachen.de>; <comedi_at_comedi.org>
Sent: Thursday, April 29, 2004 6:14 PM
Subject: Re: rtlinux comedi_poll() and ni_pcimio with continuous DMA


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 29 April 2004 05:32 am, Nils Juergens wrote:
>
> My current _guess_ is that comedi_command() from kcomedilib forgets to
> set s->busy. At least i was unable to find it.
>
> Try adding
>
>     if(s->busy) {
>         return -EBUSY;
>     }
>     s->busy = d;
>
> after line 147 of kcomedilib_main.c
>
> good luck,
> Nils
>

I've put this change into the cvs, thanks.

- -- 
Frank

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAkX5M5vihyNWuA4URAteIAKDco9AVCj6YqFBCh9PB985azBZ2TwCeP50p
M1mzqUMc2NlbYXT/TnEclWw=
=59xl
-----END PGP SIGNATURE-----

_______________________________________________
comedi mailing list
comedi_at_comedi.org
https://cvs.comedi.org/cgi-bin/mailman/listinfo/comedi

Received on 2004-04-30Z01:44:28