It has been said that software is the most complicated system humanity has created and like all complicated things we manage this complexity by breaking the problem into small problems.  Each small problem is then solved and each solution is assembled to create larger and larger solutions.  In other fields of work, humans created standardized solutions to common problems.  For example, nails and screws are common solutions to the problem of fastening wood together.  Very few carpenters worry about the details of building nails and screws, they simply use them as needed.  This practice of creating  common solutions to typical problems is also done in software.  Software Libraries can easily be used to provide drivers, and advanced functions saving a developer many hours of effort.

To make a software library useful, the library developer must create an abstraction of the problem solved by the library.  This abstraction must interact with the library user in a simple way and hide the specialist details of the problem.  For example, if your task is to convert RGB color values into CMYK color values, you would get a library that had a function such as this one:

struct cmyk {
	float cyan;
	float magenta;
	float yellow;
	float black;
};

struct rgb {
	float red;
	float green;
	float blue;
};

struct cmyk make_CMYK_from_RGB(struct rgb);

This seems very simple and it would absolutely be simple to use.  But, if you had to implement such a function yourself you may quickly find your self immersed in color profiles and the behavior of the human eye.  All of this complexity is hidden behind a simple function.

In the embedded world we often work with hardware and we are very used to silicon vendors providing hardware abstraction layers.  These hardware abstraction layers are an attempt to simplify the use use of a vendors hardware and to make it more complicated to switch the hardware to a competing system.  Let us go into a little more detail.

Here is a typical software layer cake as drawn by a silicon vendor.  Often they will provide the bottom 3 layers and even a few demo applications.  The hope is you will create your application using their libraries.  The benefit for you is a significant time savings (you don't need to make your nails and screws).  The benefit to the silicon vendor is getting you locked into a proprietary solution.

Here is a short story about the early "dark ages" of computing before PC's had reasonable device drivers (hardware abstraction).

In the early days of PC gaming all PC games run in MSDOS.  This was to improve game performance be removing any software that was not specifically required.  The only sound these early PC had was a simple buzzer so a large number of companies developed a spectacular number of sound cards.  There were so many sound cards that PC games could not keep up adding sound card support.  Each game had a setup menu where the sound card was selected along with its I/O memory, IRQ, and other esoteric parameters.  We had to write the HW configuration down on a cheat sheet and each time we upgraded we had to juggle the physical configuration of our PC (with jumpers) so everything ran without conflict.  Eventually, the sound blaster card became the "standard" card and all other vendors either designed their HW to be compatible or wrote their drivers to look just like the sound blaster drivers and achieve compatibility in software.

Hardware abstraction has the goal of creating a Hardware interface definition that allows the hardware to present the needed capabilities to the running application.  The hardware can have many additional features and capabilities but these are not important to the application so they are not part of the interface.  So abstraction provides a simplification by hiding the stuff the application does not care about.  The simplification comes from focusing just on the features the application does care about.

So if the silicon vendors are providing these abstractions, life can be only good!... We should look a little more closely.

Silicon is pretty cheap to make but expensive to design.  So each micro controller has a large number of features on each peripheral in the hopes that it will find a home in a large number of applications.  Many of these features are mutually exclusive such as synchronous vs asynchronous mode in the EUSART on a PIC micro controller.  These features are all well documented in the data sheets but at some point it was decided across the entire industry that if there were functions tied to each feature they would be easier to use.  Here is an example from MCC's MSSP driver in SPI mode:

void SPI2_ClearWriteCollisionStatus(void)
{
    SSP2CON1bits.WCOL = 0;
}

Now it may be useful to have a more readable name for the WCOL flag and perhaps ClearWriteCollisionStatus does make the code easier to use.  The argument is that making this function call will be more intuitive than clearing the WCOL bit.  As you go through many of the HAL layers you find hundreds of examples of very simple functions setting or clearing a few bits.  In a few cases you will find an example where all the functions are working together to create a specific abstraction.  Most cases, you simply find the HW flags hidden behind more verbosely named functions.  Simply renaming the bits is NOT a hardware abstraction.  In fact, if the C compiler does not automatically inline these functions they are simply creating overhead.

Sadly there is another problem in this mess.  The data sheets are very precisely written documents that accurately describe the features of the hardware.  Typically these datasheets are written with references to registers and bits.  If the vendor provides a comprehensive function interface to the hardware, the data sheet will need to be recreated with function calls and function use examples rather than the bits and registers.

In my opinion the term HAL (Hardware Abstraction Layer) has been hijacked to represent a function call interface to all the peripheral functions.  What about Board Support Package (BSP)?  Generally the BSP is inserted in the layer cake to provide a place for all the code that enables the vendor demo code to run on the "HAL".  Arguably, the BSP is what the purist would call the HAL.

Enough of the ranting....How does this topic affect you the hapless developer who is likely using vendor code.

Silicon Vendors will continue to provide HAL's to interface the hardware, Middleware to provide customers with high function libraries and board support packages to link everything to their proprietary demo boards.  As customers, we can evaluate their offering on their systems but we can expect to write our own BSP's to get the rest of their software running on our final product hardware.

Software Vendors will continue to provide advanced libraries, RTOS's and other forms of middleware for us to buy to speed our development.  The ability to adapt this software to our systems largely depends upon how well the software vendor defines the expected interfaces that we need to provide.  Sometimes these vendors can be contracted to get their software running on our hardware and and get us going.

FW engineers will continue to spend a significant part of the the project nudging all these pieces into one cohesive system so we can layer our secret sauce on top.

One parting comment.

Software layers are invented to allow large systems to take advantage of the single responsibility principle.  This is great, but if you use too many layers you end up with a new problem called Lasagna code.  If you use too few layers you end up with Spaghetti code.  One day I would love to know why Italian food is used to name two of the big software smells.

Good Luck