Hardware Abstraction

Hello All,

I am looking for a concept for abstracting of a hardware. It is desired 
that the concept should be convenient, clear, consistent, logical and 
pretty universal.

My goal is developing more or less universal HAL and application 
framework for automotive, control and instrumental. It should not be 
tied to a particular OS, CPU or board.

Can you recommend a good reading on that. I am not very interested in 
the specifics of a particular OS or board, but in the good concepts and 
ideas.


Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

Vladimir Vassilevsky wrote:

> Hello All,
> 
> I am looking for a concept for abstracting of a hardware. It is desired 
> that the concept should be convenient, clear, consistent, logical and 
> pretty universal.
> 
> My goal is developing more or less universal HAL and application 
> framework for automotive, control and instrumental. It should not be 
> tied to a particular OS, CPU or board.
> 
> Can you recommend a good reading on that. I am not very interested in 
> the specifics of a particular OS or board, but in the good concepts and 
> ideas.


Such as block and stream devices ?
Those almost infinitely clever abstractions lower
the performance to almost zero when someone then
tries to implement a serial protocol on serial hardware
but with a stream device driver in between.

IMO, a HAL is a bad idea in many cases, especially
on embedded hardware. How to dump performance on
zero advantage.

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

Rene Tschaggelar wrote:


>> I am looking for a concept for abstracting of a hardware. It is 
>> desired that the concept should be convenient, clear, consistent, 
>> logical and pretty universal.
>>
> 
> Such as block and stream devices ?

The abstractions at the lower level are interesting to me. A pin can be 
an input or output. Some outputs can do PWM. Some inputs can do input 
capture. So on, so forth.

Also, it would be good to minimize the amount of cryptic system 
functions, initializations and dependencies.


> Those almost infinitely clever abstractions lower
> the performance to almost zero when someone then
> tries to implement a serial protocol on serial hardware
> but with a stream device driver in between.

Size/speed are not the issues in 99% cases. What does matter is the 
quality and the application development time.


> IMO, a HAL is a bad idea in many cases, especially
> on embedded hardware. How to dump performance on
> zero advantage.

Reinventing a wheel each and every time when starting a new project is 
not a good idea either.


> 
> Rene

VLV

On Mon, 27 Nov 2006 23:29:36 GMT, Vladimir Vassilevsky
<antispam_bogus@hotmail.com> wrote:

>I am looking for a concept for abstracting of a hardware. It is desired 
>that the concept should be convenient, clear, consistent, logical and 
>pretty universal.
>
>My goal is developing more or less universal HAL and application 
>framework for automotive, control and instrumental. It should not be 
>tied to a particular OS, CPU or board.
>
>Can you recommend a good reading on that. I am not very interested in 
>the specifics of a particular OS or board, but in the good concepts and 
>ideas.

Vladimir Vassilevsky wrote:
> Hello All,
> 
> I am looking for a concept for abstracting of a hardware. It is desired 
> that the concept should be convenient, clear, consistent, logical and 
> pretty universal.
> 
> My goal is developing more or less universal HAL and application 
> framework for automotive, control and instrumental. It should not be 
> tied to a particular OS, CPU or board.
> 
> Can you recommend a good reading on that. I am not very interested in 
> the specifics of a particular OS or board, but in the good concepts and 
> ideas.

Perhaps this ?
http://research.microsoft.com/foundations/AsmL/

-jg

Vladimir Vassilevsky wrote:

> 
> 
> Rene Tschaggelar wrote:
> 
> 
>>> I am looking for a concept for abstracting of a hardware. It is 
>>> desired that the concept should be convenient, clear, consistent, 
>>> logical and pretty universal.
>>>
>>
>> Such as block and stream devices ?
> 
> 
> The abstractions at the lower level are interesting to me. A pin can be 
> an input or output. Some outputs can do PWM. Some inputs can do input 
> capture. So on, so forth.
> 
> Also, it would be good to minimize the amount of cryptic system 
> functions, initializations and dependencies.
> 
> 
>> Those almost infinitely clever abstractions lower
>> the performance to almost zero when someone then
>> tries to implement a serial protocol on serial hardware
>> but with a stream device driver in between.
> 
> Size/speed are not the issues in 99% cases. What does matter is the 
> quality and the application development time.

The initialization usually is only a few register
access each. Depending on the families, there are
limitations that cannot be overcome. Especially
since some families were partially made to have
a certain feature enhanced.
Eg the dsPIC2023, with a PWM that operates on a
PLLed 480MHz clock, but only on 5V, at 3.3V, the
PLL is lower, 320MHz. You want to cover this with
a standard PWM ?

I came across such libraries. As soom as you need
a trivial addition, such as power save, part of them
becomes useless.

>> IMO, a HAL is a bad idea in many cases, especially
>> on embedded hardware. How to dump performance on
>> zero advantage.
> 
> Reinventing a wheel each and every time when starting a new project is 
> not a good idea either.

Read the manual once, understand how it works and
then copy/paste from project to project.

Rene

Vladimir Vassilevsky wrote:
> Hello All,
>
> I am looking for a concept for abstracting of a hardware. It is desired
> that the concept should be convenient, clear, consistent, logical and
> pretty universal.
>

Hi Vladimir,

I am following this with interest. I try to keep all references to the
hardware in one file or set of files so that even toggling pins becomes
a function call. If speed is needed then the entire function is taken
out of the main code and an API designed for it. While in some case
speed may suffer and then exceptions are made, in general the ease of
porting to different h/w is made much easier.

By their nature interrupt service routines are in this 'h/w' category.

If you find / develop a good 'standardised' concept that does not cause
total bloat it would be really great if you could share it here.

Regards
Rocky

Vladimir Vassilevsky wrote:
> Hello All,
> 
> I am looking for a concept for abstracting of a hardware. It is desired 
> that the concept should be convenient, clear, consistent, logical and 
> pretty universal.

I find that when abstracting hardware, like any other abstraction,
it is useful and important to separate the construction/initialization
and mode selection from the abstract interface that is used during
most of the application life cycle.

To use a GPIO pin as an example, a bit-banging application can
generally perform two operations:

setHIGH()
setLOW()

The initialization, that selects mutiplexed function routing,
direction, open-drain operation and other configuration belongs
to another interface that is most likely not abstract.

IMHO, operations which are not available on a particular
piece of hardware should not appear in the abstraction
supported by that hardware. For example, a having the
ability to read the value of a GPIO at the pin or as
a read-back of the register associated with the pin.
Some GPIO implementations have one or the other and
some have both. Thus there are two possible operations:

bool readAtPin()
bool readPinRegister()

A GPIO implementation that supports only one of these
should not have the other available in its interface.
The result is there is no error condition if an application
calls an "unsupported" operation.

All of this falls under the "Interface Segregation Principle"
The result is several very narrow abstract interfaces rather
than a single abstract interface. Though this suggests MI,
composition is generally better suited for the implementation.

sorry about the long post

-- 
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1

Michael N. Moran wrote:
> Vladimir Vassilevsky wrote:
> > Hello All,
> >
> > I am looking for a concept for abstracting of a hardware. It is desired
> > that the concept should be convenient, clear, consistent, logical and
> > pretty universal.
<snip>
> IMHO, operations which are not available on a particular
> piece of hardware should not appear in the abstraction
> supported by that hardware. For example, a having the
> ability to read the value of a GPIO at the pin or as
> a read-back of the register associated with the pin.
> Some GPIO implementations have one or the other and
> some have both. Thus there are two possible operations:
>
> bool readAtPin()
> bool readPinRegister()
>
> A GPIO implementation that supports only one of these
> should not have the other available in its interface.
> The result is there is no error condition if an application
> calls an "unsupported" operation.
>

If the higher level s/w requires a readPinRegister would it not be
better to implement it for example by keeping a copy that is written to
RAM?

When using a PIC it is sometimes necessary to do this anyway to prevent
corruption of output pins that change slowly due to loading. One alway
does the BSF or BCF on the RAM copy and then writes that out to the
port.
Regards
Rocky

Michael N. Moran wrote:

> Vladimir Vassilevsky wrote:
> > Hello All,
> >
> > I am looking for a concept for abstracting of a hardware. It is desired
> > that the concept should be convenient, clear, consistent, logical and
> > pretty universal.
>
> I find that when abstracting hardware, like any other abstraction,
> it is useful and important to separate the construction/initialization
> and mode selection from the abstract interface that is used during
> most of the application life cycle.
>
> To use a GPIO pin as an example, a bit-banging application can
> generally perform two operations:
>
> setHIGH()
> setLOW()
>
> The initialization, that selects mutiplexed function routing,
> direction, open-drain operation and other configuration belongs
> to another interface that is most likely not abstract.

What if I need to dynamically change pin properties ? For instance,
bitbanging an I2C port may involve changing SDA/SCL from input to
output on some architectures.

What if 8 of those GPIO pins are available on the same port, and I need
to access them simultaneously, for instance to access an 8 bit
peripheral ?

What if precise timing is required, for instance bitbanging a UART
peripheral ?

Frankly, I don't see where providing an abstraction for a single GPIO
pin is going to make life easier. There are just too many variations in
hardware capabilities, and application requirements. Even if you could
design a model, it would probably be slow and bloated, and a much
bigger hassle than just accessing the hardware ports directly.