Re: LDP and comedi

On Thu, 25 Oct 2007, Tabish Mustufa wrote:

> On 10/25/07, Herman Bruyninckx <Herman.Bruyninckx_at_mech.kuleuven.be> wrote:
>> BTW, what are, in the opinion of the Comedi users/developers, the real
>> 'showstoppers' to move to "1.0"...?
>
> It's been several months since I looked at it, but I recall that the
> encoder / counter API was confusing.  Or perhaps it was fine, and it
> was the documentation that was confusing...
>
> We had been using a Quanser Q8 card to run a prototype robot at my
> employer, and I thought I'd clean up and port the driver we were using
> to comedi... but though it is ultimately a digital and analog I/O
> device, the Q8 card has several features oriented towards motion
> control that didn't seem to fit into the comedi abstraction very well.
> Since we had picked that card specifically for those features, I
> ended up abandoning the comedi port.  I'd be happy to pick it up again
> if it would shed some light on the dusty corners of the API.

The motion control features belong to another API than the DAQ API that
Comedi provides. That's the approach we took in Orocos (Open Robot Control
Software), at least, where we are quite happy with the Comedi way of doing
things. Maybe the semantics of "commands" should be clarified a bit more,
especially their interrelationship with "callbacks" (events): it's not
clear to me whether currently Comedi supports all command use cases
appropriately. (It should certainl _not_ support application-dependent use
cases such as your motion control board.)

> In general, I would say that the pieces that are widely implemented
> among comedi drivers (analog and digital I/O, instructions and
> commands) are fine.  The parts that are listed as "experimental" in
> the comedi documentation (encoders and counters, filtering options,
> waveform generation, advanced trigger settings) need to be cleaned up
> and documented if they're going to be frozen into a mainline kernel
> API.
Personally, I think the filtering and waveform generation functionalities
belong in another API: the Comedi DAQ functionalities are typically
_instantaneous_ operations, while filtering and waveform generators
inherently work over longer periods of time. I think it's a bad idea to mix
both interfaces.

> Though I'm not personally familiar with it, we may be able to take
> some inspiration from Video for Linux 2... video capture cards are
> also a class of devices that all generally do the same thing, but have
> tons of device-specific configuration options that need to be taken
> into account.  There's been a long series of articles explaining the
> v4l2 kernel API at lwn.net:
>
> http://lwn.net/Articles/203924/
>
Maybe a fundamental difference between DAQ and video capturing is that the
former has much higher realtime and periodicity constraints than the
latter? And the data is not a 'channel of integers', but a 'stream of
arrays'. My intuition tells me Comedi should not try to do video capturing,
but I agree with you that a comparison of the API designs could be
illuminating...

Herman

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Received on 2007-10-25Z10:56:53