Thanks, Javi the comment! I don't use POSIX layers too often, but I definitely agree that it can be very useful. I'll give this topic some thought for a future talk at the conference, or in some other form. Thanks!

Jacob: Thanks for the comments and questions. Let me try to answer some of these for you.

Question: Now on a slides where different drivers are switched under the HAL, what is the HAL in that case?
Jacob: The HAL should be a header file that defines what the driver interface. The interface might or might not match the driver implementation functions.

Questions: Could you provide some examples what HAL above the drivers consists of? This looks like unchangeable part of the software.
Jacob: For an I2C driver, this might look something like the following:

typedef struct {
bool (Init)(uint32_t (Time_Get)(void));
bool (Write)(uint16_t const SlaveAddress, uint8_t const const Data, uint32_t const DataLength);
bool (Read)(uint16_t const SlaveAddress, uint8_t Data, uint32_t const DataLength);
bool (WriteRead)(uint16_t const SlaveAddress, uint8_t const const Data, uint32_t const DataLength, uint8_t * const DataOut, uint32_t const DataOutLength);
}I2C_t;

then you can assign whatever function you.

static I2C_t I2C0 = {.Init = I2C_Initialize,
.Write = I2C_Write,
.Read = I2C_Read,
.WriteRead = I2C_WriteRead};

If you have library functions for an MCU that don't match that pattern, you can create an implementation. For example, you can create your own mapped function that uses your MCU vendor drivers:

static bool I2C_Initialize(uint32_t (*Time_Get)(void)) {
assert(Time_Get != NULL);
SystemTime_Get = Time_Get;
SERCOM0_I2C_Initialize();
return true;
}

Question: Also, from the practical point of view, is it really achievable to get to a pack of interfaces that are well defined and stable so you really stop fiddling with them and able to switch drivers back and forth?
Or in reality, once starting this route of HALs, you're bound to support and modify all your old drivers to an interface you come up with for a newer ones.

Jacob: I think it is possible. It does depend on your company needs and projects though. I have interfaces that I've used for years with different clients and projects that haven't changed.

Question: And how to come around the fact that even simple things like SPI and UART vary greatly between different hardware implementations? How do you implement specific behavior? Do you make specific functions for one implementation and define them as NULL for another?

Jacob: You could have some functions that are just NULL. Typically, I define the core set of functionality for a peripheral. If one MCU has an extra feature like a speed boost, validation, etc, I extend my HAL interface in a separate header to cover those functions. They are then just used for that specific chip.

Thanks!