[PIC] ICD3 vs ICE
alan smith
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Dwayne Reid
>Can anyone that has both an ICD3 and a ICE..comment on how well the
>ICD3 works as an ICE? I thought I had read someplace that it was
>intended on replacing it. Advantage of an ICE over the ICD3 for debugging?
We have a couple of MPLAB ICE2000 units, several ICD2s and a couple
of ICD3s. Although I don't use the ICD3 yet, my buddy does and
really likes it compared to the ICD2. However, I will confine my
comments to comparisons between the ICE2000 and ICD2.
Major differences:
1) Cost. The ICD2/3 costs WAY less than an ICE2000.
2) On-going cost: the little header boards that you need when
debugging a low-pin-count PIC cost WAY less than a comparable
processor module for the ICE2000. Larger PICs don't need that little
header board, so even that low cost is eliminated.
The ICE2000 requires an expensive processor module for every
different PIC that you use it with.
3) Speed: the ICE2000 is WAY faster to use when debugging. You don't
have to wait for the processor or header board to be re-programmed
everytime you do something.
4) Breakpoints: the ICE2000 supports an unlimited number of
breakpoints. The ICD2/3 supports only one breakpoint, at least with
the PICs that I use. I'm told that some newer PICs will allow up to
two breakpoints.
5) Complex breakpoints: the ICD2/3 can't do these. You do need the
ICE2000 if you are trying to set up complex conditions that will
cause a break or start a trace.
6) Trace memory: the ICD2/3 can't to this. You need the ICE2000.
My take on the subject: I use the ICD2/3 while I'm evaluating a PIC
that I can't shoehorn into one of the ICE2000 processor modules that
I already have. Once I've made the decision to do significant work
with that new PIC, I purchase one or two processor modules for it. I
try to ensure that the project's development cost to the customer
reflects at least a portion of the cost of purchasing those processor modules.
Part of the charm of the ICE2000 is that it REALLY speeds up the
edit/compile/run/crash loop that I often do when I'm closing in on a
bug. You can evaluate minor code changes in just a few (3-5) seconds.
I do use the ICD2 when I'm troubleshooting in the field. Its
entirely adequate and does everything that I need to do while
troubleshooting - its just not as quick as the ICE2000.
dwayne
--
Dwayne Reid <dwa...@planet.eon.net>
Trinity Electronics Systems Ltd Edmonton, AB, CANADA
(780) 489-3199 voice (780) 487-6397 fax
www.trinity-electronics.com
Custom Electronics Design and Manufacturing
alan smith
--- On Tue, 6/15/10, Dwayne Reid <dwa...@planet.eon.net> wrote:
Xiaofan Chen
> Thanks..good info. what about the new "realICE"...
> is it a replacement for the ICE2000?
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en534451
Real ICE is still an In-Circuit-Debugger and not an In-Circuit-Emulator
despite the name. It still requires the debug header for those chips
without the debug silicon. But it is the flagship debugger from Microchip now.
So if you can afford to buy it, buy it by all means. It is a bargain for
its capability (eg: tracing).
http://www.microchip.com/realice
As for ICE2000, despite its benefits as a *REAL* In-Circuit-Emulator,
it is an old product and only supports PIC12/16/17/18. It does not
support dsPIC30/33 and PIC32. It does not support 3.3V only
PIC18s (eg: PIC18J) either. If you have it, be happy. If you do not
have it, never mind.
http://www.microchip.com/ice2000
ICE4000 is not recommended for new design. It only supports
5V PIC18 and dsPIC30.
http://www.microchip.com/ice2000
--
Xiaofan http://mcuee.blogspot.com
peter green
> Thanks..good info. what about the new "realICE"...is it a replacement for the ICE2000?
Afaict the ICD3 is based on the realice but with the trace support and
high speed coms stuff ripped out.
It seems if you want trace on 5V 18F or on lower pic families you still
need one of the old emulator units (which do still seem to be available
at least from digikey though for some reason the minimum order quantity
on the ICE4K from them is 2)
Xiaofan Chen
> I don't see the 16F parts in the supported list for debugging at all
> (though my mplab install isn't all that up to date).
Yes you MPLAB is quite old. Now Real ICE and MPLAB ICD 3
(and PICkit 3) supports almost all flash PICs (PIC12/16/18/24/32,
dsPIC30/33), programming or debugging.
--
Xiaofan http://mcuee.blogspot.com
alan.b...@stfc.ac.uk
> for the ICE2000?
Download the new MPLAB 8.53 release notes.
Unzip into suitable directory.
Look at second file (called 'processor support' IIRC). It lists the
debugging support for all the possible combinations of processor
supported by this release, and the possible ways to do debugging, and
the number of breakpoint/trace/etc options for each combination.
--
Scanned by iCritical.
Josh Koffman
> 5) Complex breakpoints: the ICD2/3 can't do these. You do need the
> ICE2000 if you are trying to set up complex conditions that will
> cause a break or start a trace.
The ICD2, PicKit2 and PicKit3 that I have all support what they call
complex breakpoints in the form of breaking on read or write of a
certain register, or breaking when a specific value is in the
register. I think you can break after a certain number of passes, but
I've never really used that. Is that what you mean, or is there
another kind of complex breakpoint?
> 6) Trace memory: the ICD2/3 can't to this. You need the ICE2000.
What is trace memory? I've been trying to find a description but so
far I'm failing.
Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
-Douglas Adams
Barry Gershenfeld
> far I'm failing.
>
> Josh
>
Imagine single-stepping with the debugger, and taking a snapshot each time
you hit the step button. The trace is a review of what instructions got
executed, where the next instruction was fetched from, what was in
such-and-such register, maybe even a record of bus signals. I made up that
feature list since I don't actually have one, but it's based on what we did
many years ago with similar equipment.
The trace memory is where you put all that info, so you can look back 128
instructions or whatever. And often you can set up a trigger to capture
what's in the trace memory (like a "freeze" option) even though you keep
running.
Josh Koffman
> Imagine single-stepping with the debugger, and taking a snapshot each time
> you hit the step button. The trace is a review of what instructions got
> executed, where the next instruction was fetched from, what was in
> such-and-such register, maybe even a record of bus signals. I made up that
> feature list since I don't actually have one, but it's based on what we did
> many years ago with similar equipment.
>
> The trace memory is where you put all that info, so you can look back 128
> instructions or whatever. And often you can set up a trigger to capture
> what's in the trace memory (like a "freeze" option) even though you keep
> running.
Oh, cool! Thanks for the explanation, that sounds really useful
actually. To verify routines I'll sometimes step through a bunch of
code while watching various registers. If I'm understanding you
correctly, I'd be able to say, set a breakpoint at the end of a
section of code then watch what the registers did for the last X
number of steps. That seems much quicker! Do you get to choose which
registers it follows or does it dump the entire memory? Would that
slow down execution (like the old "jog" mode)?
Is there anyone with a RealICE that can show me a screenshot of how
trace appears? I'd love to see if it will actually do what I think it
does.
By the way, I've noticed that single stepping on the PK3 seems to be
quicker than with the PK2. I'm guessing RealICE should be at the same
speed as PK3/ICD3 right?
Thanks!
Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
-Douglas Adams
--
Dwayne Reid
>On Tue, Jun 15, 2010 at 3:34 PM, Dwayne Reid <dwa...@planet.eon.net> wrote:
> > 5) Complex breakpoints: the ICD2/3 can't do these. You do need the
> > ICE2000 if you are trying to set up complex conditions that will
> > cause a break or start a trace.
>
>The ICD2, PicKit2 and PicKit3 that I have all support what they call
>complex breakpoints in the form of breaking on read or write of a
>certain register, or breaking when a specific value is in the
>register. I think you can break after a certain number of passes, but
>I've never really used that. Is that what you mean, or is there
>another kind of complex breakpoint?
Yeah, there is.
With one of the emulators (PICmaster or ICE2000), you can set up
sequential conditions where each trigger has to occur before the
break actually occurs. The easiest way to see this is either by
reading the help or by setting MPLAB up to use the ICE2000, then
looking at the complex breakpoint setup pages.
> > 6) Trace memory: the ICD2/3 can't to this. You need the ICE2000.
>
>What is trace memory? I've been trying to find a description but so
>far I'm failing.
I may be using the wrong term, but its a log of every instruction
executed by the processor. Although the trace files can be long
(enormous), they are occasionally the easiest way to find out HOW the
PIC got to where it went off the rails. I've only used it a few
times, but it really saved me a LOT of time on some of those occasions.
You can start and stop the trace by using the same complex trigger
setup used for breakpoints.
dwayne
--
Dwayne Reid <dwa...@planet.eon.net>
Trinity Electronics Systems Ltd Edmonton, AB, CANADA
(780) 489-3199 voice (780) 487-6397 fax
www.trinity-electronics.com
Custom Electronics Design and Manufacturing
--