Re: LDP and comedi

On 10/25/07, Herman Bruyninckx <Herman.Bruyninckx_at_mech.kuleuven.be> wrote:
> The motion control features belong to another API than the DAQ API that
> Comedi provides.

I agree in principle, but in the specific case I'm talking about
(Quanser Q8), the card is really a DAQ card... it has 8 encoder
inputs, 8 analog inputs, 8 analog outputs, 32 DIO and a handful of
other counter/timers.  My confusion was mostly with implementing the
encoders and other counters.  The only real non-DAQ feature was a
hardware-level emergency stop (which puts all of the DAQ outputs in a
"safe state").

In any case...

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

By filtering, I only meant hardware-level features -- I've seen things
like DIO debounce or a configurable anti-aliasing filter.  And for the
waveform generator, I was only thinking of cases where you buffer the
entirety of a repeating waveform to the card.  Maybe comedi already
supports this and I'm not familiar with it.

Clearly, any digital filtering of inputs is application-specific and
belongs in the userspace program that's using comedi.  In my opinion,
comedi should really only be concerned with presenting the features of
the hardware to the user in a standardized and device-agnostic way.

However, more often than not in DAQ hardware, there's some extra
configuration option or feature (like the emergency stop on the
Quanser Q8) that doesn't cleanly fit the abstraction... in those
cases, we ought to provide a device-dependent way to access those
features.

On 10/25/07, Bernd Porr <BerndPorr_at_f2s.com> wrote:
> Well. There's still the comediLIB which actually provides the API. As
> long as comedilib doen't change, the kernel drivers can morph as long as
> comedilib does the appropriate abstraction.

Exactly -- the discussion I'm trying to start is what we want our
*kernel* API to look like.  If I understand the process correctly,
inclusion in the mainline kernel means that the kernel to userspace
API should be stable and slow to change.  Thus, if there's a reason to
change something there, we should consider it before moving towards
inclusion in the mainline kernel.

Of course, I don't know that we have consensus yet about moving the
comedi drivers to the mainline.  Personally, I think it'd be a benefit
to both the comedi project and mainline kernel.  The only downside I
see (which is admittedly a major one) is that some of the realtime
integration would have to be removed or changed.

-Tabish

Received on 2007-10-25Z20:47:10