Pickit3 - ICD3 - Anyone with experience in both?

[atferrari]

I have the chance to get almost for free one Pickit3 or an ICD3.

Is there anyone using / having used both to tell what is good and what is bad.

If I get ICD3, am I leaving behind any advantage in the Pickit3 that isn't with ICD3.

Who's easier to use when past of the learning period?

BTW I am aware of the difference in speed.

Help appreciated.

[Howardlong]

I use both, and a Real ICE too.

The ICD3 is definitely faster than the PicKit 3, and I use the ICD3 99% of the time. The Pickit 3 is handy if I'm away from the lab as it's less stuff to carry.

With the ICD3, if you switch between MPLAB and MPLAB X IDEs, then you have to switch drivers which is a bit of a PITA.

Both support the option of powering of the target from the debugger, but I rarely rely on it, I much prefer to provide my own power. The Real ICE does not provide power to the target.

The ICD3 also supports software breakpoints: on the Pickit 3 you're restricted to hardware breakpoints and with that you frequently end up skidding past the actual breakpoint.

Edit: in case you haven't found it, there's an useful functional comparison chart here: https://microchip.wikidot.com/tools:debugger-comparison

Although I have all the advanced trace options for the Real ICE, I've never used them, they're a bit of hassle setting them up. My Real ICE is also one of the first off the production line, and it has some interesting "features" shall we say to be aware of that I have to work around, it's a bit like a dealing with a difficult child at times! The ICD3 on the other hand is very reliable, as long as you remember to switch drivers if switching between MPLAB and MPLAB X.

[atferrari]

The ICD3 also supports software breakpoints: on the Pickit 3 you're restricted to hardware breakpoints and with that you frequently end up skidding past the actual breakpoint.

I know I can read about but I am far from where I could do it at ease. What are those hardware breakpoints? (Still with Picstartplus  )

It seems that I should go for the ICD3, right?

Gracias for replying, Howard.

[Howardlong]

The ICD3 also supports software breakpoints: on the Pickit 3 you're restricted to hardware breakpoints and with that you frequently end up skidding past the actual breakpoint.

I know I can read about but I am far from where I could do it at ease. What are those hardware breakpoints? (Still with Picstartplus  )

It seems that I should go for the ICD3, right?

Gracias for replying, Howard.

With hardware breakpoints you're restricted to the on chip resources. Some low end chips only have one or two hardware breakpoints (although these chips also don't support software Breakpoints either). Higher end chips like the PIC32 have 6 or so. The problem with hardware breakpoints is often skidding. There's a note on this here: http://microchipfae.com/tag/skidding/

Edit: Picstart Plus? Wow, haven't used one of those for a loooong time!

[Gixy]

ICD3 has many more features and is much more reliable. I broke several devices with Pickit3 on Windows 8.1.

[atferrari]

ICD3 has many more features and is much more reliable. I broke several devices with Pickit3 on Windows 8.1.

Could you elaborate briefly?

[Gixy]

See this topic:

https://www.eevblog.com/forum/microcontrollers/pic-programming-debugging-tools-with-windows8-1/msg542058/#msg542058

[BloodyCactus]

I have both and only use ICD3, but I have an ICD3 to Pickit3 adapter (the little rj11 to icsp 6 pin board). the icd3 is heaps better than pickit3

[mikeselectricstuff]

I tend to use ICD3 for 16 & 32 bit devices and PK3 for 8 bit.
ISTR there was once a reason for not using ICD3 on 8bit but don't recall exactly what - I have a feeling that there was some permutation of IDE and compiler where it wouldn't automatically program after compile - may well not be an issue any more, but the habit has stuck.

ICD3 is definitely faster, but only noticeable on larger parts with more memory.

PK3 has programmer-to-go mode, which is really handy for production programming, even if only a few devices. It's also cheap enough to be near-expendable, e.g. on things where nasty voltages may go where they shouldn't

[JoeN]

"skidding"

 

Does that leave "skidmarks" in memory?

It's interesting that this doesn't happen on any PC environment I have ever worked with and Intel processors have much deeper pipelines than Microchip has ever designed.  What gives?

[Sal Ammoniac]

On the PIC32 the ICD3 is 10x faster than the PICkit3. I consider the PICkit3 unusable for debugging on the larger parts. It typically takes 10 seconds to single-step one line of code. The ICD3 steps code as fast as you can click the mouse.

[marshallh]

The Picshit3 is a flaming you-know-what.
Always go for the puck ICD3. Loads better

[atferrari]

It seems that now I know what to ask for.

Gracias to you all for replying. 

[AndyC_772]

I feel left out now. I use a PICKIT 3 all the time, never had a problem with it.

I've also tried an ICD3 and not really found much difference.

[Howardlong]

"skidding"

 

Does that leave "skidmarks" in memory?

It's interesting that this doesn't happen on any PC environment I have ever worked with and Intel processors have much deeper pipelines than Microchip has ever designed.  What gives?

It depends on the hardware architecture. In a PC environment, software breakpoints are probably used most of the time for code breakpoints as there's no practical limit. Since the 80386 there has been support for hardware breakpoints on chip. I can't remember if those skidded, I'd have to get out my Borland Turbo Debugger circa 1989 or so to find out! Hardware-assisted global data watch breakpoints quite often skid too.

The PIC32 doesn't skid but the other PICs do. It can be quite irritating, particularly at first, but you come to get used to it. Or use software breakpoints instead if the chip and debugger support it.

For a software breakpoint, an instruction is inserted, usually hidden from the user, at the point of breakpoint. In a PIC, this means writing to flash, so this is why the default is usually to use hardware breakpoints. On a PC it's a single byte instruction, 0xCC, or INT 3, and unless it's in an exceptional circumstance, it's in RAM, so easy to do. Back in the days when you wanted to debug into the BIOS, you would need hardware assisted breakpoints as there was no way to insert the debug byte onto ROM.

[helius]

It sounds like an imprecise exceptions problem. Several architectures suffer from imprecise floating-point exceptions (where the faulting instruction may not be reported precisely).

[Sal Ammoniac]

I feel left out now. I use a PICKIT 3 all the time, never had a problem with it.

I've also tried an ICD3 and not really found much difference.

It all depends on what you're doing. If you're programming a few hundred bytes of code into a PIC 16F, then a PICkit 3 is probably okay, but of you're programming 512KB into a PIC32, then it's glacial, especially if you need to do any debugging.

[AndyC_772]

Fair enough, I've only used PIC32 once, and it wasn't a hugely complex project, it just needed lots of I/O pins.

Nowadays, if I need something faster than a PIC18, I use an STM32.

[bson]

On a somewhat tangential note, does using a dedicated ICE header provide more than two hw breakpoints with either of these, or does that require Real ICE?  It's not clear if the breakpoints are in the ICE chip debug/trace logic or in the main control unit.  (I assume the former?)