- From: Tomasz Motylewski <motyl_at_stan.chemie.unibas.ch>
- Date: Sun, 17 Nov 2002 18:40:46 +0100 (CET)
I am running PCI-MIO-16E-1 with current comedi CVS and comedilib/demo/ao_waveform -F 1000000 It looks good (I can see sin() waveform on one channel. I was also able to get simultaneous output on 2 channels by setting n_chan=2 and running it with -F 500000.) There are about 500 interrupts per second visible. (BTW. how do I use that waveform output from the kernel space (RT)? Not neccesarily in the continuous mode, it is enough for me to write about 8000 samples in the buffer and trigger "one shot" output of that waveform) Typical output looks like: m=4092 m=4078 m=26 m=4096 m=4070 m=22 m=4100 m=4070 m=22 m=4100 m=4070 m=22 But one time I have got: ni_mio_common: DMA underrun nbytes 2490390, write count 2486294 (I was using default buffer size, which is probably too small). > > We got dma analog output (and input) working with the NI 611x cards, > > but I've hit two issues with output dma. How to munge output data > > that is being dma'd directly from the buffer, and how to reliably > > detect underruns? Well, fortunately I do not need both of these functions. It is interesting that when comedi gets fixed my application gets broken. > Accurately handling overruns, that is, making sure that no incorrect > sample is output, is difficult. I don't care too much about that > right now. To do that properly would require playing with the link IMHO in many cases outputing slightly old data may be better than outputing no data at all. Especially when dealing with cyclic waveforms. I can do "if((int)(nbytes - async->buf_write_count) > 0)" in the application if I want. What I _really_ do not like is _obligatory_ stopping AO or AI on over/underrun. It is OK to detect such condition, but pulling emergency break in case of each timing problem is just making bad things worse. You detect that your train is late - this is an "error case" - your action: "pull emergency brake". This is what comedi does. Instead of allowing the application to catch up with the write pointer, it kills it completely. But I think I have found an easy workaround for me - just "#define COMEDI_CB_OVERFLOW 0" ;-) OK, will try it next weekend. Or may be I will get a flag doing it for Christmas? :-) Best regards, -- Tomasz Motylewski
Received on 2002-11-17Z17:40:46