Re: channel 'bounce' with ni_pcimio

From: Jack Culpepper <jack_at_email.arc.nasa.gov> · Date: Mon, 9 Sep 2002 11:51:47 -0700

Thanks for everyone's help.  Let me just give a little background info to aid
in my explanation here: I am reading 8-16 channels at 4 KHz, one row at a time
(yes, I know I should be reading more than a row at a time to improve
performance, etc. but it SHOULD work on my machine).  For a long time it was
working fine.  Then, I think after upgrading from comedilib-0.7.18 to 19, the
channel bounce started happening.  After doing some debugging, I discovered
that the reason it was happening was because during the bounce, every read from
the driver was returning less than the number of bytes than it should have.
(I wasn't checking for this before..demo/cmd.c doesn't check either.  Dave:
you might consider adding this code to demo/cmd.c at around line 150

   if (0 != (ret % sizeof (sampl_t))) {
     fprintf (stderr, "Error! got an odd number of bytes: %d\n", ret);
     exit (3);
   }
   samp = ret / sizeof (sampl_t);

   if (0 != (samp % n_chan)) {
     fprintf (stderr, "Error: didn't get a full scan. %d samples\n", samp);
   }

so other slackers like me don't have similar problems.)  The 'bounce' effect
leads me to believe that somewhere inside the driver, the sample from one or
more channels was being over-written by the subsequent channel.

Finally: upgrading everything to the versions in CVS fixed me, yay!

Jack

On Wed, Sep 04, 2002 at 02:12:20PM -0700, David Schleef wrote:
> On Tue, Sep 03, 2002 at 09:16:14AM -0700, Jack Culpepper wrote:
> > Correct.  The switch happens briefly, then things go back to normal, then it
> > happens again.  To give you an idea of the time scale, when sampling at 4 KHz, 
> > the problem appears about once every 15 seconds (although it's not periodic),
> > and lasts for maybe 50-100 samples.
> 
> This is quite possibly DMA writing to the wrong part of the Comedi
> buffer.  0.7.65 doesn't have very good control over which regions
> of the buffer belong to DMA vs. belonging to the reader.  Rewriting
> the buffer code has been one of the major developments lately, and
> it's taking a while to settle.
> 
> You should be able to reduce the chance of seeing this problem by
> increasing the buffer size.  You can eliminate it entirely by
> disabling DMA in the driver (USE_DMA in ni_pcimio.c).
> 
> 
> 
> dave...
> 
> 
> _______________________________________________
> comedi mailing list
> comedi_at_comedi.org
> https://cvs.comedi.org/cgi-bin/mailman/listinfo/comedi