Few Notes on Software Prototyping

As a teenaged electronics technician I worked for a terribly undercapitalized small company that always spent tomorrow's money on today's problems. There was no spare cash to cover risks. As is so often the case, business issues overrode common sense and the laws of physics all prototypes simply had to work, and were in fact shipped to customers. Years ago I carried this same dysfunctional approach to my own business. We prototyped products, of course, but did so leaving no room for failure....

Managing the Feedback Loop

The last step in most projects is the one we dread the most assigning the blame. Who is responsible for the late delivery Why didn't we meet the specification document Who let costs spiral out of control The developers, that's who. When management sheds blame like a duck repels water, we wonder why we got into such an unforgiving Something happened in this country in the past couple of decades, something scary for the future. We've become intolerant of failure. In 1967 a horrible fire consumed...

Step 5 Measure Your Bug Rates

Code Inspections are an important step in bug reduction. But bugs some bugs will still be there. We'll never entirely eliminate them from firmware engineering. Understand, though, that bugs are a natural part of software development. He who makes no mistakes surely writes no code. Bugs or defects, in the parlance of the software engineering community are to be expected. It's OK to make mistakes, as long as we're prepared to catch and correct these errors. Though I'm not big on measuring things,...

RAM Diagnostics

Beyond software errors lurks the specter of a hardware failure that causes our correct code to die, possibly creating a life-threatening horror, or maybe just infuriating a customer. Many of us write diagnostic code to help contain the problem. Much of the resulting code just does not address failure modes. Obviously, a RAM problem will destroy most embedded systems. Errors reading from the stack will surely crash the code. Problems, especially intermittent ones, in the data areas may manifest...

Breakpoint Problems

Using any sort of debugging tool, suppose you set a breakpoint where the ISR starts, and then start single stepping through the code. All is well, since by definition interrupts are off when the routine starts. Soon, though, you'll step over an EI instruction or its like. Suddenly, all hell breaks lose. A regularly occurring interrupt such as a timer tick comes along steadily, perhaps dozens or hundreds of times per second. Debugging at human speeds means the ISR will start over while you're...

The CMM

Few would deny that firmware is a disaster area, with poor-quality products getting to market late and over budget. Don't become resigned to the status quo. As engineers we're paid to solve problems. No problem is greater, no problem is more important, than finding or inventing faster, better ways to create code. The Software Engineering Institute's (www.sei.cmu.edu) Capability Maturity Model (CMM) defines five levels of software maturity and outlines a plan to move up the scale to higher, more...