The Challenges of an Embedded Software Engineer Part 2: Decisions, Decisions
by Madison Turner, Accelerated Technology, a Mentor Graphics Division

This is the second of three articles comparing the challenges embedded developers face with the lot of their counterparts in desktop development. The first article discussed how to start development before any hardware is available. This one moves on to the phase of development where hardware exists, or good simulation and prototyping solutions have been found, and software development begins in earnest.

Has the industry reached a point where embedded developers are on equal footing with desktop coders? Not quite.

To start with, developers working in desktop environments can count on having an enterprise operating system. These days, that usually means Windows or Linux, but it could just as easily be Mac OS X or a commercial Unix flavor. All these operating systems have much in common for the developer. Developers can reasonably expect to remain thoroughly ignorant of the underlying hardware platform that the software will be running on. They can also take for granted that the operating system will handle the details of memory management and multitasking, that the memory and processing power available to the application are virtually unlimited, and that a wide range of middleware APIs are available for use.

Designers of embedded systems can take none of this for granted. Instead, they must face decisions among software environments ranging from writing assembly language to run on bare metal to using a stripped-down version of one of the aforementioned desktop operating systems.

Challenge #2: The Operating System Decision

For the simplest kind of embedded application, no formal operating system is necessary. A control loop written in some combination of C and assembly language will often do the trick. In this case, the developer must be familiar with every detail of the hardware, not to mention the temporal implications of every interrupt source that the application will encounter. Needless to say, this is about as far from desktop development as one can get. For this kind of project, development tools, discussed in detail below, take on paramount importance.

Most embedded applications require some form of operating system, and here there are still plenty of decisions to be made. First, a developer may decide on a “roll your own” real time kernel. This might be the best decision in cases where additional time is available in the development schedule and the project budget won’t sustain buying a commercial OS. Or, if the application has enough hardware resources and few real-time constraints, a customized Linux distribution can be created, thus gaining access to a wide variety of open source middleware and even application code under open source licenses. Of course, that decision comes with the legal implications inherent in the general public license (GPL) and other open source licenses.

For projects that can’t afford the development time necessary to write a kernel from scratch or port Linux, a commercial real-time operating system (RTOS) offers an option that comes ported to the chosen hardware platform. A commercial RTOS also normally has some level of supporting middleware available, though the breadth and depth of middleware coverage varies widely from one RTOS to the next. There are many factors that influence the selection of an RTOS. Performance and memory footprint are often at the top of the list. It is also important to choose an RTOS that has the right middleware available for the intended project. In some cases, developers will need an OS that handles memory management or one that offers industry standard APIs like POSIX, μITRON or OSEK. In most cases, it’s important to find an OS that is preintegrated with a set of high quality development tools.

Depending on the operating system being used, desktop application developers usually have an obvious choice of development environment that includes project management, compiler, and debugger that are more or less standard for that OS. In some cases, the same is true for embedded developers. The GNU GCC compilers and related development tools like the GDB debugger are available for most popular embedded environments, and most commercial embedded operating systems are integrated with tools from the same vendor or a third-party partner. The difference occurs when developers consider the quality of the tools and the complexity of the environment in which they operate.

For example, consider the compiler. To most desktop developers, the compiler is a magic black box that consumes high-level code and emits an executable or a library. Embedded developers, on the other hand, know their compilers inside out. The key difference is that to a desktop coder, the source code is the program, while to an embedded developer, the final bits on hardware are ultimately the most important thing. Embedded developers must concern themselves with the smallest details of their application as it is burned into ROM, loaded into RAM, and executed on the target processor. Quality development tools reduce these challenges by offering visibility into the system.

Challenge #3: Seeing inside the box

For desktop Windows® developers, the Microsoft® Visual Studio® environment offers a state-of-the-art graphical interface that is fully integrated, from project management to editor, compiler and debugger, with full knowledge of the Windows system calls and middleware APIs available. For embedded developers (even those working with embedded Windows), none of these things can be taken for granted. Desktop developers receive the benefits of high quality development environments because there are only a few platforms the tools have to address. Embedded developers, on the other hand, have historically been forced to use tools that were not integrated into an easy-to-use package, not focused on their environment, or extremely expensive.

Embedded development environments have tended to lack the GUI sophistication and ease of use of desktop equivalents. This makes sense, since embedded tools have a smaller user base and must support a wider range of hardware and software environments, thus vendors have comparatively fewer resources to put toward the interface. This is changing, however, now that the embedded community is standardizing on the Eclipse Platform. Eclipse is an open-source, cross-platform foundation for building IDEs. It provides a plug-in-based architecture where toolmakers, developers, and third parties have equal access to the environment’s basic functionality so that an array of tools can interoperate in a consistent manner and the environment can be extended at will. Now embedded developers can use all the tools they need without vendor lock-in and with all the benefits of the most advanced development framework, in a free IDE and debugger platform backed by the energy of the open source community. Developers can invest their time in building familiarity with an environment that they can take with them to the next project, and project budgets don’t have to support all the costs of maintaining basic user interface features.

Another critical aspect of embedded development tools is the availability of I/O connections. Keep in mind that a typical embedded system may not have a standard output device to display printf statements. Other input and output devices might exist in the device’s ultimate real world environment, but not during development. Therefore, it is essential for the development environment to handle I/O. One way of dealing with this is to use virtual I/O connections, sometimes called semihosting, to reroute input and output to the development host. In this way, print debugging output can be printed to a console window on the development workstation. Similarly, input sources like human-machine interfaces can be simulated on the host while interacting with code running on target hardware.

A third consideration for embedded development tools is the use they make of hardware-assisted debugging features. These range from JTAG emulator devices to sophisticated on-chip debugging blocks that provide facilities like execution trace information and bus analysis. It is essential that development tools make use of these facilities when they exist. Even better, development tools can use these hardware-assisted debugging features to provide application analysis that goes beyond typical debugging. For example, execution trace data from an embedded debug block like the ARM embedded trace module (ETM) can be used as a nonintrusive data source for code coverage statistics and performance analysis.

A final consideration that developers should keep in mind when looking at development tools is the continuing support of new hardware, especially new processor variants. It is quite common for a development team to start work on a particular CPU variant with plans to migrate to a newer chip when it becomes available. It is equally common to migrate a subsequent version of an application to a new part, either to leverage new features or because the old chip has become obsolete. In these cases, it can be extremely disruptive to the development process to install updated development tools in order to gain support for the new processor variant. The latest generation of embedded development tools takes this scenario into account by using a data-driven architecture for the support of processor variants. Upgrading this class of tools to support the latest CPU variant can be as easy as copying an XML file into the directory that holds variant definitions. This kind of flexibility can save hours of effort in locating and installing a newer version of the tools.

Although progress has been made, compared to their desktop colleagues, embedded developers have a tough row to hoe in terms of hardware availability and the decision of an operating system and development tools. Is it safe to say that the hard part has been overcome and embedded developers can continue forth on equal terms with desktop programmers? Indeed not. The final article of this series will examine the challenges posed to embedded developers by the requirements of mission-critical reliability and safety-critical operation.

by Madison Turner, Technology Analyst, Accelerated Technology,
a Mentor Graphics Division

January 17, 2006

[back to top]

Comments on this article? Send them to comments@embeddedtechjournal.com