Small changes can leave variants off-colour
26 February 2009
Developers of embedded software probably don't think too much about coping with ongoing changes. It is easy to view variant management as someone else's problem. Not so, as Dave Robertson points out
When a company decides to produce different editions of a product containing embedded code, the development team may feel that others can cope with the necessary variations. Different versions of a motherboard created for different markets are the responsibility of the electrical engineers. The marketing
department is responsible for producing collateral promoting each edition of a device. And the technical writers are saddled with recrafting the documentation.
In reality, however, embedded application software developers should be paying close attention to the problem of variant management. They work with narrower constraints than their equivalents in the computer game development or enterprise software world. Efficiency in software design isn't optional for these coders; it is a fundamental requirement. Not only must they often eke out the available memory in relatively small footprint devices on a byte-bybyte basis, but they must do it multiple times for different editions of the product. Although they will work from the same broad code base, some variations in the software will be
needed for each of these editions. In the embedded development world, the variations between code written for different editions of a product are not huge. However because the code is tied so closely to the hardware,
an incorrectly coded variant could have devastating effects, not just on system performance, but on its ability to function at all. Consequently, they must be managed effectively to avoid confusion as the products evolve.
Embedded developers grappling with variant management must understand what is different between the software that they write for each edition of the product, and what is the same. Unless they keep track of these differences effectively, they will find themselves reproducing the same work for multiple editions of the product. Not only does that impose an unnecessary development overhead, but it also introduces more risk. Bugs may find their way into the product because the same functions are being rewritten multiple times,
possibly by different team members, in different ways. It makes sense to automate the process as much as possible.
The tools to help automate this process should be a critical part of any embedded development team's arsenal. Software configuration management (SCM) tools can help embedded software developers to keep track of their code, but not all SCM tools are created equally.
All modern SCM tools manage these problems using branching. When a developer needs to code a variant of the software for a different platform or market, the traditional method involves copying a set of source code files so that they can be worked on independently of the main code. When this happens, the system effectively copies the code into a branch, so that the developer can work on it without affecting the main trunk of the code.
But many older SCM tools behave in a way that any good embedded developer would dislike: inefficiently. They waste space and system resources, which can have an adverse effect on developer performance. These tools blindly copy code to new branches without checking the differences between the original code and the new version that a developer is working on. A developer working on a large number of C libraries, or assembly listings could find themselves copying megabytes of working files between different branches when in reality only a few kilobytes have changed.
This may not present a huge problem for a developer on version 1.1 of a project. But what about version 1.11? Or version 1.2? Or the maintenance release for embedded systems that are firmwareupgradable in the field? Before long, the system becomes unmanageable. In the worst case scenario, the development team may stop using it altogether and revert to manual folders containing different code streams.
There is a better way to do SCM without hindering an embedded development team's activities or tying up their systems. The concept of 'lazy copying' uses pointers to more effectively manage their code base. Instead of copying a whole set of files to a new branch, the SCM software uses pointers to refer to the original files. An embedded software developer working on a new branch will see all of the files, logically
represented on the system, as though they were copies of the originals. But the only time a new file is physically created on disk is when the developer alters it.
By reducing the storage and processing overhead incurred by the SCM system, this lazy copying approach also brings another benefit: better performance. Developers trying to squeeze as much functionality as possible into a small space will appreciate the chance to experiment with alterations that could make their code more elegant without having to wait for an overloaded system to catch up.
The benefits of a lazy copying approach become more obvious as an embedded development team puts more data into the SCM system. To truly take advantage of a modern, capable SCM tool, developers should
be putting far more than source code into it. An SCM tool should be able to support compiled binaries and text files. Embedded developers will need to store and refer to a variety of digital assets, including everything
from architecture documents through to circuit board designs. Because they will be writing variants for different platforms, they may even wish to store emulator packages representing different versions of a target platform inside an SCM infrastructure. Because a mistake in embedded software design can potentially affect the functionality of a whole system, testing must be thorough, and should be conducted for each variant of an embedded code set. The tests, too, must be documented and managed. The more that the team can rely on the system, the more likely it is to store all of the assets related to a project in one place. That will increase productivity and throughput, and encourage them to try new approaches to embedded design and development.
Let's not also forget the need to work with multiple team members, often remotely. We live in a world that encourages centres of excellence, especially in highly-specialised areas of code design. The Scandinavian region is known for its excellence in mobile phone software development, but what about the software radio code that makes it 4G ready, or the embedded codec that makes video calling possible? The primary contractor for the device may be working with a Chinese team that are experts in developing geographical
positioning system code, while the handwriting recognition team may be located in Bangalore. A good SCM system will support such outsourced, inter-company teams even when spread across the globe.
This is a good example of how business needs and SCM tool features are linked. A good SCM tool should be able to cache branches of code locally at dispersed geographical sites, again using pointers to original files. The combination of pointer usage and file caching where necessary means that local developers can restrict most network activity to the local area network when making changes. That minimises network overhead, which can be significant in outsourced locations where network reliability and throughput isn't as good as it is at a primary development site.
This caching should therefore be a musthave in any RFP because even if an embedded team doesn't need it now, it will doubtless require it in the future as business conditions force companies to source expertise from overseas.
Because those development teams are probably using different IDEs to produce their embedded code, it is also necessary for an SCM tool to integrate with many different tools. An open architecture is an important
feature to look for in SCM software so that developers can bring their own development environments to the process and feed their source code into the development cycle with minimal fuss.
In many ways, then, an SCM system should be just like a well-written piece of embedded code. It should be unobtrusive, serving as a frictionless element whose elegance enables a wider system to function without interruption. But there are other requirements, too. It should operate seamlessly with other systems, so that it can integrate assets from whichever testing, application design or requirements gathering tool a development team uses. And it should also be easy to learn, so that embedded programmers can get on with doing what they're good at - taking excellence and squeezing it into small packages.
DAVE ROBERTSON is director of Europe for Perforce Software.
Contact Details and Archive...
Related Articles...
Most Viewed Articles...