Re: New buffer reading behaviour in continuous acquisition mode?

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

On Wednesday 29 January 2003 01:02 pm, Michal Dobes wrote:
> 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.

I replaced comedi_buf_put() (which should really be given a quick death at 
this point) with calls to cfc_write_to_buffer() and 
cfc_write_long_to_buffer() as appropriate, in cvs.  Would you try that?  It 
still may be too slow though, in which case you would need to either use 
cfc_write_array_to_buffer() which I would describe as "more than fast 
enough", if you arrange your driver to copy the data in chunks.  Or you could 
do a bit of work to make the driver do a zero copy dma directly into comedi's 
buffer (like ni_pcimio.c does).

I also noticed that your driver seems to do a bit of byte swapping on the 
data, making assumptions about the cpu's byte ordering?  If this is the case, 
you should really use the cpu-independent byte swaping functions provided by 
the kernel, such as le16_to_cpu(), etc.

- -- 
Frank

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

iD8DBQE+ODB75vihyNWuA4URAufoAJ95osqRyEw7YYUiJkCH3D9KGb47lQCfVBbN
hyzxuBFEZh+aG7mbD8y8r0Y=
=1I43
-----END PGP SIGNATURE-----

Received on 2003-01-29Z19:50:19