Search in Book Reviews

This is one of the most irritating books that I have reviewed for a long time. It meets a real market need and buried in it is most of what that market needs. The target readership are people who are already competent programmers in a C-syntax language, preferably C, but C++ or Java (and C#) will do. The assumption is that the reader wants to learn the special idioms etc. for programming an embedded system. Because it is by far the most widely used, the author addresses the problem for an 8051. Note that there are over 400 variants of that chip and almost all actually have an 8052 core.

Regular readers of these reviews will know that Chris Hills normally handles books on embedded programming. As I clearly had most of the pre-requisites for reading this specific book I decided it would be an opportunity to discover exactly what it was about embedded programming that I was ignorant of. First let me point out that I learnt my programming on an IBM 1130 with high-level input being through punched cards and output being a line printer. As the machine only had 8k of 16-bit words and I needed to maximise the amount available for data while getting as much speed as possible (all but 8 words of memory were magnetic core, the top 8 words were TTL and doubled as registers) I had to use hand crafted assembler for my main computation and use the consol lights and switches for i/o. I think that comes pretty close to embedded systems programming so perhaps I have a little too much experience.

The first thing that irritated me was to find too many places where text had been duplicated, almost word for word. This is even more annoying when the author repeats a manifest idiocy. On the second page of the Preface we are told:

... Sales of this vast family are estimated to have the largest share (around 60%) of the microcontroller market as a whole, and to make up 50% of the 8-bit microcontroller market.

I read that three times before deciding that the author could not mean that (unless there are a negative number of non 8-bit microcontrollers). That is just bad proof reading. However on page 3 (chapter 1) exactly the same statement is made (word for word). This tells me something else, not only was the book's proof reader not paying full attention but the author was constructing this book by cut and pasting from somewhere else (probably some lecture notes) and was not thinking about it.

The next thing to irritate is the source code layout, just too large and with too much whitespace. The result is that the organisation of the source code hinders the readers understanding of it. Throw in his inconsistence with comment style (sometimes /* */ and sometimes //) and we finish with poor presentation of about 50% of the printed pages. That is an issue that the Addison-Wesley editors should have tackled. (Sorry, Simon and Karen, but you can do better)

Then there is the matter of where the author takes time to emphasise differences. He correctly has his embedded main() returning void while the times when he writes a main for a hosted environment he returns an int - but why does he not explain this to the reader? Even more important for an author who is often repetitious, why does he only once mention the odd declarative syntax used by Keil C for memory mapped addresses? That is a real shaker for someone used to programming in C. Indeed as I read through this book I came to realise just how far Keil C was from Standard C. Note that I do not find that necessarily a bad thing but it should be clearly acknowledged and in a book such as this one an appendix listing the major differences would be very helpful.

The one place that had me spitting was where the author writes about object-oriented programming and C++. His statements in that section are completely unjustifiable urban myths. They simply do not stand up to inspection, yet they will serve to re-enforce the prejudices of many C programmers. He even quotes something Bjarne Stroustrup wrote in 1994 saying that a C++ implementation was likely to run 25% slower than an equivalent application in FORTRAN. If you substitute C for C++ in that statement it would likely be just as true. For numerically intense programming in the middle 1990s FORTRAN had some major advantages over both C and C++ (that is one reason why C99 introduces the new keyword restrict and the new structure of VLAs). A major reason that C is still the main tool for programming small embedded systems is that the dialects used are NOT Standard C. It would take time and resources to develop equivalent variants of C++ and most implementors are still trying to get fully conforming Standard C++ compilers out. Let me say that one more time, a conforming Standard C compiler would not be useful for programming most members of the 8051 family (not least because they do not support bit addressing) Only when people understand their motives can they fairly assess when, if ever, it is time to change.

By now you may think that I do not like this book. You would not be entirely correct. Inside this book there is a much better book trying to get out. The CD provision of both Keil C and a full 8051 simulator for a Windows system is just what the newcomer needs. The underlying ideas in the book are right on target. Now if the author could be persuaded to rework the text, remove the redundancy but spend time on the real differences, reconsider his presentation of source code and check that his code follows a consistent style he would have an outstanding text. As it is he has a good book that is going to irritate the hell out of some readers. Most of us use what we know as a metric to decide the quality of the technical content of a book. It would be easy to dismiss this book on the basis of the superficial errors and the poor assessment of priorities but that would be a mistake. Instead of getting his drafts reviewed by embedded systems experts he needs to include those who have a broader background who would possibly have noted the things he took for granted.

Well worth reading/studying/working through if you want to try your hand at programming embedded systems. Worth the publishers getting a second edition started that will find that excellent book that is hiding in this one.