For the BIOS engineer, most computer science books are irrelevant. Browsing through the book shelves at your local book store reveals zillions of books on game programming or Java or databases but just a few tomes devoted to embedded software . And even those few are focused on surviving your RTOS or managing your serial ports, not the small, low-level, specialized code used in the world of BIOS. Where is that book on SMM and S3 and debugging over I2C? Would I fall asleep reading it?
The book If I Only Changed the Software, Why Is The Phone on Fire? (Newnes, 2007) is both practical and intriguing. Organized as a series of mini-mysteries, each chapter presents the on-going challenges of an engineering team focused on a wide variety of embedded products. Each of these products is failing in a dramatic way, from the eponymous phone to an overheating oven on a manufacturing line. At various points during each story, clues are given, including code snippets and results of tests performed by the programmers and the reader is challenged to find out what is going wrong.
The stories have the classic mystery elements: red herrings, character conflicts, time pressure and, of course, the villains. Lurking below innocent-seeming code listings are the typical culprits of embedded programming: unsigned integer underflow, interrupt latency, buffer overflows, uninitialized variables. The investigation techniques may not be CSI:Miami, but they are part of every embedded engineer's debugging toolbox: how to reproduce the problem, how to get the data out (even in closed systems) and how to brainstorm.
Along the way, Simone tries to impart some helpful embedded debug hints, which she collects in the "notebook" of Li Mei, the newbie engineer in the team. She also manages to slip in some management advice, through the interactions between the team lead, Oscar and the folks in his team, Ravi, Josie and Li Mei.
The book succeeds for BIOS engineers because the problems are true-to-life, dealing at the lowest level with hardware/software interaction. The code examples are in C and various 8-bit assembly-language dialects, which made me feel at home as an ex-6502 guy. It was fast-paced and deeply technical, a rare combination. It was easy to translate what I learned into what I debug every day.
Highly recommended.
Tim
