Re: New buffer reading behaviour in continuous acquisition mode?

Frank Mori Hess wrote:
> The cb_pcidas64.c driver is the only one that uses it.  There are a few lines
> in the documentation file, the lines below the one you saw, describing what
> the elements of the data array mean.  The zeroth element is just
> INSN_CONFIG_BLOCK_SIZE, and the next element is the block size in bytes.  The
> driver should write back the actual block size it is using if it can't
> achieve exactly the block size that was requested.

Interesting function. I criend about it some time ago. :-)

Btw, I downloaded comedi-0.7.66 and looked on it how this works 
and I must say that there is a lot of changes from 0.7.33 which
I still use.

Some of them is not too fine. My adl_pci9118 driver now runs
about 40% slower on the account of comedi_buf_put() call.
But this driver don't works corretly, becouse comedi_buf_put() 
don't handle 32-bit moves, so every second sample is dropped
and driver is unusable. 
There is one simple workaround for this:
--- adl_pci9118.c       Thu Nov 21 08:34:30 2002
+++ adl_pci9118.c.2     Wed Jan 29 19:58:59 2003
_at__at_ -1501,7 +1501,8 _at__at_
        devpriv->ai_add_back=0;
        devpriv->useeoshandle=0;
        if (devpriv->master) {
-               devpriv->usedma=2; // assume 32 bit DMA transfer now
+               //devpriv->usedma=2; // assume 32 bit DMA transfer now
+               devpriv->usedma=1; // hard fallback to 16 bit mode
                if ((cmd->flags&TRIG_WAKE_EOS) &&
                    (devpriv->ai_n_scanlen==1)) {
                        if (cmd->convert_src==TRIG_NOW) {

But the driver with it runs more that 3 times slower if compared
with 0.7.66 version.

	Majkl

Received on 2003-01-29Z19:02:01