Embedded Software: The Works

There is nothing mandatory about using an RTOS, but most larger embedded systems tend to include a kernel or OS of some kind. The topic could easily fill a book by itself. The articles in this chapter look at various aspects of using, choosing, or implementing an RTOS and take glimpses at the internal workings.
Debugging is a very broad subject. Typically, embedded software engineers appreciate only a small subset of the gamut of possibilities. In particular, debugging with a real-time operating system presents a wide range of options. I have made presentations on this topic at numerous seminars and conferences and authored many papers and articles. A piece that I did in NewBits in early 2003 provided the basis for this expanded article. (CW)
Most modern embedded system designs make use of an RTOS. This permits the software designer to employ the multi-task paradigm to distribute the available processor resources across the required functionality. At the same time, the opportunity arises to distribute the detailed design, programming, and debugging effort across a team.
An RTOS may be developed in-house or it may be a commercial product, licensed for use in the design at hand. In either case, the multi-tasking environment introduces some new challenges. Not the least of these is debugging.
This article aims to provide a complete overview of the issues, scope, and limitations of debugging when an RTOS is in use.
The term task is used throughout.