On Sat, Aug 27, 2005 at 02:13:34PM -0400, Olin Lathrop wrote:
> 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.  

So it's the live input that I referred to earlier then? Most everything else
I find equally accessible in a simulator. Breakpoints (with conditionals),
watch windows for particular variables, and the like. And with the gpsim
I/O modules, items such as switches, displays, and the like are accessible
in virtual real time.

>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.

Trace code doesn't have to exist in simulation. But I do see the
resource/pertubation issue when running live fire.

I have some "how is it really done" questions. Since I branched off into
bootloader world quite a while ago, I have spent no significant amount of
time working with ICSP/ICD style configurations. PGC and PGD must be used in
these configurations. So what is the trend in terms of applications usage of
these pins? Are they simply dedicated to the ICSP/ICD interface? If they are
multiplexed then how does that interfere with ICSP or ICD?

> 
> 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.

It's that Ferrari thing again. It's kind of hard to appreciate the difference
until you've experienced it.

At this point I'm unsure how I feel about the whole ICD2 vibe. It's relatively
expensive, and I have no tools to use it in my current environment. 

Maybe it's time to spend time examining the underlaying infrastructure. 
This page: http://www.beyondlogic.org/pic/icd.htm outlines the basic ICD
process. But it's unclear whether the same interface exists in the 18F and
dsPIC families.

This is one of the reasons why I would rather depend on specifications rather
than tools.

BAJ
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist