If the measure of a good technical reference is how many times you pick it up for different reasons, Robert Oshana's book tops the list.
Robert Oshana’s recent book “Software Engineering for Embedded Systems (Newnes/Elsevier),” written and edited with Mark Kraeling, is a ‘book for all reasons.’ At almost 1,200 pages, it was obviously written by Oshana and his collaborators to be an all-encompassing reference for professional software developers. But unlike some other all-encompassing references that become dated when some of the content is made irrelevant by later technology innovations, this book has been a reference that I have come back to again and again in the context of my job as a technology editor.
Software Engineering for Embedded Systems, “ is a technical reference useful for many reasons.
(Source: Elsevier/Newnes Publishing)
Its sheer size and range of topics means that the book is not one of those that you pick up with the intent of reading from beginning to end in a few sittings. With 25 chapters and seven appendices and case studies, the book is best used as a resource when you need grounding in topics of importance to developers. Some of the topics it covers include: software performance evaluation, hardware/software co-development, software design patterns, real-time building blocks, user interface design, software quality, and safety-critical development among many others.
Each chapter ranges from 20 to 30 pages and most cover their assigned areas completely. Care has been taken to organize each of them with relevant subtopic headings so you can easily find specifics without being forced to slog through the entire chapter until you find the information you need. In short, it is a very navigable book.
“Software engineering is not the same as software programming,” Oshana writes, explaining the reason for the book and its comprehensive nature. “Software programming usually involves a single developer developing ‘toy’ applications and a relatively short life. Software engineering on the other hand involves teams of developers with multiple roles building complex systems with an indefinite lifespan. There are numerous stakeholders, families of systems, a heavy emphasis on reuse to amortize costs and a maintenance phase that accounts for over 60 percent of overall development costs.”
Amazingly, Oshana and his co-contributors have managed to do something that is not often accomplished: they’ve created complete descriptions of specific areas in a way that does not seem to become dated. Most deal with the aspects of a topic that will remain constant over time and which a developer - no matter what his or her expertise - will find useful.
Because it is a book about software engineering, there are a lot of code examples, mostly in C or C++, but sometimes assembly. But while there are places in the book where something might have been done better with some later extension to either of those languages or compilers, the code usually well illustrates the technical point being explained.
I found insights into topics that I continue to find useful. For example, recently while in the process of creating an editorial package of contributed articles on the pros and cons of C versus C++, and finding myself feeling like a tennis ball being batted back and forth by aggressive opponents, I came across a contribution by Mark Kraeling on the use of C++ in embedded designs. His balanced assessment of its strengths and weaknesses gave me insights that have helped me enormously. Of particular use to me was his evaluation of C++’s features in terms of cost in relation to its impact on runtime resources. Using that definition, he has categorized many of its features into expensive, modestly expensive and inexpensive additions to a developer’s C++ programming repertoire.
“With proper planning and diligence, C++ provides an attractive offering for portability and performance in the embedded environment beyond that of the C language,” he writes, “while not necessarily suffering the overhead of various alternatives in the emulated or interpreted spaces. “
Often I find myself going back to the book again and again, not just for new topics and chapters, but sometimes back to the same topics for different reasons. For example, an ongoing topic I always have an interest in is how developers can make use of various techniques for code optimization. But optimizing for what? Memory? Power? Performance? It is all there in three excellent chapters. Now, however, after reading Jack Ganssle’s recent blog on new enhancements to the C language standard, I found myself going back to those chapters and their wealth of ode examples and taking a closer look the code in the context of C’s new features. Based on my previous experience with the book, I expect to learn a great deal.
If I have any particular criticism of the efforts of Oshana and Kraeling, it is the fact that as complete as it is, it is a bit too light on references. Rather than include them in one all-encompassing section at the end of the book, they are at the end of each chapter. When provided, that makes it easier to find additional information. But some chapters have references and some don’t.
Any questions I might have had about the book disappeared recently when I picked it up again and noticed that Jack Ganske, a regular blogger on Embedded.com, wrote a Forward to the book. He called it a “monumental work,” and commented further that it is probably the most comprehensive book on embedded systems to date and one that is much needed. I agree. It is always at hand in a row of books on my desk where only my most valuable references reside.
— Bernard Cole, MCU and PCB Designline editor,EE Times is an embedded microsystems technology analyst who writes about hardware/software design and use across the range of consumer, industrial, automotive, networking and Internet of Things applications. He can be contacted via LinkedIn, by email at email@example.com, or at 928-525-9087.