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

formatting link

Reply to
Vladimir Vassilevsky
Loading thread data ...

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
Reply to
Rene Tschaggelar

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.

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

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

VLV

Reply to
Vladimir Vassilevsky

Reply to
Jonathan Kirwan

Perhaps this ?

formatting link

-jg

Reply to
Jim Granville

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.

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

Rene

Reply to
Rene Tschaggelar

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

Reply to
Rocky

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
 Click to see the full signature
Reply to
Michael N. Moran

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

Reply to
Rocky

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.

Reply to
Arlet

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)

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.

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.

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

Reply to
Rocky

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.

Reply to
Arlet

[...]

And it can take weeks of digging through the manuals, trials and errors to do the initialization properly.

There is another aspect: when a new guy gets involved into the project, it takes him a month of hard work just to understand the dependencies and know what is already available.

Depending on the families, there are

Why not. For example, I can describe this feature as a class derived from the basic PWM class.

That's why the concept should allow for the flexible expansion.

This is how it is done now, and I can feel more and more that this is not the right way.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

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

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

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

For example, a having the

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

formatting link

Reply to
Vladimir Vassilevsky

[%X]

I am presuming that most of you already do abstraction of software functions and I would have thought the same sort of thing would be applicable to hardware also.

As one who leaves decisions of what is software and what is hardware until quite a bit later in the project than most I have never seen any problem with abstracting the functions in such a way that the decision on hardware/software split can be delayed.

I know that the way I do it will not suit everyone out there. My HAL and SAL are in Forth pseudo code. The function names are usually descriptive enough to be able to select some of them from an archived library of functions. One has to remember that none of it is finished code but just a way that, with a little effort (mostly completing the coding work), can lead to testing of design decisions before any scrap of hardware is available. It is akin to building a hardware simulator under the application software.

--
********************************************************************
Paul E. Bennett ....................
 Click to see the full signature
Reply to
Paul E. Bennett

[snip]

A matter of the language. There are some that want you write PortA &= ~bit(1 bool readAtPin()

Also a matter of the language. The awkward language I'm talking about was never extended to cover controllers too. If the language is simply not readable, a set of API which is made to enhance readability and is basically a macro or a to-be-optimized-away function call is not really efficient.

Rene

Reply to
Rene Tschaggelar

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.