I was thinking about how embedded software can be made more reusable across different hardware platforms.

Suppose we design the software in layers. At the top, we have the Application Layer, which contains the actual product logic. Below that, we have an Interface Layer that provides common APIs such as UART send, GPIO write, sensor read, and so on. At the bottom, we have the Hardware Layer, which contains all the microcontroller-specific code.

So the application talks only to the Interface Layer and does not know anything about registers or a specific MCU.

With this approach, I feel that if we change the hardware for example, from an STM32 to an NXP controller we should only need to rewrite the Hardware Layer and maybe adjust a small part of the Interface Layer, while the Application Layer remains exactly the same.

Similarly, if we add new features or change the product logic, we would modify only the Application Layer, without touching the lower layers.

This makes me think that it should be possible to build a mostly hardware-independent software architecture where only a small portion of the code needs to change when moving to a new platform.

Does this understanding make sense? Is this approach practical in real projects, and is this how portable embedded software is typically designed in industry?

I’d really appreciate your thoughts on this.

 

This is an approach that is used all over the place, including embedded systems. But there are penalties that come along with it in terms of code size, efficiency, and latency. If those penalties can be tolerated, then the approach makes sense. If they can't, which is not uncommon when dealing with resource-starved embedded platforms, the no matter how much sense it makes on paper, it is unworkable in the real world. There are, of course, hybrids of all kinds in which you leverage a layered approach as much as can be tolerated, but no more.