Re: Hardware Abstraction

Arlet wrote:
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.

For this particular example it is actually extremely nice to abstract
the routine. I have used the same 'main I2C' library for the Z80, 8032
and the PIC with calls to five funtions.
SDA_LO,SDA_HI,SCL_LO,SCL_HI and SDA_IN. The benefit of doing this is
that it was easy to change hardware and only these 5 short functions
changed. It also made changing timing requirements simple. (In a lot of
cases the call and return added enough delay to eliminate extra delays)

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 ?
I think this would be an even better example of why abstraction would
be good. Abstraction could even be a macro in the hardware header.

What if precise timing is required, for instance bitbanging a UART
peripheral ?
I have been abstracting whole uart routine to the hardware file. For Tx
it reads a circular transmit buffer and for Rx it write to one. The
'main' routine just polls the buffer to check for characters.


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.

It is a bigger hassle to start with - until a hardware change is needed
and then there is only one place you need to look when making the
changes.
Regards
Rocky

.

Relevant Pages

  • Re: Havent done anything real with OOP yet.
    ... But it is an algorithm description and, ... simulation needs. ... hardware to/from the network port. ... driving the abstraction of a rather specialized chunk of hardware. ...
    (comp.object)
  • Re: [OT] ALSA userspace API complexity
    ... So API might look a bit complicated for the first glance, but the ALSA interface code for simple applications is not so big, isn't? ... Wny applications myst know anything about hardware layer? ... Why we have X servers in user space then? ... All abstraction are NOW coded but some parts of this abstraction are on library level and you are wrong because this still ONE abstraction ...
    (Linux-Kernel)
  • Re: Hardware Abstraction
    ... hardware abstraction, and while LED's and motors are hardware in a ... hardware abstraction is generally about the ... peripherals used to control these devices. ... a bit-banged I2C bus driver doesn't care about ...
    (comp.arch.embedded)
  • Re: hardware geeks and software geeks
    ... I can certainly confirm that the hardware guys use levels ... of abstraction as much as the software guys do. ... the ramp voltage is zero. ... The ON-TIME value equating to the speed demand can be ...
    (comp.lang.forth)
  • Re: book on assembly language
    ... |> But right, some code parts can be written OS-independent, ... |> and they would need their own hardware routines to communicate. ... routines for keyboard, mouse and GUI-drivers. ... | more callable instructions at an adress is an abstraction, ...
    (alt.lang.asm)