Print PDF
Favorite
Email
Step 3A Minor Digression On Debugging.
If you're like me (and every other programmer in the world) you probably have experienced times when the "error-free" code you've carefully typed in and compiled doesn't do what you expect it to do. Maybe it simply does nothing! So what's the problem? How are you going to find out?
Fortunately, there are several approaches to getting things to work. (Get this book for an excellent treatment of the topic of debugging. http://www.debuggingrules.com/) I'd like to offer a few simple suggestions pertaining to the topic of debugging microcontroller applications.
Step one is to build on what you know. If you have gotten a blinkenlight to work once, then use it again to see where you are in your program. I like to have the LED blink twice to signal the start of the program. You can put the code in to do this initially at the start of your program. Once you know that nothing is wrong with your hardware, create a function to do the blinking. Here's the function I use.
/*------------------------------------------------------------------------
** blinkEm - function to blink LED using PD4
** PD4 must be configured as an output.
** ---------------------------------------------------------------------*/
void blinkEm( uint8_t count){
while (count > 0){
PORTD = _BV(PD4);
_delay_ms(1000);
PORTD = ~_BV(PD4);
_delay_ms(1000);
count--;
}
}
It is now possible to use this function at various points in your code as a signal that the code has executed that far. Knowing the code is running means you can carefully examine each section that has run, but not done what you expected, to find errors.
Changing one thing at a time is a key technique for debugging also (described in the reference above). This classic method works along with "divide and conquer": taking baby steps to add functionality incrementally. This may seem like a slow approach, but it's not nearly as slow as trying to debug a large section of non-working code all at once.
Fortunately, there are several approaches to getting things to work. (Get this book for an excellent treatment of the topic of debugging. http://www.debuggingrules.com/) I'd like to offer a few simple suggestions pertaining to the topic of debugging microcontroller applications.
Step one is to build on what you know. If you have gotten a blinkenlight to work once, then use it again to see where you are in your program. I like to have the LED blink twice to signal the start of the program. You can put the code in to do this initially at the start of your program. Once you know that nothing is wrong with your hardware, create a function to do the blinking. Here's the function I use.
/*------------------------------------------------------------------------
** blinkEm - function to blink LED using PD4
** PD4 must be configured as an output.
** ---------------------------------------------------------------------*/
void blinkEm( uint8_t count){
while (count > 0){
PORTD = _BV(PD4);
_delay_ms(1000);
PORTD = ~_BV(PD4);
_delay_ms(1000);
count--;
}
}
It is now possible to use this function at various points in your code as a signal that the code has executed that far. Knowing the code is running means you can carefully examine each section that has run, but not done what you expected, to find errors.
Changing one thing at a time is a key technique for debugging also (described in the reference above). This classic method works along with "divide and conquer": taking baby steps to add functionality incrementally. This may seem like a slow approach, but it's not nearly as slow as trying to debug a large section of non-working code all at once.
| « Previous Step | Download PDFView All Steps | Next Step » |
 |
Add Comment
|
