counter, pulse generator API, ni_660x.o

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

In an effort to get the ni_660x patches applied, I've been converting them 
to the counter API Dave suggested using (as I understand it).  So far, 
I've got an INSN_CONFIG that is more general (and more painful to use) 
than the existing GPCT_* stuff in the patch Klaas provided.  It is can be 
used for simple up/down counting, and quadrature x1,x2, and x4 counting 
with z channel reset, but could probably stand some improvement still.  
How it works is the data[] array of the insn is of arbitrary length, and 
contains (at its end) pairs of elements (a 'trigger' and a corresponding 
'action')  A trigger might specify that it goes off when input 0 has a 
rising edge, and input 1 is high, then the corresponding action might be 
to increment the accumulator (the counter).  It is somewhat painful to 
use, since it requires the driver to analyze the insn to determine whether 
it is actually one of the combinations the hardware is actually capable of 
achieving.  Similarly, a user would have to come up with one of the magic 
combinations in order to get it to work.  I suppose life could be made 
easier for the user by providing some functions at the comedilib level 
that are specifically tailored to particular pieces of hardware.

As far as the single pulse/pulse train generation part of the patch, I'm a 
bit more lost.  My initial thought is to treat them as output commands.  
The immediate stumbling block to this is that currently, you can only have 
one output command per device.  Here, we would want to have one output 
command per channel of a counter subdevice (since we seem to be mapping 
each counter onto one channel of the counter subdevice).  It's also not 
very clear to me exactly what Dave would like to see improved/changed 
about this part of the patch?

Does anyone out there have anything to say about any of this?  Speak now!  
In any case, I suppose I could commit the counter/encoder part of the 
patch after a little more work so others could look at it more closely and 
improve it. 

- -- 
Frank

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

iD8DBQE/uCbv5vihyNWuA4URAunKAJ90X1vEYLoWFpRgUrNUqgak8iEX2QCfb656
VRGFTxgIcYDn4X+P95si9bw=
=twnc
-----END PGP SIGNATURE-----

Received on 2003-11-17Z01:39:55