Basing an embedded device on Free and Open-Source Software (FOSS) brings many advantages, not the least of which is complete control over the software stack and free reuse of existing high quality solutions. However, it also means having to deal with large amounts of code, mainly coming from external parties. Coping with this can be a challenge for small embedded teams, used to smaller stacks developed in-house.In this series of articles, we take a step by step tour of good software development processes and how to use them to improve your organisation. We emphasise embedded development and point out particular pitfalls to avoid.
In this first part, we focus on the evolution of embedded systems, how this fuels use of FOSS, and what effect this has on your organisation. Future parts will discuss tools supporting the software development process, testing and debugging of embedded systems using FOSS, and FOSS components that you can use in embedded projects.
Embedded systems evolution
As hardware technologies continue to improve, features which were previously only available in high-end desktop applications start trickling down to the embedded sector. Single-vendor 8-bit and 16-bit embedded processors are on their way out in many applications, and the bulk of development is moving onto 32-bit MIPS or ARM targets, capable of running full-blown operating systems similar as those used on desktop platforms. At the same time, both Flash memory technology and LCD screens have made both technological and economy-of-scale advancements that allow high resolution LCD screens to be available at low cost, backed up by Flash storage capable of storing matching high resolution graphics and sound.
These technological advancements are pushing user expectations. Gone are the days where one could get by with 8-segment LED displays coupled with 2-button operation. A modern device is expected to contain a high-resolution touch screen with an appropriate GUI on it. Likewise, data going in and out of the device is no longer coming in over serial cables or floppy disks, but is supplied via USB Mass Storage devices and SD cards, if not via a TCP/IP network running over a WiFi link.
The challenge facing the embedded systems developer is hence the need to deal with a significantly larger infrastructure below his own applications, to support this advanced functionality.
FOSS based embedded systems
The infrastructure required to support all the advanced features that a user expects is simply too large to be developed completely in-house. You will therefore have to look for and integrate existing software components. Using Free and Open-Source Software (FOSS) components (as opposed to commercial software) has several advantages.
By reusing existing FOSS solutions, embedded developers no longer need to reinvent the wheel for functionality that is common or non-specific to their own product. Furthermore, prototypes and proof-of-concepts can be developed without the need to make large investments in software. If the final product goes to the market, there will be no overhead from the need to pay royalties either.
Beyond this, the core principle of FOSS, namely the ability to access and modify all parts of the software stack result in an increase in flexibility as well as a reduction of risks. Indeed, the system is not limited by what an outside party decides to support or provide, but can be extended in the direction the system builder considers
Because FOSS is a large ecosystem and there are hard guarantees that the software remains free, it’s almost impossible to get locked-in by a single vendor. Support and services for FOSS software is available from a large number of commercial vendors and and non-commercial developers, which compete freely.
There is a general mindset underlying the development of most FOSS software, that promotes portability and open standards. For the embedded developer, this, together with the available of source code, means that FOSS software can often be expected to be portable to different devices than those the code was originally written for. This
means that in addition to commoditizing the software foundations, FOSS can also help you commoditize the hardware, by keeping your options open and allowing you to weigh the pros and cons of different hardware vendors.
The biggest advantages of FOSS can be reaped when you work with the community. This can be as simple as submitting bug reports. Indeed, a bug report from a seasoned developer is worth 10 times more than one of an innocent user. Submitting bug reports helps getting your bugs fixed, but indirectly also increases developer motivation to maintain the software. Bug reports mean that the software is being used, which is the key motivator for many free source software developers. Submitting patches is even better, of course. If it gets accepted, it will be easier for you to upgrade to future releases. If it doesn’t get accepted, you’ll usually be informed why your patch isn’t good enough, which may help you improve the quality of your own software. And either way, it gives the core developers some insight in how the software is used, which may lead them to implement a feature that is even more useful for you. Even if you don’t see the benefit of working with the community in a particular case, taking on that habit will make it easier for you next time you do see the benefit.
One of the often-quoted problems with FOSS by managers who don’t know about it is the licensing. Indeed, the license compliance policy is important to look at when integrating FOSS components. However, there is no essential difference compared to the legal issues when choosing a software supplier, except that your legal personnel probably has more experience with closed licenses.
That said, it is essential to have a well thought-out policy in place about FOSS licenses. Which licenses are acceptable for which parts of the system? For a quick comparison chart of the most popular licenses, see the new media rights open source licensing guide. Which type of changes should be fed upstream and which ones should be kept secret? Without a policy for these questions, developers may shy away for using the full potential of FOSS, or may contaminate your system with a too restrictive license.
To avoid license issues, it is a good idea to prepare tarballs of the (L)GPL components as part of the release script. Even if you don’t put them on the embedded system itself, you at least have them ready when they are needed. If you don’t do this, you expose yourself to harassment from FOSS prosecutors. For example, binary analysis tools exist that can detect open source software in binary firmware images.
A critical question to ask yourself is where your own added value lies in the entire product. If your hardware consists of a slightly modified reference board from the vendor, combined with a pile of unmodified open source packages and some minimal glue between them, then you might make it to the market really quickly and at minimal
development costs, but it will also be exceptionally easy for any competitor to step in, do the same, and undercut your price. After all, the exact same FOSS is also available to him. Therefore, you have to identify your key differentiator. A key differentiating area can be the hardware itself, which may provide functionality or performance not available in competing devices. Second, you might focus on the software and, on top of the software stack, you might have your own, innovative
application. Third, your business case may consist simply of customizing the stack to the exact needs of your customer. Lastly, you may use the system as part of a larger product or service that you supply to your customer and not sell it on its own.
Integrating FOSS in the development process
Reusing existing software stacks to quickly get to a high level of functionality does come with some more unpleasant consequences. It will impose higher demands on your software development process. For starters, there will suddenly be much more code to deal with, including large amounts of code that did not originate within your organisation and will not conform to any development guidelines you might have set. This code comes from a large number of different developers, including ones that are not part of your organisation but belong to the FOSS community.
Eventually, the increased emphasis on dealing with the software aspects will lead to a shift of focus in the organisation. Software will no longer become a byproduct to the hardware platform, but a more important entity critical to how the public perceives the product. You will shift from being purely a hardware company to being a company that deals with both hardware and software.
This requires the establishment of good processes for software development, continuously improving the ones that might already have been established. In the following parts of this series, we will discuss in more detail what software processes you should pay attention to for developing embedded systems.