Elecia White loves embedded systems. “The first time a motor turned on because I told it to, I was hooked,” she writes in her new book, Making Embedded Systems. “I quickly moved away from pure software and into a field where I can touch the world.”
In that world, she has “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.”
It is a world where “embedded systems don’t have operating systems. The software runs on the bare metal. When the software says ‘turn that light on,’ it says it to the processor without an intermediary.”
So this is not a book about embedded operating systems. Just embedded systems. And the intended audience is intermediate and experienced programmers seeking new challenges.
The author’s basic definition of an embedded system is “a computerized system that is purpose-built for its application.”
She says she wrote her book (and it is well-written, by the way) “almost as a story, to be read from cover to cover. The information is technical (extremely so in spots), but the presentation is casual.”
So she hopes readers will not treat Making Embedded Systems as “a technical manual where you can skip into the middle and read only what you want.” With that approach, “you’ll miss a lot of information…[and] You’ll also miss the jokes, which is what I really would feel bad about.”
Embedded system compilers typically support only C or C++ (and often just a subset of that language), she notes. And: “There is a growing popularity for Java, but the memory management inherent to the language works only on a large system.”
Meanwhile, debugging an embedded system often can be challenging, because it’s not always easy to tell if a problem lies in the software or in the associated hardware.
Elecia White’s 310-page book is divided into 10 chapters, with illustrations, code examples and a good index:
- Introduction – (Discusses embedded systems and how their development differs from traditional software development.)
- Creating a System Architecture – (How to create – and document – a system architecture.)
- Getting Your Hands on the Hardware – (Dealing with hardware/software integration and board bring-up.)
- Outputs, Inputs, and Timers – (The simple act of making an LED blink is more complicated than you might think.)
- Managing the Flow of Activity – (How to set up your machine, how to use [or not use] interrupts, and how to make a state machine.)
- Communicating with Peripherals – (“Different serial communications forms rule embedded systems.…” But: “Networking, bit-bang, and parallel buses are not to be discounted.”)
- Updating Code – (Options for replacing the program running in a processor.)
- Doing More with Less – (How to reduce RAM consumption, code space, and processor cycles.)
- Math – (“Most embedded systems need to do some form of analysis.” Make your system faster by “[u]nderstanding how mathematical operations and floating points work [and don’t work]….”)
- Reducing Power Consumption – (Your system may run on batteries. Better system architecture and reducing processor cycles can help cut power drain.)
Making Embedded Systems also includes helpful information on how to read a schematic diagram, why it’s best to run tests on three of the same prototype devices, not just one, and what interviewers look for when meeting with applicants for embedded systems jobs.
An embedded system, the author says, often is viewed as a jigsaw puzzle that only fits together one way. But she challenges readers to see the puzzle as also having “a time dimension that varies over its whole life: conception, prototyping, board bring-up, debugging, testing, release, maintenance, and repeat.”
Embedded system design presents many challenges, she says, and demands constant flexibility.
“Our goal is to be flexible enough to meet the product goals while dealing with the resource constraints and other challenges inherent to embedded systems.”
— Si Dunn