As an integrated software engineer, it is easy to think that all product software is hardware dependent. Most embedded developers want to get to a development board early on and start writing software, including myself. It is not necessarily wrong; it is only familiar and allows us to understand the complexities and problems of the hardware. However, if we design our application code correctly, we can use simulation and testing on most of our code without the underlying hardware. There are several different ways for a developer to simulate their code to prove it before actually integrating it into the hardware.
First, and perhaps the easiest way to simulate the code, is to develop and test it on a PC. Developers can use GCC or G ++ to run their code on a computer and then generate and verify the output. It is very easy for Linux and Mac developers to do this, as they directly access a terminal that supports GCC or G ++. Windows developers may need to install Cygwin or Mingw, which is very easy to set up.
Previously, I mentioned that properly designed software can be simulated or tested on a PC. Properly designed software is architected to minimize dependencies and designed to be flexible and isolate components. The latter architecture allows them to be executed and tested without bringing the entire code base. They can be run on the PC and the inputs can be fed through a file. Then, the outputs can be recorded in a file to be analyzed or even plotted, if necessary.
A good example of this technique comes from one of my recent projects, where we concentrated most of our software development efforts on the final hardware, since it was available. Eventually, we encountered a problem where an application algorithm was simply not providing the expected output. It was close, but it just wasn’t right. This left us with an interesting question: “Was there any interaction with the hardware or RTOS, or was the algorithm just coded incorrectly?”
Typically, an embedded software developer would play with the software on the hardware for weeks trying to figure out what could be causing the problem. In this type of situation, a team is betting on finding a solution in any reasonable period of time. Due to the way the software was designed and implemented, I was able to extract the algorithm, which would be considered hardware dependent, and wrap it in a test code that I ran on a PC. I was then able to plot the production and compare it to the expected results.
This allowed a developer to perform a sanity check on the part of the software. If it did, there was a problem with the way the algorithm was integrated into the built-in processor. If it doesn’t, implementation C needed some tweaking.
This leads us to a second option to simulate embedded software, that is, using a tool like Matlab. Matlab can allow a team to simulate state machines, algorithms and investigate how a system will behave. In fact, in many automotive and aerospace applications, teams even allow Matlab to generate the integrated code for them, and the team then just needs to maintain its model.
In the example above, the algorithm I was working with was simulated in Matlab. I knew exactly what I was supposed to produce based on known inputs. Comparing the embedded C code simulation with the Matlab output provided the details to show if there was a problem with the algorithm or something in the embedded system.
The simulations can also help the embedded developer to understand the system as a whole. Sometimes we blindly implement algorithms without really understanding how they work, what the inputs mean and what the outputs for those inputs should look like. Sometimes we can get away with it, but it is often critical that the developer understands the details if a problem arises.
Simulation can help with this, especially if all buttons and dials are included. A developer can increase parameter A and see how it changes the output. Then parameter B can be adjusted and so on until they fully understand how the system can work. I found that, in many cases, the problem is not so much the algorithm, but its interaction with real-time behavior.
Embedded software developers don’t have to rely on the hardware to get the job done. It’s great when hardware is available and can allow developers to overcome hardware obstacles. At the end of the day, however, many algorithms and application features can be simulated and tested off-target. This simulation can prove that the system is working the way it should or help to solve problems of small nuances that could take a considerable time to debug. Developers need to add off-target simulation to their bag of tricks, if they’re not already doing so.
Jacob Beningo is an integrated software consultant who currently works with clients in more than a dozen countries to dramatically transform their businesses, improving product quality, cost and time to market. He has published more than 200 articles on embedded software development techniques, is a highly sought-after speaker and technical instructor and holds three degrees, including a Master of Engineering degree from the University of Michigan. Feel free to contact him at email@example.com on his website www.beningo.comand sign up to receive your monthly Embedded Bytes newsletter.