Making Embedded Systems - A Reader's Review

When I first heard that Making Embedded Systems 2nd Edition was up for pre-order, I jumped onto Amazon and handed over my dollars.

For a period of time, I have been self-training in a variety of areas of electronics and embedded systems development but in a reasonably random and not entirely organised fashion.

I was hoping this book could provide a good framework to formalise my growth and learning.

I had some presumptions about the content of the book and intended that it would firstly teach me to set up a development environment for the STM32 range of micro-controllers, and that I could use the material in the book to jump to whatever area of development interested me the most.

After seeing the index list and sample chapters on the O'Reilly website, it was clear that there was no such setup chapter, and that the Preface strongly recommended not jumping around, but to work through the entire book in order.

Which was a little freaky… did the author read my mind? Fine. When the book arrives, I'll do as I'm told. In the meantime I installed my own STM32CubeIDE development environment. That was not a bad thing, nor was it all that difficult.

The book arrived with much jubilation and fanfare! The first order of business was to have it covered in clear contact. I intended this book to be with me everywhere, and I didn't want it doggy-eared.

Of course, I am eternally grateful to the author for taking many months out of her life to write this book specifically for me. :)

I'll take you through some moments in each chapter that really struck a chord with me or was a point of interest in my journey through the pages.

Chapter One is a nice and easy introduction to Embedded Systems: compiling, debugging, resource considerations, and the difference between maker prototypes and products. I liked the interview question at the end of the chapter and at the end of each chapter. But I won't say anything about them as this might pre-empt how you go about answering them. So I just leave that as it is.

Chapter Two had me creating diagrams to plan out systems. I groaned. I just want to talk to some peripherals. When do we get to the meat? I mean, I know what I want the system to do, and I have a reasonable idea of how it's laid out. Do I have to do this?

But then I remembered, I'd committed to following everything in order, and taking the advice along the way. So I started drawing the boxes and lines from one thing to another thing.. and hey wait… this is hard. I had to really stop and think about the best way to lay things out, to consider resources, pros and cons.

This was super helpful. It started to click into place, and this made me realise that after throwing in various subsystems, I could easily be in danger of getting myself into a mess of spaghetti.

Chapter Three introduces the art of reading datasheets. But a datasheet on a triceratops? Couldn't we do a real example or something more familiar like an actual component?

I'm doing that thing again, aren't I? It dawned on me that many components can be like a mystery box. I would have no better understanding of a SPI-based display datasheet in one hand versus a triceratops datasheet in the other.

So why not have a datasheet to explain how a dinosaur works? Or a brick, or well, anything really.

Next were good insights into software vs hardware project planning, reading schematics, sources of good documentation, good tools, and testing.

Chapter Four spent some time on bit-wise operations, and while it's something I have used in my toolbox before, I had never fully grasped why some developers use them so extensively over clearer syntax. But what I really liked was the way the examples were explained in such a simple and clear way.

Pre-scaling timers was a very welcome topic, and it was nice to run into a concept that I had already been trying. It gave me the impression I was on the good path considering patterns and techniques that are useful for embedded.

Chapter Six introduces state machines. This was a topic that was interesting to read. I had used state machines in game development in the past as a natural way of giving enemies intelligence. I didn't know it was a pattern with a name.

Working through an example based around traffic lights and traffic flow seemed easy at first, but there were many things to consider, both in the technical planning of the flows and the simplification of the components.

Chapter Seven finally brought me to peripherals, yay! There was I2C, SPI, and all the flavours of serial (cereal?), oh my.

But it didn't teach me any of the actual use of those protocols. That's not really the point of the book. Already having experience working with some of those protocols on my own, this chapter mainly provided a reinforcement of the availability and difference between so many serial protocols: their benefits and limitations, and things to consider as an engineer.

DMA and Buffers were also welcome topics and another confirmation to feel I was on the right track with my learning.

Chapter Nine takes us through getting ourselves into trouble and getting out of it again. It looks at debugging, at doing the basics first to solve an issue, problems that optimization can cause or mask, writing into memory that has fallen off a cliff, stack versus heap, registers and core dumps.

This is definitely a chapter to come back to try each of the problems and methods to solve issues. Actually feeling the problems first hand and seeing the reaction of your compiler helps when experiencing problems again on a real project.

Chapter Eleven was one of my favourites. Here, the resources of RAM, code space and CPU time are pitted against each other with their pros and cons in the face of different scenarios. Which is more important for each use case?

Function chains can take up more RAM and reduce speed for the sake of readability and easily maintainable code.

Map files are explained - something I have never used before. These help give an understanding of the breakdown of an executable: the library space, how variables and functions are stored. Using this tool, all sorts of issues can be uncovered, and resource use can be greatly improved.

Registers over variables is covered as a way of improving speed as is reducing the depth of function chains.

I loved the section on code profiling, and using GPIO lines with an oscilloscope to provide a visual indicator of how long a function or code section takes to run. Timing are compared on different patterns and code techniques.

Chapter Twelve… oh man. Math. Like going to the dentist, It just has to be done. Amazing how much you tend to forget when you don't use it all the time. And I'll be straight, I struggled with this chapter. Most other chapters provided so many of those ah-ha moments, but not this one.

One topic that fascinated me was the concept of Fake Floating-Point. This is something I had considered myself in the past. So I was pleased to see it explored here in great detail. The other excellent topic was the great cost of division on the CPU and the alternative techniques that are available.

I'm not done with this chapter. I've read it, but to really understand everything here, I'll be going back to the start and working slowly through each topic.

Chapter Thirteen is a much relieved break from Chapter 12 that covers much about power consumption (or reducing it) and measuring it. Also: designing for low power, turning things off that aren't required, slowing down, sleeping and watchdogs. I like sleeping.

Chapter Fourteen is the last one and covers all the various kinds of motors that you might come across. This was a good review chapter having worked on motors here and there. It's a good topic to finish on. Because while lighting LEDs is fun for a while, actually seeing your work affect movement in the real world sets the embedded field well apart from say, software-only platforms like web or mobile development.

The safety of motors is covered and how you can add protection to your circuits. It's not hard to blow a MOSFET or your processor when a large motor suddenly stops.

And that's where it ends.

I've pretty much gushed about it. So what didn't I like about the book?

There were a couple of minor things in the area of political correctness that were not necessary. I suspect these were editorial expectations of O'Reilly Media rather than that of the author.

In Chapter Seven, is the suggestion that Master/Slave in MISO and MOSI are out-of-favour terms as an attempt to steer the reader towards “safer” alternatives. I'll stick to the classic terms.

Chapter Five's Interview Question strays into that long worn area of diversity. I am always happy to see this left out.

I will say, however, that the author treated the topic with more care and reason than most. Regardless, I prefer to not have this in my materials.

This is a great book. It's not going to hold your hand, and it's not a book of tutorials. It will, however, become your closest companion to help guide your own learning path, giving you valuable insight into key skills and experience for a career in embedded systems.

It acts as that friendly work mate who loves mentoring and who shares knowledge and experience.

I wouldn't call it a book for beginners. If you have been actively learning various aspects of embedded systems then I think this is the sweet spot for it to work well for you.

So where to from here? Well, it's time to start over and to absorb each chapter more fully. Especially that chapter on mathematics.

Or maybe I'll just jump around this time.