Section 1.6 Debugging
Once a project has been designed and implementation has begun, it will inevitably be time to start debugging. In order to make debugging as painless as possible, be smart about how code is implemented. Work on high-level functions first. Once they are working as expected, add other subroutines only one at a time. If more than one bit of extra functionality is added at once, and something doesn’t work, it will be difficult to determine what component of the design doesn’t work. In the process, keep code well-commented, and document design decisions, research, implementation ideas, and notes about what does and doesn’t work (and why) in a design notebook.
If something doesn’t work (which will inevitably happen in any design), rather than diving in headfirst and changing code, find out what the code is actually doing. Then, and only then, can you change it to what it should be doing. This requires an intimate understanding of both the software and hardware components of your design. It may first need to be determined if hardware or software is at fault. For this reason it is imperative to test hardware before integrating it with software, to avoid problems later on.
Some hardware debugging steps are listed below.
-
Check that LEDs light before using them
-
Check pushbuttons with a multimeter on continuity mode
-
Use a tabletop multimeter or digital logic probe (for static signals)
-
Use an oscilloscope (for time-varying signals)
Some software debugging steps are listed below.
-
Ask your peers take a look at your code
-
Walk through the code step-by-step and see what results
-
Comment out lines of code one line at a time until the program works, then uncomment one line at a time until it doesn’t work (the line that breaks the code is likely at fault)
