Programming Embedded Systems in C and C++

Programming Embedded Systems in C and C++

3.5 2
by Michael Barr

Embedded software is in almost every electronic device designed today. There is software hidden away inside our watches, microwaves, VCRs, cellular telephones, and pagers; the military uses embedded software to guide smart missiles and detect enemy aircraft; communications satellites, space probes, and modern medicine would be nearly impossible without it. Of

…  See more details below


Embedded software is in almost every electronic device designed today. There is software hidden away inside our watches, microwaves, VCRs, cellular telephones, and pagers; the military uses embedded software to guide smart missiles and detect enemy aircraft; communications satellites, space probes, and modern medicine would be nearly impossible without it. Of course, someone has to write all that software, and there are thousands of computer scientists, electrical engineers, and other professionals who actually do.

Each embedded system is unique and highly customized to the application at hand. As a result, embedded systems programming is a widely varying field that can take years to master. However, if you have some programming experience and are familiar with C or C++, you're ready to learn how to write embedded software. The hands-on, no-nonsense style of this book will help you get started by offering practical advice from someone who's been in your shoes and wants to help you learn quickly.

The techniques and code examples presented here are directly applicable to real-world embedded software projects of all sorts. Even if you've done some embedded programming before, you'll still benefit from the topics in this book, which include:

  • Testing memory chips quickly and efficiently
  • Writing and erasing Flash memory
  • Verifying nonvolatile memory contents with CRCs
  • Interfacing to on-chip and external peripherals
  • Device driver design and implementation
  • Optimizing embedded software for size and speed

So whether you're writing your first embedded program, designing the latest generation of hand-held whatchamacalits, or simply managing the people who do, this book is for you.

Read More

Product Details

O'Reilly Media, Incorporated
Publication date:
Edition description:
Older Edition
Product dimensions:
7.00(w) x 9.11(h) x 0.53(d)

Read an Excerpt

Chapter 8: Operating Systems

All but the most trivial of embedded programs will benefit from the inclusion of an operating system. This can range from a small kernel written by you to a fullfeatured commercial operating system. Either way, you'll need to know what features are the most important and how their implementation will affect the rest of your software. At the very least, you need to understand what an embedded operating system looks like on the outside. But there's probably no better way to understand the exterior interfaces than to examine a small operating system in its entirety. So that's what we'll do in this chapter.

History and Purpose

In the early days of computing there was no such thing as an operating system. Application programmers were completely responsible for controlling and monitoring the state of the processor and other hardware. in fact, the purpose of the first operating systems was to provide a virtual hardware platform that made application programs easier to write. To accomplish this goal, operating system developers needed only provide a loose collection of routines-much like a modem software library-for resetting the hardware to a known state, reading the state of the inputs, and changing the state of the outputs.

Modem operating systems add to this the ability to execute multiple software tasks simultaneously on a single processor. Each such task is a piece of the software that can be separated from and run independently of the rest. A set of embedded software requirements can usually be decomposed into a small number of such independent pieces. For example, the printer-sharing device described in Chapter 5, Getting to Know the Hardware, contains three obvious software tasks:

  • Task 1: Receive data from the computer attached to serial port A.

  • Task 2: Receive data from the computer attached to serial port B.

  • Task 3: Format and send the waiting data (if any) to the printer attached to the parallel port.

Tasks provide a key software abstraction that makes the design and implementation of embedded software easier and the resulting source code simpler to understand and maintain. By breaking the larger program up into smaller pieces, the programmer can more easily concentrate her energy and talents on the unique features of the system under development.

Strictly speaking, an operating system is not a required component of any computer system-embedded or otherwise. it is always possible to perform the same functions from within the application program itself. Indeed, all of the examples so far in this book have done just that. There is simply one path of execution-starting at main-that is downloaded into the system and run. This is the equivalent of having only one task. But as the complexity of the application expands beyond just blinking an LED, the benefits of an operating system far outweigh the associated costs.

If you have never worked on operating system internals before, you might have the impression that they are complex. I'm sure the operating system vendors would like you to continue to believe that they are and that only a handful of computer scientists are capable of writing one. But I'm here to let the cat out of the bag: it's not all that hard! in fact, embedded operating systems are even easier to write than their desktop cousins-the required functionality is smaller and better defined. Once you learn what that functionality is and a few implementation techniques, you will see that an operating system is no harder to develop than any other piece of embedded software.

Embedded operating systems are small because they lack many of the things you would expect to find on your desktop computer. For example, embedded systems rarely have disk drives or graphical displays, and hence they need no filesystem or graphical user interface in their operating systems. In addition, there is only one "user" (i.e., all of the tasks that comprise the embedded software cooperate), so the security features of multiuser operating systems do not apply. All of these are features that could be part of an embedded operating system but are unnecessary in the majority of cases.

A Decent Embedded Operating System

What follows is a description of an embedded operating system that I have developed on my own. I call my operating system ADEOS (pronounced the same as the Spanish farewell), which is an acronym for "A Decent Embedded Operating System." I think that name really sums it up nicely. Yes, it is an embedded operating system; but it is neither the best nor the worst in any regard. in all, there are less than 1000 lines of source code. Of these, three quarters are platform-independent and written in C++. The rest are hardware- or processor-specific and, therefore, written in assembly language. In the discussion later, I will present and explain all of the routines that are written in C++ along with the theory you need to understand them. In the interest of clarity, I will not present the source code for the assembly language routines. Instead, I will simply state their purpose and assume that interested readers will download and examine that code on their own.

If you would like to use ADEOS (or a modified version of it) in your embedded system, please feel free to do so. In fact, I would very much like to hear from anyone who uses it. I have made every effort to test the code and improve upon the weaknesses I have uncovered. However, I can make no guarantee that the code presented in this chapter is useful for any purpose other than learning about operating systems. If you decide to use it anyway, please be prepared to spend some amount of your time finding and fixing bugs in the operating system itself.


We have already talked about multitasking and the idea that an operating system makes it possible to execute multiple "programs" at the same time. But what does that mean? How is it possible to execute several tasks concurrently? In actuality, the tasks are not executed at the same time. Rather, they are executed in pseudoparallel. They merely take turns using the processor. This is similar to the way several people might read the same copy of a book. Only one person can actually use the book at a given moment, but they can both read it by taking turns using it.

An operating system is responsible for deciding which task gets to use the processor at a particular moment. In addition, it maintains information about the state of each task. This information is called the task's context, and it serves a purpose similar to a bookmark. In the multiple book reader scenario, each reader is presumed to have her own bookmark. The bookmark's owner must be able to recognize it (e.g., it has her name written on it), and it must indicate where she stopped reading when last she gave up control of the book. This is the reader's context.

A task's context records the state of the processor just prior to another task's taking control of it. This usually consists of a pointer to the next instruction to be executed (the instruction pointer), the address of the current top of the stack (the stack pointer), and the contents of the processor's flag and general-purpose registers. On 16-bit 80x86 processors, these are the registers CS and IP, SS and SP, Flags, and DS, ES, SI, DI, AX, BX, CX, and DX, respectively....

Read More

Customer Reviews

Average Review:

Write a Review

and post it to your social network


Most Helpful Customer Reviews

See all customer reviews >

Programming Embedded Systems in C and C++ 3.5 out of 5 based on 0 ratings. 2 reviews.
Guest More than 1 year ago
Very introductory level book on embedded programming. I'm not sure I would recommend this book even to beginners as it doesn't really offer any structured approach to embedded programming. I would put your $23 towards another book.
Guest More than 1 year ago
As an embedded systems programmer myself, I was looking for a book that would help both beginners and experienced programmers. Among all the books I reviewed, I liked this one the best!