Re: Hardware Abstraction



Michael N. Moran 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.


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()

Actually, there should be a 3-level interface:

Application: set_something_meaningful(BOOL param)
Hardware abstraction: set_port_pin(BOOL param)
Low level: PORTA.1 = param


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

Initialization/deinitialization is a big potential source of errors. The initalizations should be consistent with the application interface.


IMHO, operations which are not available on a particular
piece of hardware should not appear in the abstraction
supported by that hardware.

Yes. And the attempt to use the unsupported function should be detected at the compile time.


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.


:) We are growing out of this concept at this moment.
Initially it was copy/paste code reuse, then it came to a set of functions and macros, and finally it was realized that a new paradigm is required.


Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com
.

Relevant Pages

  • Re: Newbie Modelling Interface Question
    ... A client's access to this subsystem is ... interface has a message identifier and a by-value data packet. ... The client then has a pointer to each interface. ... For example, in a hardware interface, clients usually want to manipulate ...
    (comp.object)
  • Re: OpenGL-based framebuffer concepts
    ... Agreed that kernel should only deal with necessary tasks as minimum as ... Designing the interface inevitably involves clear understanding of the ... hardware capabilities and closed hardware spec is an obvious obstacle. ... Open Graphics card would be a great thing ...
    (Linux-Kernel)
  • Re: Cubase SX or Pro-Tools M-Powered?
    ... electronic type composers, MIDI editing, sound stretching etc while ... besides a history lesson and marketing targets, they all employ a 'hyper-tape' type setup unifying audio, midi, and automation in one interface, but obviously going beyond the abilities of tape. ... ProTools would restrict your choice of hardware. ...
    (rec.audio.pro)
  • Funded Ph.D. Position - Formalising the Hardware/Software Interface, TCD, Ireland
    ... Formalising the Interface between Software and Hardware ... Software Systems Laboratory, ... hardware and software, with particular emphasis on Flash Memory ...
    (comp.theory)
  • Re: [openib-general] Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation
    ... The interface should be used ... > to map the hardware, there will always be opportunity for abuse. ... any faster than it would to invalidating a memory region. ... Instead it is allowed to block on such a request and only guarantees ...
    (Linux-Kernel)