Re: counter, pulse generator API, ni_660x.o

> 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.

Hi Frank,

First of all, thank you for your work!
Can you give an example from the application point of view, since I don't
really see how you can switch between x1, x2 and x4 counting with the
above mentioned trigger/action pairs scheme?

Furthermore, a couple of weeks ago, there was a post with a question about
buffered event counting on the ML.  Does this application class fit
somehow in your scheme too (the are still some other applications, that
are not adressed yet, such as period measurement etc)?

> 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?

The good part about your proposal seems to me the fact that you use a
command for something that is truly asynchronous.
OTOH, if you program it with instructions as we currently did, it
seems to me there is more parallellism between the different application
classes.

> 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.

That would be great.  IMHO, counter API can only get better if people are
trying to apply it to "their-favourite-cards", so it get's more clear what
is the common stuff between most counter cards.

Furthermore, I guess the 8 channel DIO subdevice could be committed as
well, since it is less "intrusive" with respect to the API?

regards and thank you again for your effort,

klaas

Received on 2003-11-17Z08:34:51