I looked something like this in January, 2001
© ACM, 2005. This is the author's version of the work. It is posted here by permission of ACM for your personal use. Not for redistribution. The definitive version was published in Proceedings of the 2005 International Symposium on Low Power Electronics and Design.
The more we learn, the more we realize how little we know.
Experience dictates 10 lessons that must be followed for successful
debugging of embedded systems. The first lesson is that programmers
must be familiar and proficient with a diverse array of tools that
includes source-level debuggers, in-circuit emulators, data monitors,
operating system monitors, profilers, memory testers, execution
tracers, and coverage testers. Lesson 2 is to detect memory
problems--classified as leaks, fragmentation, and corruption--early
on, while lesson 3 demonstrates that code efficiency can only be
maximized by understanding how the CPU is executing the code via
performance profiling. The fourth lesson is to clearly indicate
suspicious or potentially problematic code at the outset to avoid
searching for it later, as well as to regularly scan for errors as a
preventative measure; the fifth lesson is to reliably recreate the
problem and then isolate it by keeping detailed logs of any changes
noticed during testing; and the sixth lesson is to furnish a
backwards-traceable record of the embedded system development process
so that future problems will be understood as they crop up. Lesson 7
mandates the use of coverage testing to determine and confirm the
thoroughness of the test suite, with the level of required testing
dictated by the application. Lesson 8 is to test and scan for problems
as you go to avoid much more costly and time-consuming end-cycle
debugging, while lesson 9 is to use dynamic debugging tools such as
operating-system monitors, data monitors, and profilers to analyze
programs while they are in operation. The tenth and final lesson of
successful debugging recommends that the coder refresh his perspective
of a problem by taking time off, in order to prevent a
close-mindedness that can set in during long debugging sessions.
Click
Here to View Full Article
echo 2372976585344052966489671886911366197460427893P |
dc