As part of the content on this blog, I will occasionally give my thoughts on some embedded- or controls-related material. This is the first article in that vein, and I'm covering Elicia White's Making Embedded Systems from O'Reilly. Which you can buy from Amazon here.
Background Image: Giammarco Boscaro
My first college course in embedded systems had a "book." It was the reference manual for the PPC MPC823. This was not a textbook. My professor always referred to it as "whitebook." It was huge, it was white, it was a book - his description fit pretty well. "We are going to meet in the lab Thursday for lecture, and for the next two weeks we will be living in whitebook." This was the same professor who once exclaimed "EVERYBODY WAKE UP AND PAY ATTENTION BECAUSE THIS NEXT PART IS REALLY IMPORTANT!" Ahhhh, good times. But I digress.
Use it as a reference
Every now and then during my time in academia a course would not have an official text, and in this case it wasn't particularly needed but I wish I had something other than my scibbles on a printed-out powerpoint deck to refer back to. That's one of the nice things about reference texts - after the course you get to keep it as a "reference." Chapters 3 through 6 in White's book would have been at least adequate, if not great, references for an intro-to-embedded-systems class. The parts I enjoyed most were:
- Ch 3: Hands on the Hardware. Datasheets, schematics, and reference manuals; plus toolbox contents and strategies for testing and error handling
- Ch 4: Outputs, Inputs, and Timers. The hello-world of embedded systems, separating hardware from logic, modularity and ownership, and an intro to on-chip peripherals like clocks, timers, prescalars, and PWMs
- Ch 5: Managing the Flow of Activity. Sharing data (race conditions), atomic operations, state machines, interrupts, schedulers, OSes, and watchdogs
- Ch 6: Communicating with Peripherals. Sensors, actuators, displays, communication layers (OSI), and data handling
For somebody with a pure software background, these chapters should give a great introduction to how your perspective changes when writing embedded software. One thing I want to call attention to is that chapter 6 is the absolute crux of embedded systems, and is probably applicable to every microcontroller-based platform in existence. Embedded is about using software to sense or affect the tangible world (as opposed to the virtual one) and chapter 6 is an excellent exposition on that topic.
How useful the book is for the professional embedded software folks with 10 years experience is going to vary quite a bit. White hits some high points early when going over system architecture diagrams, and good nuggets about design patterns are sprinkled throughout, but much of the content is elementary and would be covered by an undergraduate course. Not everybody working on embedded software took those courses though, so it still may have a great deal of useful info for some.
Part of why embedded reference texts are so tough is that the field is enormous. You could spend a career doing more-or-less real-time work and never once touch control systems - let alone motor control in particular. That is something which you could spend an entire Ph.D. on and maybe learn about 1 thousandth of that field. It's easy to fall into a situation where the text will mention things and not cover the theory behind it (or explain why something works, or when it definitely will not work) but White does a good job listing numerous references for covering that material while throwing in enough tidbits to pique the reader's interest.
A bit about optimization
White spends whole chapters going over methods of optimization and even mentions that to her, reclaiming a few kilobits of code space or taking a few CPU cycles out of a function is what makes embedded work fun. Great googly-moogly. If you take this attitude of optimation beyond what is absolutely necessary, you wind up with some heavily-commented and heavily-documented piece of code that nobody touches ever again and eventually it gets thrown out because the one guy that understood it left the company years ago. There is a lot of content out there imploring the restricted use of optimization techniques, so I'll just mention one of my favorites here. James Grenning mentions in his book on embedded TDD (somewhat covered in these two posts) that you should do the following:
White puts heavy emphasis on that third point, and I would have preferred to see some bold disclaimers saying these tips should be undertaken only when necessary.
Now to completely contradict myself: she's probably on to something. It has been the case many times in my career that a project did run out of X resource (CPU time, code space, RAM, etc) and we had to get creative. Sometimes you need to get creative from the start because you're going to ship millions of units and it makes sense to use a micro that is over $1 cheaper (and much less powerful) than the one you want because that's a lot of money. White mentions as much, and reiterates throughout the book that with these optimizations, your mileage may vary. Every case will have to be evaluated independently to see what actually makes enough of a difference to get the system to work correctly and robustly.
The book is very easy to read, and I did enjoy it. It will remain on my shelf until a new hire comes over looking to learn about something and I'll had it over and say "start here, and come talk to me after chapter 6."