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

Chapter 7 explains device driver design and implementation techniques and includes an example driver for a common peripheral called a timer.

Chapter 8 includes a very basic operating system that can be used in any embedded system. It also helps you decide if you'll need an operating system at all and, if so, whether to buy one or write your own.

Chapter 9 expands on the device driver and operating system concepts presented in the previous chapters. It explains how to control more complicated peripherals and includes a complete example application that pulls together everything you've learned so far.

Chapter 10 explains how to simultaneously increase the speed and decrease the memory requirements of your embedded software. This includes tips for taking advantage of the most beneficial C++ features without paying a significant performance penalty.

Throughout the book, I have tried to strike a balance between specific examples and general knowledge. Whenever possible, I have eliminated minor details in the hopes of making the book more readable. You will gain the most from the book if you view the examples, as I do, only as tools for understanding important concepts. Try not to get bogged down in the details of any one circuit board or chip. If you understand the general concepts, you should be able to apply them to any embedded system you encounter.

The following typographical conventions are used throughout the book:

Italic

is used for the names of files, functions, programs, methods, routines, and options when they appear in the body of a paragraph. Italic is also used for emphasis and to introduce new terms.

Constant Width

is used in the examples to show the contents of files and the output of commands. In the body of a paragraph, this style is used for keywords, variable names, classes, objects, parameters, and other code snippets.

Constant Width Bold

is used in the examples to show commands and options that you type literally.

This symbol is used to indicate a tip, suggestion, or general note.

This symbol is used to indicate a warning.

Other conventions relate to gender and roles. With respect to gender, I have purposefully alternated my use of the terms "he" and "she" throughout the book. "He" is used in the odd-numbered chapters and "she" in all of the even-numbered ones.

With respect to roles, I have occasionally distinguished between the tasks of hardware engineers, embedded software engineers, and application programmers in my discussion. But these titles refer only to roles played by individual engineers, and it should be noted that it can and often does happen that one individual fills more than one of these roles.

This book includes many source code listing, and all but the most trivial one-liners are available online. These examples are organized by chapter number and include build instructions (makefiles) to help you recreate each of the executables. The complete archive is available via FTP, at ftp://ftp.oreilly.com/pub/examples/nutshell/embedded_c/.

We have tested and verified all the information in this book to the best of our ability, but you may find that features have changed (or even that we have made mistakes!). Please let us know about any errors you find, as well as your suggestions for future editions, by writing to:

O'Reilly & Associates

1005 Gravenstein Highway North

Sebastopol, CA 95472

800-998-9938 (in the U.S. or Canada)

707-829-0515 (international/local)

707-829-0104 (FAX)

You can also send us messages electronically. To be put on the mailing list or request a catalog, send email to:

info@oreilly.com

To ask technical questions or comment on the book, send email to:

bookquestions@oreilly.com

We have a web site for the book, where we'll list examples, errata, and any plans for future editions. You can access this page at:

http://www.oreilly.com/catalog/embsys/

For more information about this book and others, see the O'Reilly web site:

http://www.oreilly.com

As long as I can remember I have been interested in writing a book or two. But now that I have done so, I must confess that I was naive when I started. I had no idea how much work it would take, nor how many other people would have to get involved. Another thing that surprised me was how easy it was to find a willing publisher. I had expected that to be the hard part.

From proposal to publication, this project has taken almost two years to complete. But, then, that's mostly because I worked a full-time job throughout and tried to maintain as much of my social life as possible. Had I known when I started that I'd still be agonizing over final drafts at this late date, I would have probably quit working and finished the book more quickly. But continuing to work has been good for the book (as well as my bank account!). It has allowed me the luxury of discussing my ideas regularly with a complete cast of embedded hardware and software professionals. Many of these same folks have also contributed to the book more directly by reviewing drafts of some or all of the chapters.

I am indebted to all of the following people for sharing their ideas and reviewing my work: Toby Bennett, Paul Cabler (and the other great folks at Arcom), Mike Corish, Kevin D'Souza, Don Davis, Steve Edwards, Mike Ficco, Barbara Flanagan, Jack Ganssle, Stephen Harpster (who christened me "King of the Sentence Fragment" after reading an early draft), Jonathan Harris, Jim Jensen, Mark Kohler, Andy Kollegger, Jeff Mallory, Ian Miller, Henry Neugauss, Chris Schanck, Brian Silverman, John Snyder, Jason Steinhorn (whose constant stream of grammatical and technical critiques have made this book worth reading), Ian Taylor, Lindsey Vereen, Jeff Whipple, and Greg Young.

I would also like to thank my editor, Andy Oram. Without his enthusiasm for my initial proposal, overabundant patience, and constant encouragement, this book would never have been completed.

Finally, I'd like to thank Alpa Dharia for her support and encouragement throughout this long process.

Michael Barr mbarr@netrino.com

One of the more surprising developments of the last few decades has been the ascendance of computers to a position of prevalence in human affairs. Today there are more computers in our homes and offices than there are people who live and work in them. Yet many of these computers are not recognized as such by their users. In this chapter, I'll explain what embedded systems are and where they are found. I will also introduce the subject of embedded programming, explain why I have selected C and C++ as the languages for this book, and describe the hardware used in the examples.

An embedded system is a combination of computer hardware and software, and perhaps additional mechanical or other parts, designed to perform a specific function. A good example is the microwave oven. Almost every household has one, and tens of millions of them are used every day, but very few people realize that a processor and software are involved in the preparation of their lunch or dinner.