 |
|
"The entire point of an embedded microprocessor is to monitor or control some real world event."Although embedded-systems development can be a simple subject, it often falls into the realm of being a black art. Why? Mainly because of the many things that can go wrong in a design. Data sheets and application notes are notoriously hard to read, always biased towards the manufacturer's products, and rarely warn you of pitfalls you may encounter. Often app notes are only helpful as a reference. Most embedded systems designs are unique and cannot be characterized using one manufacturer's app notes and data sheets. In short, embedded systems can do amazing things, but trying to understand how to create systems that work well can be mysterious--unless you have a guru on staff.-- Stuart Ball
Stuart Ball is an one such embedded-systems guru. His book, Embedded Microprocessor Systems: Real World Design, will help novice embedded-systems designers understand and avoid the problems they may face. This book also helps dispel the notion that embedded-system development is a black art. When I brought this book to the office, it was a particularly big hit with recent engineering graduates.
Embedded Microprocessor Systems is a quick read for anyone with a basic electrical engineering background. Many topics are covered; yet little time is wasted on obscure topics. Its real-world examples are especially valuable, including Ball's "DOs" and "DON'Ts." Real hardware is presented in examples that include schematics and code.
The rules for avoiding problems in embedded-systems design are fundamental. Experienced designera are familiar with them, and most of these engineers didn't pick it up from a book. They learned about design pitfalls either from an expert on their project, or the hard way--by finding and correcting problems in their own designs.
Reading this book will save you more time during the design and debugging steps than you spent reading the book. One thing I especially like about Embedded Microprocessor Systems is that it is very concise-- about 38,000 words concise, in fact. Of course, you sometimes pay a price for this. There are instances where a numbered list and a diagram or figure would work better than presenting an idea in paragraph form. For example, the description of accessing dual-ported RAM (page 127) is not as clear as it could be. The memory-access sequence would be easier to understand if it had been written as a list and referenced a timing diagram.
Ball discusses system design in Chapter 1. System design is important because, as Ball says, "if you don't know where you're going, how will you know when you get there?" To summarize (from Chapter 1):
The documentation procedure that I have found useful and that will be followed here is as follows:Still, I would have preferred more on design in Embedded Microprocessor Systems, since that is the fun part in any embedded-systems project. Building hardware, writing code, and debugging the system is more like work. In the real world, design rarely gets the time and attention it deserves. Hindsight makes it easy to say that the system design was shortchanged. But it is hard to know ahead of time where we will need to spend design time to avoid the problems we'll encounter. Many project managers are eager to get right to the implementation, so they can show their boss something. I hope that they will spend at least as much time on design as Ball recommends.
These steps are not necessarily serial.
- Product Requirement Definitions
- Functionality Description
- Processor Selection
- Hardware Design
- Firmware Design
- Integration
Ball generally discusses design appropriately for the type of examples he presents. But I would prefer to see state transition diagrams in addition to flow charts for his examples at the end of the book. And his description of state and data-flow diagrams is inadequate. As design tools, I believe they are more important than he acknowledges them to be. To be fair, there are entire books written on state-transition diagrams, data flow-diagrams, and design methodology.
Chapter 5, "Adding Debug Hardware and Software" is insightful. Understanding this topic is the key to any successful embedded system project. It is important to consider this issue in the design phase, so that debug facilities can easily be added to a system during integration, as they're needed. Although not possible in all designs, the one thing missing from this chapter (and from Chapter 4, "Interrupts in Embedded Systems") is the obvious and simple technique of developing ISRs in a controlled environment. This is where a designer's control over the system stimuli makes it easy to step through code and trace hardware states.
The major criticism I have Embedded Microprocessor Systems is that it just isn't big enough. There are many things left unsaid. I would have liked to see some real examples using real-time operating systems, since they are becoming more important in embedded systems every day. And with Microsoft's Windows CE, the RTOS business will heat up quickly.
It remains true that the conciseness and size of this book is also the reason I enjoyed reading it. Ball got right to the point in the topics that he presents, and I was usually able to easily understand them. The examples are simple and well presented. They are developed throughout the book, with complete documentation in the appendices.
This is excellent primer on embedded systems. Reading this book made me eager for Ball's next book on embedded systems.
-- Michael E. Fitzpatrick (mikefitz@pacbell.net)
| Readability |
|
| Originality |
|
| Organization |
|
| Accuracy |
|
| Consistency |
|
| Depth |
|
| Timeliness |
|
| Editing |
|
| Design |
|
| Overall Value |
|
Explanation of ERCB rating scale: No stars = unacceptable, 1 Star = marginal, 2 Stars = average, 3 Stars = above average, 4 Stars = exceptional, 5 Stars = stellar.