> > I build myself one, using an IR diode. optical isolation, and no
> > connectors needed. and the external circuit is 
> project-independent, can
> > even be used (with an LCD) when no PC is available.
> 
> Neat, but again, you are building something on top of project
> requirements.

Yes, but ICD2 or JTAG style debugging *also* adds to the project
requirements. For instance, for an LPC2106 it claims a *lot* of pins.
For a PIC it claims RB6/RB7 etc.

> True, to an extent. I'll counter that in the number of projects I've
> done, ICD type debugging was/would have been much more useful.

That's says a lot about your projects. For most things (for instance
motorcontrol, datacommunication) I do it would add very little and would
be difficult to use.

> Very true, which is something I mentioned. That said, timing dependent
> problems don't give many options for debugging. About the 
> only one I can
> think of that guaranteed not to interfere would be live stack trace
> emulation. I don't have the equipment for that. Fortunately I haven't
> encountered many of those types of bugs.

but like 'real-time', 'timing-dependent' does not require zero
influenece (or infinite speed), in fact it will (in my cases) often
tolerate a fixed time influence quite well. But not a
stop-and-peek-around approach. As said, that probably says a lot about
my type of projects.

> That said, once I properly learned how to do ICD type 
> debugging, I never
> looked back. While not as flexible as printf style debugging (i.e.
> breakpoint limitations, speed of data transfer, etc.) it is a 
> far faster
> way for me to debug problems. It does take a while to 
> properly get your
> head around how to properly use ICD style debugging, but once I did I
> was set. Funny thing is it took me a short while to get back into the
> printf debugging mindset on my current project.
> 
> To each his/her own. TTYL

very true. I prefer printf-style even on PC's where a debugger is often
available and has much more capabilities than an ICD2 and is much faster
than a wiggler-jtag.

As an example: when debugging the (old) Jal compiler I had to hunt for
bugs in the tree transformer. I did that by printing the before- and
after-transformation trees (often before and after 10's of
transformations) (in a format that was often taylored a bit towards the
problem at hand) (often on paper because it was 10's of pages) and then
inspected the trees to see what was happening. I realy don't see how I
could do that with a debugger at all, much less what advantages a
debugger would have!

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu
 

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