Byron A Jeff wrote:
> As a gdb user I can appreciate a debugger to a point. I find that
> simulators help with gross errors. But as a "love what you learn"
> question, what does the debugger bring to the table that's outside
> of the scope of "normal" debugging activities using I/O devices
> such as serial interfaces and LCDs?

I'm amazed you're even asking this, Byron.  The big everwhelming advantage
is that you can single step your code, set break points, and look around at
state without having to decide up front which limited state you are going to
spit out at which limited set of circumstances.  Other advantages:

2 - You don't have to write the code to send trace information somewhere,
nor the code to either format it nicely in the PIC, or receive it with a
special program which formats it for you to see.

3 - Just the existance of trace code can alter the problem you are trying to
find.  Other code may be moved around, the timing will be different, stack
usage will be different, etc.  Sometimes this will make the original symptom
disappear, and sometimes it can introduce symptoms that are only due to the
trace code in the first place.

4 - Trace code can require hardware resources that are already all in use,
like extra pins, UART, etc.

In short, debugging with a real debugger (ICE even better) is waaaaaay more
efficient than the equivalent of sprinkling PRINTF around, especially on a
machine that doesn't have an OS and a notion of standard output.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist