All embedded systems eventually connect to hardware such as external sensors and actuators or internal functional blocks and peripherals for input/output, data storage and communication. Each bit of hardware in every design has its own idiosyncrasies a designer has to wrestle with.

Change any element of the hardware used in the design, even just adding or subtracting an input or output port, and the embedded software is impacted, sometimes severely. Make these changes late enough in the schedule and your product won't go out on time. Unless, that is, you completely design the hardware out of your system.

Designing-out the hardware means separating all control and algorithmic software from the hardware-interfacing software. By logically constructing wrappers and interfaces around all hardware you can replace, at any time, the particular hardware in use with a logical alternative without impacting the control and algorithmic software.

Abstracting hardware with understandable, logical interfaces (functions, macros, symbols) makes a design more portable and enables developers to concentrate on solving the real application problems, even before the hardware design is set. It sounds so easy and straightforward, and you may even think this is what you or your team already does.

But take a hard look at your current project (or favorite past one) and consider what would happen if you changed the microcontroller. If switching to a different microcontroller, especially from a different vendor, would be a major disruption, you have designed-in the hardware.

To successfully design-out the hardware you must design with a new mindset. Rather than waiting to begin developing the embedded software until the hardware is completely designed, and waiting to finalize the hardware selections until all requirements are fully specified, instead separate the "what" from the "how" in your design and you can start making serious headway on your project while marketing is still prancing out straw-dogs in front of key customers. After all, when is the hardware ever truly done and not subject to change?

Beginning the design process using this approach yields greater overall flexibility, both because the hardware CAN be swapped at almost any time and because the fear of change disappears. Additionally, debugging becomes easier since hardware-specific features are localized in the wrappers and interfaces, which also increases the number of opportunities to leverage IP from project to project.

What does it mean to "Design-Out the Hardware"
In its simplest form, designing the hardware out of your embedded system means logically isolating the embedded application software from direct contact with all hardware. All hardware means ANYTHING that could change if the physical design or selected microcontroller is changed.

This includes obvious things like support hardware within the selected microcontroller, like the Analog-to-Digital converter (ADC),and the communications interface (UART, SPI, I2C, USB, CAN), but if the physical system design includes sensors and actuators, these also impact software if changed and therefore must also be designed-out.

But don't forget the common elements like input/output ports and embedded memory; if a change in these could impact the application (for instance the non-volatile memory used for logging data or storing configuration choices, or the input port which may provide internal pull-ups or built-in drive circuitry). ALL hardware must be designed out.

Some readers may already have got the point and are thinking "So what's new about that?" Thousands of years ago the wise King Solomon wrote that "there is nothing new under the sun". The ideas behind designing the hardware out of your embedded project are not new. Engineers have been constructing wrappers or interfaces around their hardware since the beginning of modern embedded systems design (which I peg at circa 1980).

The point of this article is that unless you take this approach to the logical extreme, you still have a project dependent upon the hardware and do not have the flexibility to change the project hardware when needed. I hope to impress upon you a greater sensitivity to the impact of hardware selection on the embedded design and provide tips for removing the impact of hardware changes on future designs.