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.

Where do you begin?
When you start a project, there is at least a small set of driving ideas or requirements. This is the time to begin designing a hardware-free system. What are you trying to accomplish? What is the end goal? What is going to be driven, monitored or controlled? Once you encounter some hardware, work out all the pieces in the signal chain.

Each piece of hardware you find that connects to another piece of hardware is a potential point of disruption if it is swapped for another. Isolate each piece of hardware within a wrapper or interface. For a motor control design, look at the algorithm. What are the pieces of data used to determine the drive commands?

To the control algorithm, these should always look logical, no matter what hardware is used, whether it is a load current in amperes, or a speed in revolutions-per-minute, or a drive command in percent.

Between the hardware and the algorithm, a load current is converted to a voltage, which is sampled by an ADC and becomes a digital count, which is converted by a math function to milliamperes; each of these steps need to be "wrapped" to eliminate the impact to the software application if the underlying hardware changes.

If you follow this path throughout your design process, at the end you will see two things. First, you will see how your hardware relates to your final system, and therefore understand how a new, similar but different, project can benefit from your work. Second, someone designing a brand new project in a completely different type of application can take your project and adapt it to fit their project, replacing or removing layers that change due to the new application.

That big, complex, board support package for the microcontroller that used to be the domain of a single whiz-kid or specialty group (who always seems to be too busy to make changes when desired) has now been logically de-constructed and piece-wise associated with the functions it serves, enabling this knowledge to disseminate to the entire group.

Remember how back in college, even if you didn't get the right answer on an exam, if you worked through the problem in a clear, logical, methodical and organized fashion (comments helped, too), you still could get a fair amount of partial credit on an exam? The same is true here.

While you do not need to be rigidly organized, if you collect your wrappers and interfaces together logically, you can replace actual hardware pieces easier. For instance, If you collect all the wrappers and interfaces that are directly associated with your microcontroller in one place, changing the microcontroller at the last minute becomes easier than if these are sprinkled throughout many files.

How it works - by example
Let's take an example application, a fan whose speed is monitored and controlled according to temperature, and try to walk through the design process, designing-out the hardware as we go along. As we begin the project, the few things we know are that

1) we need to get a temperature reading,
2) we need to compute a desired fan speed based upon temperature,
3) we need to get a current fan speed reading,
4) we need to compute a new fan command based upon the current fan command and error between the desired and the current fan speed reading, and 5) we need to put the new command out to the fan.

Figure 1 below shows the logical block diagram of the system. The rectangles are hardware dependent, the ovals are not. The way this is shown, a control engineer can begin system development, perhaps using a simulation package like MatLab, and the results of his/her work can directly feed into the end design (especially if it is written in a high-level language like C which almost every microcontroller supports).

Figure 1: Simple Fan Control System

Now as the project proceeds, a decision is made to use a thermistor as the temperature sensor (maybe because it is cheap, or it has specific desirable properties).

Looking at Figure 2 below, the "Get Temperature" rectangle is expanded into separate hardware dependent functions associated with the thermistor design, including the hardware characteristics of the thermistor and its interfacing circuitry.

Temperature is represented by the device as a resistance, with signal conditioning circuitry the resistance is represented as a voltage, using the ADC described the voltage is converted to a count value between 0 and 4095, and with software the counts are converted to a temperature in a machine-storable representation (for instance fixed point value temperature with the resolution of 0.1 degrees Celsius).

We have put the temperature into a data store so that its value can be updated asynchronous to the control algorithm. This makes the temperature always as current-as-possible for the control algorithm and better isolates hardware from software.

Figure 2: Thermistor Sensing Details

Later, it is determined that for this design, the microcontroller will not be near enough to the temperature hot-spot to use a thermistor, running the analog lines all the way from the thermistor to the microcontroller pins introduces too much opportunity for noise and signal loss.

Instead we will install in the temperature zone an integrated circuit, an LM75 I2C temperature sensor, that converts temperature locally and provides a digital value onto an I2C bus as a slave device.

Now in order to get a temperature, as shown in Figure 3 below, we have to enable I2C master communications hardware in our microcontroller, read a particular set of registers in the LM75, convert the temperature from native representation (the least significant bit represents 0.125 degrees Celsius) to our previously chosen temperature representation (fixed point value temperature with the resolution of 0.1 degrees Celsius).

Figure 3: I2C Digital Temperature Sensor Details

Because we isolated our control software, even from the actual rate at which new temperature readings occur, the control application software has not been impacted at all by this hardware change.

And any peculiarities associated with the LM75 can be tucked into one of the blue rectangles of Figure 3 above, exposed to scrutiny and verification without having to disturb the control software.

For instance some of these devices start a new conversion each time the I2C master reads the temperature value/register and if this access occurs too fast or too often, the LM75 will not finish a conversion. The control algorithm doesn't need to care about these details.

Abstracting Your Microcontroller
Our example purposely changed the hardware outside of the microcontroller to make a more universal point, but the same process applies if the microcontroller hardware changes.

If we started with the thermistor design of Figure 2 and changed our microcontroller, the commands to configure and access the ADC would change, the register sequence to multiplex and sample the inputs would change and perhaps the counts-to-temperature conversion would change.

But since these were all tucked neatly into rectangles (representing functions and/or macro definitions and calls) simply replace the contents of the rectangles with the new instructions required by the new microcontroller, and, voila! hardware changed, but software is unchanged.

While I haven't yet come across an embedded design tool that make these changes for you when switching between one microcontroller vendor and another, many vendors do provide wizards to set-up the hardware initially, which does make the process of changing hardware, choosing a new device offered by the same vendor, relatively straightforward.

When it comes to making it easier to design-out hardware, microcontroller companies are striving to simplify the process a few steps further by employing hardware abstraction within their software development tools. The peripheral functions of microcontrollers are selected by users from a catalog of choices, depending upon what the application requires, and can be added or removed from the design as the needs change.

By employing generic instance names, like PWM1 or ADC, the user can change his/her mind about the actual hardware function details and let the tool manage the first layer or wrapper of abstraction. For instance in Figure 2, if an incremental (integrating) ADC is desired rather than the SAR (successive approximating) ADC, the tools would automatically make the changes to the middle light blue rectangle.

Abstraction can even be carried to a higher level. For example, with the PSoC Designer and PSoC Express visual embedded design tools for the PSoC Mixed-Signal Array devices, the software by default employs a hardware abstraction method and generates all the layers automatically (Blue elements in Figure 2 and Figure 3 earlier).

In order to modify the thermistor, the user selects "Thermistor" from a catalog in PSoC Express, defines the "Compute Desired Speed" control algorithm, and the development tool presents which PSoC devices are available with the necessary resources for the application.

Upon selecting a device, the tools generate the necessary firmware to read, convert and store the thermistor temperature in fixed-point format into a data structure and make it available to the "Compute Desired Speed" algorithm.

If the specifications of the thermistor change, the user can select a different PSoC device, adjusting for memory, pin-count, cost, etc. Only those device with the necessary resources for the application will be displayed and the hardware abstraction layers will be regenerated without impacting the control algorithm.

One day, all projects will have reasonable schedules, marketing will decide in advance exactly what customers want, write it down and not change its mind, and application software with all desired features will fit within the memory space of the chosen microcontroller.

But until that day arrives (I'm not holding my breath yet), you can reach a reasonable facsimile of embedded utopia by designing your embedded systems to isolate all hardware in neat wrappers and layers, uncoupled from the control software.

Then look out the window, breathe deep, take a moment to notice an eagle high in the sky circling for its prey, and then turn your attention back to marketing's urgently demanded last minute changes to satisfy (insert name of your favorite disruptive customer here).

Jon Pearson began designing commercial embedded systems in 1986 for commercial aircraft, telecommunications satellite systems and notebook computers. Jon has been driving marketing efforts at Cypress Semiconductor since 2000 when the first Programmable System-on-Chip mixed-signal array devices were created. Currently Jon leads the development tools marketing efforts for PSoC and other programmable devices. You can reach him at jpx@cypress.com.