Re: Hardware Abstraction Layer - Rev 0.01

[jmkasunich-at-ra.rockwell.com]

Max Heise wrote:

> well I have not been active on this list for quite
> some time and haven't followed all threads. Perhaps
> you already considered comedi ?

Somebody did mention comedi a while back, I took a
quick look and my first reaction was that it is very
complex.  Of course all APIs are complex when you
first look at them.  The other thing I noted is that
comedi looks like it was written mostly for user
mode programs, and was later extended for real-time.

Comedi does not address the issue of mapping any
I/O bit to any internal variable at runtime, which
is one of our core requirements.  I consider "links"
to be the key feature in the proposed HAL.

> It might be interesting to avoid reinventing the
> wheel once more for the HW driver side+have the
> added bonus of other drivers ready for use.

My personal opinion is that I would rather write a
HAL driver that directly accesses the hardware, for
better speed.  But I am a hardware guy who likes to
write low-level code....

On the other hand, if a comedi advocate wrote a
HAL driver that encapsulates the comedi API, then
_any_ hardware with a comedi driver could be used
with EMC, retaining the benefits of HAL "links"
while re-using the hardware specific comedi drivers.
That sounds promising.

One of the strengths of comedi is that it addresses
scaling.  Currently EMC does scaling in the EMCMOT
task, and I haven't proposed changing that - the
HAL is a big enough change already.  Does anyone
think we should address scaling at the HAL level,
or is the existing design better?

John Kasunich