Why Arnold Berger wrote his latest book

Over the last five years Associate Professor Arnold (Arnie) Berger’s collected ideas for a book about debugging and when he went on sabbatical in spring 2018 the book began to take shape. In August 2020 Dr. Berger’s newest book “Debugging Embedded and Real-Time Systems: The Art, Science, Technology and Tools of Real-Time System Debugging” launched. He has found that “if problems crop up, as they invariably do, students lack the diagnostic skills to analyze the problems and, in a systematic way, zero in on the possible causes, and then find and fix the bugs”—this is where his book comes in.

Excerpted from “Debugging Embedded and Real-Time Systems: The Art, Science, Technology and Tools of Real-Time System Debugging” preface:

After having taught embedded system design for many years, I’ve come to the conclusion that we are failing as teachers because our students can write a program in assembly, C, C++, C#, some Arduino dialect, or Verilog, and get their program to compile. However, if problems crop up, as they invariably do, students lack the diagnostic skills to analyze the problems and, in a systematic way, zero in on the possible causes, and then find and fix the bugs.

What I observe with depressing regularity is that students take the “shotgun approach.” They try a bunch of changes at once and hope for the best. Even more disturbing, rather than try to find and fix a problem, students will just throw away their code or their prototype and start all over again, hoping beyond hope that will fix the problem. You might assume when the students of today become the engineers of tomorrow and are totally immersed in product design, they will have developed the debugging skills they need to do their job in the most effective manner. I’ve learned that assumption does not hold true.

Before I became an academic, I worked in industry, creating design and debug tools for embedded systems designers. In particular, I designed and led teams that designed logic analyzers, in-circuit emulators, and performance analyzers. These were and in many cases still are complex instruments designed to solve complex problems. Just learning to effectively use one of these instruments can be a chore that many engineers don’t feel the desire to invest the time required to learn.

Maybe you’ve been there yourself. Do you do a mental cost/benefit analysis to invest the time to wade through a set of manuals, or just dive in and hope for the best? One of the most brilliant engineers I ever worked with, John Hansen, made this observation that came to be known as Hansen’s Law, which says:

If a customer doesn’t know how to use a feature, the feature doesn’t exist.

Let’s discuss this book. I started to think about writing a book about debugging about 5 years ago and was pretty much a germ in my brain that would surface every now and then and I’d write down some ideas. I got serious about it in the Spring of 2018 when I spent a sabbatical leave of absence at the University of Sydney. Having an empty office and long blocks of uninterrupted time, the book began to take shape. I managed to write the first two chapters and the introduction while in Sydney, and then finished the research and the remaining chapters over the course of the next two years. The book was released in August of this year.

The initial focus is aimed at the student. Not just the ones who want to enter the field of embedded systems design, but rather at all Electrical engineering, computer science, or computer engineering EE, CS, or CE students who wished to improve their skills in the debugging of their designs. Also, being you would be able to casually mention during a job interview that you’ve taken some effort to go beyond just doing projects by also being able to , but to also to bring defect-free projects to completion that are defect free. You’ve just expressed to the interviewer that you are entering the job market with a skillset beyond what your graduating peers might have.

For the experienced engineer who is already a practitioner and wishes to hone your his or her skillset, my goal is that this book will provide you with a roadmap to tools and techniques that you may not be aware of, or to more efficient ways to solve the problems that seem to crop up on an ongoing basis.

In researching and writing the book, I decided that application notes and white papers from the vendors themselves were the very best sources of information on specific categories of bugs. Having written more than a few of these articles myself, I am pretty confident that this was a good decision. If you think about it, it becomes obvious. Companies are constantly polling their customer base for design and debug problems that invariably appear as the technology advances. These customer problems are the driving force for the creation of tools that will solve the problems, or at least, point to the source of the problems.

Once the tool is invented, its potential value must be explained to the customer base, which leads to presentations at conferences, technical articles in industry publications, and application notes that link the problem, the source of the problem, the tool, and the solution in a way that the engineer can internalize and justify purchasing to upper management. While these articles are clearly self-serving for the companies generating them, they are also valuable resources that provide the best up-to-date and practical information that engineers need. For me, they became my principal resource for this book.

I’ve tried to make this an easy read, rather than a pedantic tome. I’ve put a lot of personal anecdotes in because they can help make a point and they’re fun to read and fun to write. I took my lead here from Bob Pease’s classical book, Troubleshooting Analog Circuits. Many senior engineers remember Bob’s column in Electronic Design Magazine©, “What’s all this….”

His book and these columns were classic reads and I am unashamedly borrowing his conversational style for this book as well. As an aside, my favorite “What’s all this….” column was about his analysis of these ultra-pricy speaker cables that were cropping up, claiming audio advantages over simple lamp cord wires. Bob does a rigorous analysis that is both fun to read and educational at the same time. More to the point, he pretty well puts the audio- superiority claims to bed.

About the Author

Arnold Berger has a doctoral degree in material science from Cornell University, with 20+ years of industrial experience ranging from hardware design engineer to Director of Research and Development (R&D) at several companies including Ford Motor Company, Hewlett-Packard, Advanced Micro Devices and Applied Microsystems. Dr. Berger has more than 15 years of teaching experience and was the first chair of the Division of Engineering & Mathematics in the School of STEM.

Dr. Berger has published over 60 papers, holds four patents and has authored two textbooks on computer architecture and embedded design. His research interests include designing tools for debugging embedded systems, enabling remote access of student lab experiments, and automatic plagiarism detection.