Should I consider buying the PICKit 4?

[technix]

I already have an Atmel-ICE and a PICKit 3. Am I going to miss out anything if I skip the PICKit 4? I don't use PIC often but there will be a few projects that have to be based on a PIC. As of AVR they are my main low-power low-cost chip of choice as a tier below STM32.

[@rt]

I still have the far superior PicKit II here and have not yet used any of the controllers that it can’t support.

Lucky, I get to skip the PicKit III altogether. I do like the idea of the SD Card slot for the OTG programming,
but it’s really a previous project long done now, where it would have been handy for me.

For PicKit 4, the last selling point they have for me is faster programming. I don’t even recall seeing anything about
any extra device support over PicKit 3.

I don’t see any LEDs on the PicKit 4, but to be honest, I only ever look a them when a device doesn’t program,
and the presence of some LEDs doesn’t mean I don’t have to program it again if  there was a bad socket connection the first time.

[IonizedGears]

I purchased the pickit4 coming from a clone pickit3. It has an RGB led that is guided to a plastic strip right above metal front panel.

Sent from my Pixel XL using Tapatalk

[ggchab]

I also bought one because there is currently a promotion code.
I hope
 - it will not download a different firmware for each family
 - it will program chips faster
 - it will support the chips I am using (promised by the support of Microchip)

[Howardlong]

I also bought one because there is currently a promotion code.
I hope
 - it will not download a different firmware for each family
 - it will program chips faster
 - it will support the chips I am using (promised by the support of Microchip)

Once I’d fixed a hardware flaw on my PICkit 4, I found that thankfully it does seem not to have to download new firmware every time you change device sub families.

For most chips I’ve tried, it does program them a lot quicker, particularly if you have a lot of flash to program (although you can sometimes mitigate against this by moving the IVT in some processors where by defualt they are at the end of flash, so the whole flash range gets written).

I did find that I had no programming speed benefit with a PIC16F1509 for example, but all PIC24 and PIC32 I tried have very significant speed increases using the PICkit 4 over both the PICkit 3 and ICD 3.

The biggest negative for me is the PICkit 4’s lack of comprehensive device support. For some it may be the lack of Programmer to go facility, but that’s not a feature I use.

Even when it does have support, some sub features are not yet supported such as debug header boards or debug at full device speed.

Two big pluses for me over the PK3are being able to place a breakpoint while code is running, and software breakpoint support.

[mikeselectricstuff]

For most chips I’ve tried, it does program them a lot quicker, particularly if you have a lot of flash to program (although you can sometimes mitigate against this by moving the IVT in some processors where by defualt they are at the end of flash, so the whole flash range gets written).

Seriously ? Isn't it smart enough  to skip unused areas?

[Howardlong]

For most chips I’ve tried, it does program them a lot quicker, particularly if you have a lot of flash to program (although you can sometimes mitigate against this by moving the IVT in some processors where by defualt they are at the end of flash, so the whole flash range gets written).

Seriously ? Isn't it smart enough  to skip unused areas?

Nope.

An example I have is a PIC32MX1/2/5 Starter Kit which has a PIC32MX570F512L on board.

With a simple blinky as an example, if you copy the processor's p32MX570F512L.ld file to the project directory and add it to the project in MPLAB X, then modify the line

Code: [Select]

PROVIDE(_ebase_address = 0x9D07F000);

to

Code: [Select]

PROVIDE(_ebase_address = 0x9D001000);

it will program much quicker.

Programming times in seconds (already compiled code, any required programmer firmware is already installed, but includes initial debugger connection time):

Programmer / 500k code / 1k code / 1k code+Modified .ld
PKOB 48 / 47 / 8
PK3 47/ 50 / 8
ICD3 20 / 17 / 8
RealICE 21 / 20 / 7
ICD4  20 / 8 / 8 **** Seems to be intelligent about unused flash
PK4 20 / 8 / 8 **** Seems to be intelligent about unused flash

****

PKOB, PK3, ICD3, RealICE,  standard .ld linker file, programming areas:
program memory: start address = 0x1d000000, end address = 0x1d07ffff

PKOB, PK3, ICD3, RealICE,  modified .ld linker file, programming areas:
program memory: start address = 0x1d000000, end address = 0x1d001fff


ICD 4, PK4,  standard .ld linker file, programming areas:
program memory: start address = 0x1d000000, end address = 0x1d0003ff
program memory: start address = 0x1d07f000, end address = 0x1d07f9ff

ICD 4, PK4,  modified .ld linker file, programming areas:
program memory: start address = 0x1d000000, end address = 0x1d0003ff
program memory: start address = 0x1d001000, end address = 0x1d0019ff

Now, if I use the original .ld, and deliberately fill flash with 500kB of 0x55, the timings of the ICD3, RealICE, ICD4 and PK4 are almost identical, 20s +/- for all four. PKOB and PK3 both come in at around 48s +/-.

So I guess on the plus side the ICD4 and PK4 are faster at programming in this use case than the ICD3 or RealICE when flash isn't full.

[NorthGuy]

ICD4  20 / 8 / 8 **** Seems to be intelligent about unused flash

I guess that's the reason it appears faster than its ICD3 predecessor. Just one bug fix ...

[JPortici]

bottom line,
if/when they add parts support the PK4 will be just as good as the ICD3 (better at debugging than PK3, can add breakpoints while running etc).
Very good as it's 1/5 of the price
if/when they add programmer-to-go you can really throw your PK3 away
then JTAG/AVR will be just icing on the cake.

they should really focus on part support.. ICD4 is also severly lacking.. what i find strange is that they apparently use the same platform but there is slightly better part support on ICD4