For smoother embedded systems development, design-out the hardware -

For smoother embedded systems development, design-out the hardware

All embedded systems eventually connect to hardware such as externalsensors and actuators or internal functional blocks and peripherals forinput/output, data storage and communication. Each bit of hardware inevery design has its own idiosyncrasies a designer has to wrestle with.

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

Designing-out the hardware means separating all control andalgorithmic software from the hardware-interfacing software. Bylogically constructing wrappers and interfaces around all hardware youcan replace, at any time, the particular hardware in use with a logicalalternative without impacting the control and algorithmic software.

Abstracting hardware with understandable, logical interfaces (functions, macros, symbols) makes adesign more portable and enables developers to concentrate on solvingthe real application problems, even before the hardware design is set.It sounds so easy and straightforward, and you may even think this iswhat 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. Ifswitching to a different microcontroller, especially from a differentvendor, would be a major disruption, you have designed-in the hardware.

To successfully design-out the hardware you must design with a newmindset. Rather than waiting to begin developing the embedded softwareuntil the hardware is completely designed, and waiting to finalize thehardware selections until all requirements are fully specified, insteadseparate the “what” from the “how” in your design and you can startmaking serious headway on your project while marketing is stillprancing out straw-dogs in front of key customers. After all, when isthe hardware ever truly done and not subject to change?

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

What does it mean to “Design-Outthe Hardware”
In its simplest form, designing the hardware out of your embeddedsystem means logically isolating the embedded application software fromdirect contact with all hardware. All hardware means ANYTHING thatcould change if the physical design or selected microcontroller ischanged.

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

But don't forget the common elements like input/output ports andembedded memory; if a change in these could impact the application (forinstance the non-volatile memory used for logging data or storingconfiguration choices, or the input port which may provide internalpull-ups or built-in drive circuitry). ALL hardware must be designedout.

Some readers may already have got the point and are thinking “Sowhat's new about that?” Thousands of years ago the wise King Solomonwrote that “there is nothing new under the sun”. The ideas behinddesigning the hardware out of your embedded project are not new.Engineers have been constructing wrappers or interfaces around theirhardware 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 tothe logical extreme, you still have a project dependent upon thehardware and do not have the flexibility to change the project hardwarewhen needed. I hope to impress upon you a greater sensitivity to theimpact of hardware selection on the embedded design and provide tipsfor 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 drivingideas or requirements. This is the time to begin designing ahardware-free system. What are you trying to accomplish? What is theend goal? What is going to be driven, monitored or controlled? Once youencounter some hardware, work out all the pieces in the signal chain.

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

To the control algorithm, these should always look logical, nomatter 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 convertedto a voltage, which is sampled by an ADC and becomes a digital count,which is converted by a math function to milliamperes; each of thesesteps need to be “wrapped” to eliminate the impact to the softwareapplication if the underlying hardware changes.

If you follow this path throughout your design process, at the endyou will see two things. First, you will see how your hardware relatesto your final system, and therefore understand how a new, similar butdifferent, project can benefit from your work. Second, someonedesigning a brand new project in a completely different type ofapplication 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 microcontrollerthat used to be the domain of a single whiz-kid or specialty group (whoalways seems to be too busy to make changes when desired) has now beenlogically de-constructed and piece-wise associated with the functionsit serves, enabling this knowledge to disseminate to the entire group.

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

While you do not need to be rigidly organized, if you collect yourwrappers and interfaces together logically, you can replace actualhardware pieces easier. For instance, If you collect all the wrappersand interfaces that are directly associated with your microcontrollerin one place, changing the microcontroller at the last minute becomeseasier 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 andcontrolled according to temperature, and try to walk through the designprocess, designing-out the hardware as we go along. As we begin theproject, the few things we know are that

1) we need to get atemperature reading,
2) we need to compute a desiredfan speed based upon temperature,
3) we need to get a current fanspeed reading,
4) we need to compute a new fancommand based upon the current fan command and error between thedesired and the current fan speed reading, and 5) we need to put the new commandout to the fan.

Figure 1 below shows thelogical block diagram of the system. The rectangles are hardwaredependent, the ovals are not. The way this is shown, a control engineercan begin system development, perhaps using a simulation package likeMatLab, and the results of his/her work can directly feed into the enddesign (especially if it is written in a high-level language like Cwhich almost every microcontroller supports).

Figure1: Simple Fan Control System

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

Looking at Figure 2 below, the “Get Temperature” rectangle is expanded into separate hardwaredependent functions associated with the thermistor design, includingthe hardware characteristics of the thermistor and its interfacingcircuitry.

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

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

Figure2: Thermistor Sensing Details

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

Instead we will install in the temperature zone an integratedcircuit, an LM75 I2C temperature sensor, that converts temperaturelocally 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 enableI2C master communications hardware in our microcontroller, read aparticular set of registers in the LM75, convert the temperature fromnative representation (the least significant bit represents 0.125degrees Celsius) to our previously chosen temperature representation (fixed point value temperature with theresolution of 0.1 degrees Celsius ).

Figure3: I2C Digital Temperature Sensor Details

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

And any peculiarities associated with the LM75 can be tucked intoone of the blue rectangles of Figure3 above , exposed to scrutiny and verification without having todisturb the control software.

For instance some of these devices start a new conversion each timethe I2C master reads the temperature value/register and if this accessoccurs 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 themicrocontroller to make a more universal point, but the same processapplies if the microcontroller hardware changes.

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

But since these were all tucked neatly into rectangles (representingfunctions and/or macro definitions and calls) simply replace thecontents of the rectangles with the new instructions required by thenew microcontroller, and, voila! hardware changed, but software isunchanged.

While I haven't yet come across an embedded design tool that makethese changes for you when switching between one microcontroller vendorand another, many vendors do provide wizards to set-up the hardwareinitially, which does make the process of changing hardware, choosing anew 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 fewsteps further by employing hardware abstraction within their softwaredevelopment tools. The peripheral functions of microcontrollers areselected by users from a catalog of choices, depending upon what theapplication requires, and can be added or removed from the design asthe needs change.

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

Abstraction can even be carried to a higher level. For example, withthe PSoC Designer and PSoC Express visual embedded design tools for thePSoC Mixed-Signal Array devices, the software by default employs ahardware abstraction method and generates all the layers automatically (Blueelements in Figure 2and 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 devicesare available with the necessary resources for the application.

Upon selecting a device, the tools generate the necessary firmwareto read, convert and store the thermistor temperature in fixed-pointformat into a data structure and make it available to the “ComputeDesired Speed” algorithm.

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

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

But until that day arrives (I'm not holding my breath yet), you canreach a reasonable facsimile of embedded utopia by designing yourembedded 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 aneagle high in the sky circling for its prey, and then turn yourattention back to marketing's urgently demanded last minute changes tosatisfy (insert name of your favorite disruptive customer here).

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

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.