The Linux effect on embedded systems

A few years ago 32-bit microcotrollers with enough power to run Linux became comparable in cost to devices with 8 or 16bit cores, making the extra performance a no (or low) cost option. This helped push 32-bit processors running Linux into the mainstream of embedded development, creating new challenges such as how to make effective use of the new capability, while coping with the extra complexity.
This step change in the capabilities of embedded systems is slowly transforming the way software is developed for these platforms, enabling far more ambitious projects to be tackled successfully by smaller teams. It is the author’s belief that most embedded software houses are only scratching the surface of this potential at present, and there are large productivity gains to be had by firms willing to push beyond traditional development models and processes.

Traditional embedded development

In a traditional, resource constrained embedded development, the challenge was often how to make use of often quirky processors and development environments. Debug facilities were often limited, with the use of external instrumentation such as oscilloscopes and logic analysers common. Often, much of the software would be closely tied to the underlying hardware. Abstraction layers were often pretty thin, meaning most developers would not completely escape the need to pay attention to the underlying hardware. The closeness to the hardware is one of the reasons why many embedded developers have studied at least some electronics during higher education, and why relatively few embedded engineers are drawn from pure Computer Science backgrounds.
The constraints had some upsides too though: developers were generally working with code of their own team’s creation, and the relatively small scale often made it possible for a single engineer to have an understanding of most or all of the code comprising the end system.

Linux based development

In a well partitioned embedded Linux development, typically only a subset of engineering team will be developing software that is closely tied to the hardware. As applications become more complex and abstract, a larger number of developers will be developing code which is several steps removed from the underlying hardware. A larger portion of time is spent integrating third party software and developing more abstract code. This requires slightly different skills from those associated with traditional embedded C developers. The availability of such a broad range of high quality software libraries for Linux is likely to be one of the main tools to improve the productivity of developers over the next few years.
Linux makes application development much easier, by providing a level of abstraction from the hardware and typically a richer set of facilities than would be found in most traditional embedded operating systems. Depending upon the flavour of Linux that is used, there are typically much larger pools of free software that can be deployed to speed the development process. Quality is often much improved too: these open-source third party libraries have often had many more man hours spent on their development than would be feasible for a single product development inside a company.
Inevitably, there are downsides. Driver development is often more complicated, requiring the developer to understand not just the specifics of the particular hardware and how to control it, but also the Linux framework into which it must fit. Increasing reliance on third party libraries also comes with risks, since fixing bugs in a much larger, unfamiliar code base can cause significant delays, particularly when there is a tendency to underestimate these tasks during project planning, assuming, rather naiively that the integration process will “just work”.

The challenge for the device manufacturers

Traditionally, semiconductor manufacturers could concentrate on the development of the IC, and provide some reference boards with some limited example software that could be used to give the customer a starting point for development. Now, however, owing to the complexity of developing Linux drivers and board support packages, clients will expect a well supported platform to use as a basis, since it is of greater importance in determining the time to market of a new product. This will increase the pressure on the software development capabilities of the vendors, which is likely to become an increasing differentiator.

All that power – what to do with it?

This sudden availability of extra processing power means that many systems are no longer resource constrained, and the abundance of software libraries provides opportunities for new, sophisticated embedded applications that would have been infeasible a few years ago.

New programming languages and development models

Increased adoption of Linux allows for greater use of programming techniques such as those outlined in The Art of Unix Programming. It is no longer necessary to develop a single monolithic program written almost entirely in C or C++. Systems can instead be composed of a number of libraries and possibly separate communicating processes, with each block designed “to do one thing well”. Problems which may in the past have required a multi-tasking or multi-threading approach (and all the complexity that introduces) can sometimes be broken in to separate communicating processes using pipes or sockets to share data and synchronise activity. These separate processes can often be single threaded, simplifying development. Use of existing Unix command line utilities and scripting can often be used to avoid the need to write custom software.
The increased power and performance, combined with applications which will be increasingly removed from the underlying hardware enables the use of languages which would not typically be associated with embedded programming. Whilst CPU intensive work is likely to remain in C or C++ for the foreseeable future, some of the more abstract data processing tasks and the stitching together of individual components could be written in any language for which a compiler or interpreter exists for the target hardware.

Agile and Test Driven Development

The similarity between embedded and desktop development environments often makes it possible for much of the software to be written and debugged on the desktop platform. Whilst this has always been possible to some extent, Linux makes the gap between the two domains much smaller. In contrast to many embedded development environments, which are often on custom hardware with limited debug capabilities and a sometimes lengthy edit-compile-reload cycle, desktop environments tend to be relatively quick and easy. This makes it possible to make the rapid, incremental changes encouraged by agile and test driven methodologies. Once the code has been developed on the desktop, it is often possible to run the same code and test harness on the embedded platform to ensure that nothing has been lost in the conversion.