Re: Hardware Abstraction

Rocky wrote:

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.

Sure, but if you have a "uart" abstraction, and an "I2C" abstraction,
and you build those directly on the hardware ports, you're not using a
GPIO abstraction, which was my point.

Abstracting a UART or I2C makes sense. The interface is fairly small,
and relatively well-defined.

For other interfaces, such as GPIOs, but also timers, it's virtually
impossible to define a generic model that can be ported to all kinds of
hardware, but still allows you to exploit all the little optimizations
and features that the MCU may have.

.

Relevant Pages

  • Re: Hardware Abstraction
    ... I am looking for a concept for abstracting of a hardware. ... To use a GPIO pin as an example, ... What if 8 of those GPIO pins are available on the same port, ...
    (comp.arch.embedded)
  • Hardware Abstraction
    ... 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 am not very interested in the specifics of a particular OS or board, but in the good concepts and ideas. ...
    (comp.arch.embedded)
  • Re: Hardware Abstraction
    ... I am looking for a concept for abstracting of a hardware. ... a read-back of the register associated with the pin. ... Some GPIO implementations have one or the other and ...
    (comp.arch.embedded)
  • Re: Hardware Abstraction
    ... I am looking for a concept for abstracting of a hardware. ... tries to implement a serial protocol on serial hardware ... zero advantage. ...
    (comp.arch.embedded)
  • Re: implementing roles in OOP......
    ... everything should be driven by abstracting the problem ... my draft interfaces define what sort of thing I would ... All I need is the Composite relationships to navigate, ... IEnumerator is an interface defined by my environment, we can put, ...
    (comp.object)