buffer stuff

Dave,

I noticed you checked a bunch of further work on the buffer stuff.  I have
one complaint though: that you only kept comedi_buf_put().  I did create a
bit of an explosion of variations, and simplifying it is fine, but if we
just want one version of comedi_buf_put, it should be the general one,
with a prototype similar to __comedi_buf_put_array().  It could handle
sampl_t and lsampl_t and transfer arbitrary sized chunks more efficiently
than doing single transfers in a loop.  Transfering single samples is fine
for lower speeds (say less than a megahertz on not too obsolete hardware).
But for example, at 20MHz with the pcidas-4020, calling comedi_buf_put()
in a loop just eats up too much cpu time.

Hmm, also all the handling of events seems to have been ripped out, which
is going to cause problems... there seems to currently be a hack in
comedi_event that always sets the BLOCK event?

On an unrelated note, Ivan has been having problems with interrupts.  It
seems whenever the interrupt is set to hard real time priority (TRIG_RT
flag, or running command through kcomedilib) only one interrupt is
generated, then the interrupt doesn't work anymore (until the cb_pcidas.o
driver is removed and reloaded).  When the interrupt is run at normal
priority, everything seems to work fine.  He's using RTAI on a smp
machine, I thought you might have some insight?

Frank

Received on 2002-07-09Z16:19:27