Starting to write code in embedded systems from scratch can often be an overly ambitious undertaking that intensifies the pressure on developers trying to finish on schedule. However, recycled code may contain previously undetected errors or new incompatibilities that are triggered by software additions, updates to hardware or even changes in a compiler. To catch these errors and address other problems created by new reusing code, programmers can use static analysis software.
Using as much code as possible from previous software versions or existing libraries can be a valuable shortcut when building embedded systems. According to a recent survey by New Electronics, 84 percent of embedded software developers did so in their latest projects. While New Electronics praised this rate of adoption as a smarter coding practice, the publication also noted that around half of respondents reusing code had to retarget it to suit the specifications of different microcontroller.
Updates reveal latent bugs
Since some types of embedded systems may be subject to a fairly infrequent update cycle, the likelihood that hardware improvements have changed the needs of the program is considerable, contributor Paul Anderson noted in a column for Military Embedded Systems. The most common change is a new processor, which can introduce a different bit width or a new number of available cores. Much of the process of moving from one platform to another is likely to involve adapting code for these differences.
Similarly, the toolchain used to compile code may have been updated since the previous version, or the operating system hosting the software might have changed. Such modifications might reveal latent bugs because they process code in a slightly different way, Anderson noted. Some programs may have even come to rely on flaws in compiler software, and such components would be exposed by an update meant to correct these errors.
"Even if such code has been tested thoroughly and has proved reliable in practice in the old system, it might still contain latent bugs," Anderson wrote. "Those bugs might have never been triggered in the legacy system because of very specific properties of that system such as the toolchain used to compile the code, the processor architecture, or the host operating system. When ported to a new system where those properties are different, the latent defects might be manifest as harmful bugs."
Overcoming lurking issues with static analysis
Given the dangers of latent errors emerging in new software versions, thorough testing and pre-release analysis are essential parts of the coding process. The New Electronics survey found that 88 percent of developers use a debugger, while 65 percent employ a circuit emulator or Jtag debugger. Additionally, 34 percent use static analysis tools, which can prove particularly effective at finding errors that might evade other tests, Anderson wrote.
"A sensible tactic to flush out these latent defects is to use advanced static analysis tools as part of the legacy transformation effort … [Such tools] are especially good at finding concurrency defects such as data races that are exceedingly difficult to find using traditional testing methodologies," he said. "They are also good at finding instances of code that, while not definitively wrong, is highly correlated with errors or is particularly risky when ported to a different environment."
As vendors look to update legacy projects or incorporate code from existing libraries into their products, they should remember that such code saves time but does not come without some new risks of its own. By using the best source code analysis tools available, businesses can dispel such fears and keep embedded software stable across all versions.
Software news brought to you by Klocwork Inc., dedicated to helping software developers create better code with every keystroke.