bookreview Programming Embedded Systems by Michael Barr and Anthony Massa

[Orunmila]

https://amzn.to/2BR0Xnr  (Link to the book on Amazon)

I have been a fan of Michael Barr since I read about his work with the Toyota Unintended Acceleration case where his team was able to identify and reproduce some very exotic conditions where automotive software failed. (Every Embedded Engineer should at least read about that case, the link is a good summary)

I recently noticed a book co-authored by Barr called “Programming Embedded Systems” and I was excited to get my hands on it as I expected to learn a couple of profound tricks from a master (the book itself is pretty old, 2nd edition published in 2006). 

Unfortunately the book did not live up to my expectations.

Since I am often asked which book I would recommend to start with, I was interested in taking this one for a test drive. Looking over the table of contents I thought that this may be a good beginner’s book, introducing embedded systems. Fair enough. 

Table of Contents:

1. Introduction
2. Getting to Know the Hardware
3. Your First Embedded Program
4. Compiling Linking and Locating
5. Downloading and Debugging
6. Memory
7. Peripherals
8. Interrupts
9. Putting it All Together
10. Operating Systems
11. eCOS Examples
12. Embedded Linux Examples
13. Extending Functionality
14. Optimization Techniques

The first thing I found odd was the choice of development platform. The book is very tightly coupled to the Arcom VIPER-Lite development kit which features a 200MHz PXA255 Xscale processor (based on the ARM v.5TE architecture). This is a PC/104 form factor board and boasts 64MB of SDRAM and 16MB of “ROM” of which 1MB is dubbed as “BOOT ROM”.

In fact it has almost every property which the book uses in Chapter 1 to describe what would NOT be an embedded system! I quote  "The design of an embedded system to perform a dedicated function is in direct contrast to that of the personal computer. It too is comprised of computer hardware and software and mechanical components (disk drives, for example). However, a personal computer is not designed to perform a specific function. Rather, it is able to do many different things. Many people use the term general-purpose computer to make this distinction clear.". 

Looking at the VIPER PC104 computer it seems to me very much general purpose and I would by that definition classify the platform chosen here as a "general-purpose computer" instead. Besides, in my world of 8-bit microcontrollers where 16KB of FLASH and 1KB of RAM is large I do not easily consider a machine with 64MB of SDRAM as an embedded system. I do hate to make the distinction between the two myself though (would you consider e.g. your cellular phone an embedded system? It has more power than the original IBM PC or the Apple II after all!). But to be fair the concepts do transfer and the board at least does not have a Keyboard, mouse and VGA port, so I will go along with that if you could get your hands on one!

I wanted to get at least the specs for the board only to find that the board is no longer available from Eurotech (it took me some time to realize that in 2007 (11 years ago - 1 year after publication of the 2nd edition of this book) Arcom was re-named to Eurotech). In fact it looks like this board has become entirely obsolete and unobtainable which is a pity as the book’s examples are so tightly coupled to this board that you would not be able to “follow along” if you did not have it at hand. 

If only they had just used a simple 8051, AVR or PIC or even an Arduino board instead of this very specialized and unique board nobody has ever heard of!

Over all the book seems to try and do way too much in too little depth, so we are covering the very basics like introducing what is an embedded system and what is a peripheral through to Embedded Linux and Real Time Systems in one book of 260 odd pages. The result is that the book barely scratches the surface on each topic and has almost no meat behind any of these topics. O’Reilly has entire books dedicated to topics which are dismissed in one paragraph in this one.

I was e.g. amused in Chapter 2 when there was a section on “Schematic Fundamentals” showing the symbols used for a resistor, capacitor and a diode and an introduction to what a timing diagram looks like. Chapter 7 explains how bitwise AND, OR and XOR can be used to manipulate bits, etc. but in Chapter 9 the examples start using function pointers without skipping a beat or explaining what a pointer is or how they can point at functions, just assuming the same reader who needed to be explained how to mask bits will be adept at using pointers ...

There were also a number of subjective “facts” in the book which I do not quite agree with, e.g. this table:

I seriously question the numbers in this table, e.g. I would say from experience that the number of units sold goes up as systems become smaller and simpler. I think I would go out of business rather quickly if I did $100K developments for products selling at $10 a piece and never sold more than 100 pieces of these. 

I would also say that my car’s ABS controller (likely on the lower end of that resource scale) must be fail-proof, while my Cellular Phone (on the High scale) requires me restarting it regularly, and I would say my ABS computer would have a life of 10’s of years while my phone is hardly going to live for more than 2. So let’s just agree that plenty of embedded systems below 64KB are safety critical and sells millions of units and use nanowatts of electricity so I disagree with the last 4 rows there.

It seems like this book is trying to cater for fairly experienced programmers as well as complete novices. My opinion is that any book should always pick a specific audience and speak to that audience well. If you try to speak to everyone you will please nobody. 

If the reader is someone so green that they cannot mask in bits and do not know how to compile and link their program the same book is not appropriate for showing people real-time OS concepts, schedulers and function pointers. I think the book leaps forward too far too often in a way that newcomers will feel that half of the book was so basic that they already know this, and the other half is so advanced that it would be out of their reach to grasp. And for experts the advanced parts of the book are so shallow that they would get very little value out of it, and of course the other half would be a waste of time.

So in summary I think the book covers a lot of ground by scratching the surface on just too many concepts without getting deep enough into any of them to really teach anybody anything new about Embedded Programming.

I always make sure to read a couple of the good and bad reviews on Amazon and the reviews there were very much in line with my experience. Like one of the reviewers this was the first time I bought an O’Reilly book where I really felt that it was not worth the money. 

One reviewer I think summed it up the best “... To experienced programmer, this is never the book for you. To beginner, maybe this is easier to understand, but i really dont think this will help you in EMBEDDED C programming...” you can read his full review as well as the others here https://www.amazon.com/review/R10VHMT76YWZVV/ref=cm_cr_srp_d_rdp_perm?ie=UTF8&ASIN=1565923545

 

[N9WXU]

I am shocked that O'Reilly would publish such a shallow book.  I have a number of their books and I have always found them very useful for technical topics.

[ric]

On 12/31/2018 at 12:37 PM, Orunmila said:

...

I have been a fan of Michael Barr since I read about his work with the Toyota Unintended Acceleration case where his team was able to identify and reproduce some very exotic conditions where automotive software failed. (Every Embedded Engineer should at least read about that case, the link is a good summary)

...

That court transcript is fascinating reading, but I can't help giggling every time I read about "parody bits", whenever he was plainly saying "parity bits" 😉

 

[KTrenholm]

That court transcript was a fantastic read (I also had a good chuckle at "Parody Bits"). 

That link also led me to the Barr Embedded C Coding Standard, which was also worth a read for me, as I'm currently working under mostly a set of my own rules gathered through just personal experience.  Might be finally time to have a formalized standards doc.

Shame the textbook is kind of a dud.

 

 

 

 

[Orunmila]

33 minutes ago, KTrenholm said:

That link also led me to the Barr Embedded C Coding Standard, which was also worth a read for me, as I'm currently working under mostly a set of my own rules gathered through just personal experience.  Might be finally time to have a formalized standards doc.

Coding standards is a interesting and complex topic. We have it listed fairly high up on the list for a blog entry coming in the next couple of weeks.

In the meantime this may be of some help to you 🙂

http://www.rosvall.ie/cgi-bin/genCodeStd.pl

Just fill out the forms and it will generate a beautiful coding standard for you !

[KTrenholm]

4 minutes ago, Orunmila said:

Coding standards is a interesting and complex topic. We have it listed fairly high up on the list for a blog entry coming in the next couple of weeks.

In the meantime this may be of some help to you 🙂

http://www.rosvall.ie/cgi-bin/genCodeStd.pl

Just fill out the forms and it will generate a beautiful coding standard for you !

 

Oh wow this is VERY cool.  I'll absolutely make use of this, at the very least to just mess around with and see if I can put my own existing personal "standards" from my brain into documentation.

[Orunmila]

I do not want to write the whole blog here, but coding standars are much more important than people realize. There is a great talk by Chandler Carruth (it is good but rather long, start watching here) which explains how using consistent patterns when writing code reduces the order of complexity of maintaining the code.

 

 

[gmon]

On 12/30/2018 at 7:37 PM, Orunmila said:

I seriously question the numbers in this table

You have mis-interpreted the table, each row is meant to be independent. I thought the same thing, until I realized that the columns were not to be taken as a whole, but just defining low, medium, or high for each independent category column.