Michael Barr: Programming Embedded Systems in C and C++

I feel that this mixed treatment of C, C++, and assembly most accurately reflects how embedded software is actually developed today and how it will continue to be developed in the near-term future. I hope that this choice will keep the discussion clear, provide information that is useful to people developing actual systems, and include as large a potential audience as possible.

it is the nature of programming that books about the subject must include examples. Typically, these examples are selected so that they can be easily experimented with by interested readers. That means readers must have access to the very same software development tools and hardware platforms used by the author. Unfortunately, in the case of embedded programming, this is unrealistic. It simply does not make sense to run any of the example programs on the platforms available to most readers-PCs, Macs, and Unix workstations.

Even selecting a standard embedded platform is difficult. As you have already learned, there is no such thing as a "typical" embedded system. Whatever hardware is selected, the majority of readers will not have access to it. But despite this rather significant problem, I do feel it is important to select a reference hardware platform for use in the examples. In so doing, I hope to make the examples consistent and, thus, the entire discussion more clear.

In order to illustrate as many points as possible with a single piece of hardware, I have found it necessary to select a middle-of-the-road platform. This hardware consists of a 16-bit processor (Intel's 80188EB [2] Intel's 80188EB processor is a special version of the 80186 that has been redesigned for use in embedded systems. The original 80186 was a successor to the 8086 processor that IBM used in their very first personal computer —the PC/XT. The 80186 was never the basis of any PC because it was passed over (in favor of the 80286) when IBM designed their next model — the PC/AT. Despite that early failure, versions of the 80186 from Intel and AMD have enjoyed tremendous success in embedded systems in recent years. ), a decent amount of memory (128KB of RAM and 256 KB of ROM), and some common types of inputs, outputs, and peripheral components. The board I've chosen is called the Target188EB and is manufactured and sold by Arcom Control Systems. More information about the Arcom board and instructions for obtaining one can be found in Appendix A.

If you have access to the reference hardware, you will be able to work through the examples in the book exactly as they are presented. Otherwise, you will need to port the example code to an embedded platform that you do have access to. Toward that end, every effort has been made to make the example programs as portable as possible. However, the reader should bear in mind that the hardware in each embedded system is different and that some of the examples might be meaningless on his hardware. For example, it wouldn't make sense to port the Flash memory driver presented in Chapter 6 to a board that had no Flash memory devices.

Anyway I'll have a lot more to say about hardware in Chapter 5. But first we have a number of software issues to discuss. So let's get started.

In this chapter we'll dive right into embedded programming by way of an example. The program we'll look at is similar in spirit to the "Hello, World!" example found in the beginning of most other programming books. As we discuss the code, I'll provide justification for the selection of the particular program and point out the parts of it that are dependent on the target hardware. This chapter contains only the source code for this first program. We'll discuss how to create the executable and actually run it in the two chapters that follow.

it seems like every programming book ever written begins with the same example — a program that prints "Hello, World!" on the user's screen. An overused example like this might seem a bit boring. But it does help readers to quickly assess the ease or difficulty with which simple programs can be written in the programming environment at hand. In that sense, "Hello, World!" serves as a useful benchmark of programming languages and computer platforms. Unfortunately, by this measure, embedded systems are among the most difficult computer platforms for programmers to work with. In some embedded systems, it might even be impossible to implement the "Hello, World!" program. And in those systems that are capable of supporting it, the printing of text strings is usually more of an endpoint than a beginning.

You see, the underlying assumption of the "Hello, World!" example is that there is some sort of output device on which strings of characters can be printed. A text window on the user's monitor often serves that purpose. But most embedded systems lack a monitor or analogous output device. And those that do have one typically require a special piece of embedded software, called a display driver, to be implemented first — a rather challenging way to begin one's embedded programming career.

It would be much better to begin with a small, easily implemented, and highly portable embedded program in which there is little room for programming mistakes. After all, the reason my book-writing counterparts continue to use the "Hello, World!" example is that it is a no-brainer to implement. This eliminates one of the variables if the reader's program doesn't work right the first time: it isn't a bug in their code; rather, it is a problem with the development tools or process that they used to create the executable program.

Embedded programmers must be self-reliant. They must always begin each new project with the assumption that nothing works — that all they can rely on is the basic syntax of their programming language. Even the standard library routines might not be available to them. These are the auxiliary functions — like printf and scanf — that most other programmers take for granted. In fact, library routines are often as much a part of the language standard as the basic syntax. However, that part of the standard is more difficult to support across all possible computing platforms and is occasionally ignored by the makers of compilers for embedded systems.

So you won't find an actual "Hello, World!" program in this chapter. Instead, we will assume only the basic syntax of C is available for our first example. As we progress through the book, we will gradually add C++ syntax, standard library routines, and the equivalent of a character output device to our repertoire. Then, in Chapter 9, we'll finally implement a "Hello, World!" program. By that time you'll be well on your way to becoming an expert in the field of embedded systems programming.

Every embedded system that i've encountered in my career has had at least one LED that could be controlled by software. So my substitute for the "Hello, World!" program has been one that blinks an LED at a rate of 1 Hz (one complete on-off cycle per second). [3] Of course, the rate of blink is completely arbitrary. But one of the things I like about the 1 Hz rate is that it's easy to confirm with a stopwatch. Simply start the stopwatch, count off some number of blinks, and see if the number of elapsed seconds is the same as the number of blinks. Need greater accuracy? Simply count off more blinks. Typically, the code required to turn an LED on and off is limited to a few lines of C or assembly, so there is very little room for programming errors to occur. And because almost all embedded systems have LEDs, the underlying concept is extremely portable.