On Wed, 2006-12-27 at 10:05 +0100, Wouter van Ooijen wrote:
> > It can however be very limiting. What if you don't have a serial (or
> > other) interface for displaying/outputting the printf? 
> 
> 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. While very simple to build, it's still an extra effort
just to get some debugging support in there and working (although
admittedly a single LED isn't that hard to get working). 

> > That's the real benefit to me of the ICD2/JTAG type debugging: it has
> > (ideally) no effect whether you use it or not (of course 
> > there are cases
> > where the break points can affect a problem). It's a "back door".
> 
> as I said, it depends a lot on the type of projects you are doing. 

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.

There is one more limitation to ICD/JTAG type debugging that may be
important to some: it tends to force you to use a subset of available
tools. If you want to use a language or IDE that doesn't support
whatever ICD/JTAG solutions are available to your platform, then you're
kind of stuck. This can especially be a problem for people (like me)
using alternate OSs. MChip is the only reason I still have a Windows
machine in this house. All the other tools I use are available in linux
versions. I sure wish MChip would port MPLAB over to Linux, but that's
probably a very long way off.

> jtag
> won't help much if your problem is timing-dependant. (printf will also
> interfere, but it is more 'under your control').

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.

I used to be a huge proponent of printf style debugging. It's very easy
to grasp, VERY flexible, and cost of entry is nearly zero (i.e. with
your LED method). 

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

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