In the field of embedded systems, I have worked on DNA scanners, inertial measurement units for airplanes and race cars, toys for preschoolers, a gunshot location system for catching criminals, and assorted medical and consumer devices. I have specialized in signal processing, hardware integration, complex system design, and performance. Having been through FAA and FDA certification processes, I understand the importance of producing high-quality designs and how they lead to highquality implementations. I've spent several years in management roles, but I enjoy hands-on engineering and the thrill of delivering excellent products. I'm happy to say that leaving management has not decreased my opportunities to provide leadership and mentoring.
Organization of the Book I read nonfiction for amusement. I read a lot more fiction than nonfiction but, still, I like any good book. I wrote this book to be read, almost as a story, from cover to cover. The information is technical (extremely so in spots) but the presentation is casual. You don't need to program along with it to get the material (though trying out the examples and applying the recommendations to your code will give you a deeper understanding). This isn't intended to be a technical manual where you can skip into the middle and read only what you want. I mean, you can do that, but you'll miss a lot of information with the search and destroy method. You'll also miss the jokes, which is what I really would feel bad about. I hope that you go through the book in order. Then, when you are a hip deep in alligators and need to implement a function fast, pick up the book, flip to the right chapter and, like a wizard, whip up a command table or fixed point implementation of variance. Or you can skip around, reading about solutions to your crisis of the week. I understand. Sometimes you just have to solve the problem. If that is the case, I hope you find the chapter interesting enough to come back when you are done fighting this fire. xii | Preface
The order of chapters is: Chapter 1. Introduction What is an embedded system? How is development different from traditional software? Chapter 2. Creating a System Architecture How to create (and document) a system architecture. Chapter 3. Getting the Code Working Hardware/software integration during board bring up can be scary, but there are some ways to make it smoother. Chapter 4. Outputs, Inputs and Timers The embedded systems version of “Hello World” is making an LED blink. It can be more complex than you might expect. Chapter 5. Task Management This chapter describes how to set up your system, where to use interrupts (and how not to), and how to make a state machine. Chapter 6. Communicating with Peripherals Different serial communication forms rule embedded systems (UART, SSP, SPI, I2C, USB, etc.). Networking, bit-bang, and parallel buses are not to be discounted. Chapter 7. Updating Code When you need to replace the program running in your processor, you have a few options from internal bootloaders to building your own solution. Chapter 8. Doing More with Less This covers methods for reducing consumption of RAM, code space, and processor cycles. Chapter 9. Math Most embedded systems need to do some form of analysis. Understanding how mathematical operations and floating point work (and don't work) will make your system faster. Chapter 10. Reducing Power Consumption From reducing processor cycles to system architecture suggestions, this chapter will help you if your system runs on batteries. The information is presented in the order that I want my engineers to start thinking about these things. It may seem odd that architecture is first, though most people don't get to it until later in their careers. However, I want the people I work with to be thinking about how their code fits in the system long before I want them to worry about optimization.
Preface | xiii
Conventions Used in This Book Typography The following typographical conventions are used in this book: Italic Indicates new terms, URLs, filenames, and file extensions. Constant width
Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names, data types, and keywords. Constant width bold
Shows commands or other text that should be typed literally by the user. Constant width italic
Shows text that should be replaced with user-supplied values or by values determined by context. This icon signifies a tip, suggestion, or general note.
This icon indicates a warning or caution.
Terminology A microcontroller is a processor with on board goodies like RAM, code space (usually flash) and various peripheral interfaces (e.g. I/O lines). You code runs on a processor or central processing unit (CPU). A microprocessor is a small processor. But the definition of small changes. A DSP (digital signal processor) is a specialized form of microcontroller which focuses on signal processing, usually sampling analog signals and doing something interesting with the result. Usually a DSP is also a microcontroller but it has special tweaks to make it perform math operations faster (in particular multiply and add). As I wrote the book, I wanted to put in the right terminology so you'd get used to it. However, this is so critical I don't want to keep changing the name. Throughout the book, I stick with the term processor to represent whatever it is you are using to implement your system. Most of the material is applicable to whatever you actually have.
xiv | Preface
Using Code Examples This book is here to help you get your job done. In general, you may use the code in this book in your programs and documentation. You do not need to contact us for permission unless you're reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O'Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product's documentation does require permission. We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “Making Embedded Systems by Elecia White (O'Reilly). Copyright 2011 Some Copyright Holder, 9781449302146.” If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at [email protected]
Safari® Books Online Safari Books Online is an on-demand digital library that lets you easily search over 7,500 technology and creative reference books and videos to find the answers you need quickly. With a subscription, you can read any page and watch any video from our library online. Read books on your cell phone and mobile devices. Access new titles before they are available for print, and get exclusive access to manuscripts in development and post feedback for the authors. Copy and paste code samples, organize your favorites, download chapters, bookmark key sections, create notes, print out pages, and benefit from tons of other time-saving features. O'Reilly Media has uploaded this book to the Safari Books Online service. To have full digital access to this book and others on similar topics from O'Reilly and other publishers, sign up for free at .
How to Contact Us Please address comments and questions concerning this book to the publisher: O'Reilly Media, Inc. 1005 Gravenstein Highway North Sebastopol, CA 95472 800-998-9938 (in the United States or Canada) 707-829-0515 (international or local) 707-829-0104 (fax)
Preface | xv
We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at: To comment or ask technical questions about this book, send email to: [email protected]
For more information about our books, conferences, Resource Centers, and the O'Reilly Network, see our website at:
xvi | Preface
Embedded systems are different things to different people. To someone who has been working on servers, an application developed for a phone is an embedded system. To someone who has written code for tiny 8-bit microprocessors, anything with an operating system doesn't seem very embedded. I tend to tell non-technical people that embedded systems are things like microwaves and automobiles that run software but aren't computers. (Most people recognize a computer as a general purpose device.) Perhaps an easy way to define the term without haggling over technology is: An embedded system is a computerized system that is purpose built for its application.
Because its mission is narrower than a general purpose computer, an embedded system has less support for things that are unrelated to running the application. The hardware often has constraints: for instance, a CPU that runs more slowly to save battery power; a system that uses less memory so it can be manufactured more cheaply; processors that come only in certain speeds or support a subset of peripherals. The hardware isn't the only part of the system with constraints. In some systems, the software must act deterministically (exactly the same each time) or real-time (always reacting to an event fast enough). Some systems require that the software be faulttolerant with graceful degradation in the face of errors. For example, consider a system where servicing faulty software or broken hardware may be infeasible (i.e. a satellite or a tracking tag on a whale). Other systems require that the software cease operation at the first sign of trouble, often providing clear error messages (a heart monitor should not fail quietly).
Compilers, Languages, and Object-Oriented Programming Another way to identify embedded systems is that they use cross compilers. While a cross...