PICkit 3 - vs - PICkit 2 Has the PICkit 3 improved in the last 5 years?

[ez24]

Has the PICkit 3 improved since Mr. Dick Head was fired 5 years ago?  Or was that just a publicity stunt ?  (sorry I lost link to that video)

Or should I try to find a real 2 on eBay?

I am trying to figure out what these can do and I think I should study the one that works the best for a beginner.  I want to put the PICs on breadboards and use USB with Windows similar to this

http://www.auelectronics.com/Q8.htm

thanks

[MarkF]

I have the PICkit 2 and I have no complaints.  However, its device list is very limited.  I would recommend you go with a real PICkit 3 and not have to worry if a device is supported or if a problem is caused by the programmer or your code.

[Kalvin]

You can get both from Ebay at the cost of genuine Microchip Pickit3. I have few genuine Pickit3s at the office and the Chinese versions 2&3 at home. I haven't encountered any problems yet. The Pickit 2 will not support the latest devices, so you may want to look at Pickit 3. Check the supported devices list before you buy something.

[Karel]

We have a pickit3 but we don't use it anymore. It works fine but it's so slooooow.... (because we use mainly 32-bit mcu's)
Switched to an ICD3, saved us a lot of time.

[macboy]

PK2 users had gripes about the PK3 when it first came out. But now, the PK2 has been out of support for several years so the PK3 definitely the go-to.

The Pickit 2 had some nice features to potentially help you debug your system... a basic logic analyzer, a serial (UART) tool, etc. The Pickit 3 dropped those and focused on being a programmer and in-circuit debugger. PK3 works well at those functions. If you need a basic logic analyzer, you can get a little box based on a CY7C68013 for less than $6, and use a free software package like Sigrok. You can use a device like Buspirate (open source H/W) to provide an PC interface to UART, I2C, SPI, and almost any other serial protocol. Those two devices are far more capable than the PK2 in those respective functions. The PK3 is far more capable than the PK2 as a programmer and debugger. PK3 supports almost every serially-programmed device from low voltage ones to 5 V ones. The PK2 bottoms out at 3.3 V devices (IIRC), and doesn't support most new devices in the last several years. PK2 also seems to be far more limited in debugging support.  PK3 can debug essentially anything it can program (as long as there are enough pins to connect it in-circuit, >18 pin devices usually). The combination of PK3+CY7C68013+BusPirate is infinitely more capable than a PK2 and you can use all three simultaneously.

Of course, PK3 has limitations. Notably, you need to tell it what family the device is (so it can upload the repsective firmware) before it can even detect the device. Changing firmware when changing device family is a PITA, but given the ultra-broad device support, it is understandable.

[Ian.M]

PICkit3 Programmer Application and Scripting Tool v3.10      6/12/2013
http://ww1.microchip.com/downloads/en/DeviceDoc/PICkit3%20Programmer%20Application%20v3.10.zip

CAUTION: this tool installs PICkit 2 emulation firmware with all that implies i.e limited device support.  The bundled PICkit 2 device file has one more device than the last official release that was on the PICkit 2 page (v1.32.14).  You may wish to consider unofficial updates from the Microchip forums.  You MUST either run the menu item in the scripting tool to revert to PICkit 3 firmware, or hold the button down while plugging in the USB to force bootloader mode, before you can use the PICkit 3 again with MPLAB 8 or X or the IPE.   This utility does NOT require MPLAB 8 or X to be installed.

It doesn't have the serial (UART) terminal, but nearly all the other PICkit 2 features are supported.

[KL27x]

I have the PICkit 2 and I have no complaints.  However, its device list is very limited.

A bit of an exaggeration. The list is quite comprehensive. You have to install the latest device file.

PK3 still has a few features that are buggy or just missing. Controls that don't do anything. But if you use MPLAB, it is the better dev tool, because it is slightly faster at flashing and has MPLAB support/integration.

PK2 is a more reliable batch programmer, IMO (albeit slower for most devices). It has better drive on the ICSP pins. It can handle a lot more inductance/capacitance on those lines. It has proven to be 100% reliable for me. When it says the chip is successfully verified, this is the case. My personal experience with PK3 is not the same... I think maybe the PK3 is intended to sell more PM3's.

Programmer-to-go is a very handy feature on the PK programmers. But it has been nothing but buggy for me, on the PK3. This may be out of the norm. But I've tried 3 different ones, and they all have some of the same problems, which might have to do with my ICSP interface or board layouts.

I have PK2's, 3's, and ICD3. I use my PK2s the most, for two reasons.

1. Because I have one built into my workbench. I would do that with a PK3, but sometimes the thing screws up and needs a hard reset (same with my ICD3). And the PK2 can use a longer ICSP cable. And also if you plug in multiple PK3, it's hard to tell which one is which. PK2's can be renamed as you choose.

2. Because of the programmer-to-go.

Overall, the PK2 is a way cooler, fully realized, bug-free, reliable piece of hardware. Everything it's claimed to do, it does. Perfectly. PK3 is a little faster and has a few great tricks. I would have both. I highly doubt PK3 will ever reach the level of reliability of the PK2. Software or firmware. It's going to be in a constant state of debugging for its entire life until it is replaced. None of my support tickets resulted in any answers or ray of hope for current improvement/development.

[KL27x]

This thread got me curious to pull out the PK3 for a project I'm working on. Maybe I was being too harsh.

Again, for dev or debugging purposes, it will be a nice tool if you are using MPLAB IDE.

But say you have already developed the project on a dev/proto board and now you have your first assembled PCB. You have a hex file. To load and flash devices, "easily," you would use this piece of junk Java app called the IPE (Integrated Programming Software).

First off, you cannot even access IPE from the Start menu in Windows. You can open all your Microchip folders to find that IPE is simply not there. So if you erased the shortcut and the app is not one of your recently/frequenty used programs on your Start menu, you apparently have to reinstall it.

Then, after you click it, it takes my computer 30-60 seconds before the GUi opens. Absolutely nothing happens in the interim. No loading screen. No empty window. Just a lingering doubt. MPLAB IDE 8/9 opens in 5 seconds (and you can see it loading immediately). I don't know why the program that manages chip-flashing should require so much longer? Well, yeah, it's cross platform Java, and probably bloated. I suppose MPLAB X takes a long time to load, too. I haven't used that in a while, so I can't recall. And I don't feel like crashing my computer right now.

So, IPE 2.26 is finally running. Click on advanced settings. Do the log in/password deal. PK3 connected. Select device. Import hex. Then I click the various things to set the programmer up. Go to set up P2G. And it's greyed out. Yeah, no more P2G. I have no idea how that happened, as I have not updated the software since last time I used it. Perhaps I forgot how to do it... but that's another whole can of worms. The app takes a bit of human RAM to use.

I close IPE and open the PicKit3 standalone software v3.01. Or I try. Last I recall, you can't even setup P2G in this software, but I figure it's worth another look. Well, I'm still waiting on this program to open and nothing. I suppose I will have to restart my computer and try again.

No, I don't think everyone should buy a PK3 and "be done with it." There are still some users who will get more utility out of a PK2 and/or an ICD3. Debugging should be reserved for your project, not your programmer.

*Edit:
Ok, 20 minutes later, I finally reach for my PK2. I unplug the PK3..... and PK3 standalone software instantly opens. 
And when I try to close it, I get an unhandled exception error.  Of course, the task manager is the preferred method for closing a professional programming software.

[KL27x]

If PK3 doesn't give you any problems, then there's no reason for you to use it. YMMV.

To get the latest device list, you go to Microchip's website and dig around for the latest devicefile.dat. PK2 doesn't support all the latest and greatest 24/32 bit stuff. But I have never lacked for support for the 18F and lower devices, AFAIK. I'm using the latest and the greatest 8 bit 1.8V F1xxx nanowatt stuff, last I checked. Maybe I'm out of touch with newer devices.

I figured someone new to this might not want to be fucking around with their programer when they want to program a chip

This is my experience with PK3. It didn't even work out of the box until I upgraded some JAR files. And even then, it was a constant chore to use it (except within MPLAB, where it is awesome).

Maybe you can give me a refresher on how to use P2G? Why is my P2G bar greyed out?

[legacy]

PICKIT2 is EOL
end of story 

you'd better buy PICKIT3
trust me

[KL27x]

Anyone wants to buy a PK3, I have 2-3 new, unopened clones, and a couple used genuine and clones. 

[Ian.M]

@KL27x: What continent are you on (to see if shipping's worth it) and what's your asking price?

[KL27x]

Ok, I just took stock. My genuine PK3 are highly modified. Li ion pack, integral charging when plugged in, 5V DC converter on board, and a 7 pin port with the programming button ported to it. Also a couple of my clones have the same modifications.

So if you want a genuine, unmolested PK3, I can't deliver.

I have two brand new clones with the "W" on the front. Programmer only, no box. These, are in my very narrow experience, better than the genuine for P2G. Whereas the genuine PK3 hangs up every now and then and requires a hard reset, the W clones find their way back after this bad jump. This is seen as an occasional extra (and variable length) delay before returning to ready status, rather than a total lock up. (This is not due to my additional circuitry; this is verified to also occur with the unmodified units while plugged into the computer USB).

I also have 2 brand new lower case "pickit 3" clones. These are still in the box with an ICSP cable. But I can't promise these on a timely manner, because I just moved and have to get them out of storage. FWIW, these hang up more frequently than the genuine PK3 in P2G mode, at least for my specific purposes. I use one of these for dev, because for that, all these genuine and clone seem to work perfectly.

If you got a Paypal, live in the US, and you trust me, this can probably happen for w/e makes it worth your time/risk. PM me with an offer if you are interested.

I am not trying to badmouth PK3. I bought all these programmers with the hope of doing small scale batch programming with P2G. For my particular situation, I have failed to figure out how to do that with the reliability I need. Countless hours of testing, and now they sit around doing nothing. Even for dev programming, I have an ICD3, already. So my loss may be your gain.

[Ian.M]

I'm the other side of the pond so probably not worth it to ship.

Ok, I just took stock. My genuine PK3 are highly modified. Li ion pack, integral charging when plugged in, 5V DC converter on board, and a 7 pin port with the programming button ported to it. Also a couple of my clones have the same modifications.

Are your mods documented anywhere?

[KL27x]

Are your mods documented anywhere?

My mods are all DIY.

Quite similar to my mods to PK2... actually, I made my own custom PK2 from the schematic, with integrated DC boost/charging circuity. There's an additional microcontroller for low battery detection, various piezo buzzer alert noises and logic to convey actively flashing, pass/fail verification, reset/ready after fail, (reading the status LEDs to determine condition, so I don't have to). And a socketed EEPROM. (Once set for P2G, all relevant data, such as MCLR hold, voltage, device, etc is ALL stored on the EEPROM. So you can swap EEPROM to program different firmwares/devices). I still use PK2 for batch programming, whether by hand, with an arbor press, or even sometimes with a CNC machine with custom circuitry and firmware. And once setup, the PK2 is ready to P2G about 1 second after turning it on. I can download the firmware onto my desktop PK2 and take the EEPROM chip to my CNC or my arbor press.

My PK3 mod piggyback PCB has most of the same features. And an additional verification output for connection to a CNC. (My CNC custom circuitry does the verification logic, requiring the STATUS LEDS to be connected, but I figured it would be nice to have it on the programmer, instead, using just one output line). My PK3 PCB requires one trace to be cut on the PK3 so that it can charge while plugged in, and jumpers to the STATUS LEDs and programming button. Most of the firmware is completed, but I never quite finished it. Didn't fully implement low-current sleep. My PK2's hold charge for years, but right now my PK3's have to be disconnected from the battery in storage. Oh, yeah. I also gave (due to my PK3 issues) the circuit the ability to power cycle the PK3, either by pressing a button, manually, or through input from the CNC machine. But I never got to the point I trusted the PK3's own programming verification to actually use PK3 for production.

I was hoping to upgrade to PK3 for the speed. But I also found another great improvement on the PK3; it will flash a chip without verifying device ID. Sometimes, due to availability, I might buy different versions of the same chip. Different memory or LF vs F. If you make sure your configuration word is compatible with all versions, the PK3 will flash them all indiscriminately. The PK2 has to be setup for each device.

I've yet to use P2G so I can't help you there,you might try the MC forum.

This endeavor was last October. Been all over the forums and submitted tickets to no avail. It could be my programming setup just has too much capacitance. My programming cable is only 3 inches long, but my traces and ICSP pads are quite close together.

FWIW, my PK2 software includes 16F50X, but not the other two pics you mentioned. I haven't updated my devicefile.dat in maybe four years, but I suspect it hasn't been updated, since support was officially dropped aways back.

[ez24]

I've yet to use P2G so I can't help you there,you might try the MC forum.

The MC forum is for erotica ?  Is this what you mean?

http://www.mcforum.net/

[ez24]

Oh just in case you weren't joking.
MC stands for MicroChip.

thanks - I did not know

[MarkF]

Here is the last official PICkit2 device list from Microchip and the newest list updated by users that I could find:

[KL27x]

Haha, I can't stop thinking how great it would be if I could get the PK3 to work.

So I tried, and got it to work. Here's the breakdown.

Opening IPE on my Windows computer:
At 24 seconds, the window finally opens, first indication that you have.
At 45 seconds, the output window says "finished loading IPE software"

edit: after several software reboots AND multiple plugging in/out of the programmer, I could finally get IPE to detect the programmer. And after it detects, it needs to "connect."  This is 45 additional seconds to connect to the PK3, after you hit the "connect" button. And sometimes this fails, which takes 45 seconds to 60 seconds before the connect button lights up and can be tried, again. Note, this is NOT the download of new device firmware. I already have the appropriate device family firmware installed for the selected device.

So I might have had a failure to connect, before. I didn't wait for the connection message in the output window... I may have been "spoiled" by my PK2's that always connect in bout 1 second. Anyways, got a hex loaded in P2G mode. Took quite a long time to load into the device. 

I used my genuine PK3. Flashing 27 PCB's, I had to reboot the thing a bout 6 times due to hangs. And it takes about 6-7 seconds to reboot. It is definitely faster than the PK2, but not by orders of magnitude. Something like 20% or 30% faster in this particular case. When I read back the devices on the PK2, they all verified, which has not ALWAYS been the case. Had one failure, before, with the genuine PK3, despite the programmer giving the thumbs up. The "W" clone is actually faster than the PK2. The genuine, with the hangups/reboots is about a break-even, at best.

*edit:
I may have figured out how to connect it. But with the length of time, I'm not sure if it's 100%.
Let IPE finish loading, full 45 seconds, before plugging the PK3.
After the PK3 enumerates, go and do something else for approximately 50 seconds. This is when IPE detects the programmer. Now, hit connect and wait another 45 seconds. And after you unplug the programmer, even if you use the "disconnect" button, don't expect to reconnect it, or any other PK3, without first closing and restarting the whole process from the beginning. 

Win 7, 64 bit. 2.9Ghz i5 processor. Not that shabby. I'm pretty sure IPE hates Window 7, in particular. There are a lot of complaints with Win7 in particular.

Per my old notes, IPE is the only way I could get the PK3 to actually work in P2G mode. With an older firmware, I could do it in MPLAB 9, but it didn't work. With the latest firmware, it can only be done in IPE. If there's a way to do it in the standalone bugfest, I didn't figure it out.

[KL27x]

DevLst_1_61_0.pdf (149.87 kB - downloaded 1 times.)
* DevLst_1_63_149.pdf (123.46 kB - downloaded 4 times.)

BTW, this is definitely not the full list.

Download the latest devicefile.dat.

It includes a large number of more modern 8 bit parts.  10F322, 12F18XX and 16F1XXX enhanced 1.8V parts. That's just what I noticed at a glance. Definitely not ALL of them, as I have found out. But enough where I have yet to select the best 8 bit PIC for a job and been disappointed. If I ever do, I will probably look for alternatives that are supported.

[MarkF]

DevLst_1_61_0.pdf (149.87 kB - downloaded 1 times.)
* DevLst_1_63_149.pdf (123.46 kB - downloaded 4 times.)

BTW, this is definitely not the full list.

Download the latest devicefile.dat.

It includes a large number of more modern 8 bit parts.  10F322, 12F18XX and 16F1XXX enhanced 1.8V parts. That's just what I noticed at a glance. Definitely not ALL of them, as I have found out. But enough where I have never selected the best 8 bit PIC for a job and been disappointed.

Search again (DevLst_1_63_149.pdf -- top of page 4, right column).

[KL27x]

I stand corrected.

[0b01010011]

The only mod I have had to do my (genuine) PK3 is to bend back the female header and stick the thing back together with sticky tape (awaiting the next time I have the araldite out AND remember).  My nutty son literally ripped it sideways off a dev board it was plugged into.  The dev board needed new male headers but the PK3 survives!

I don't intend to start a micro/mini USB debate but the mini-usb connector on the PK3 seems a bit loose - maybe just the cable as I have only used the original red cable it came with.  Micro usb would have been a bit better then you could use any old cable you have laying around for phone charging etc, and also you could use it with phone chargers etc., in programming mode.

I have built a few custom ICSP cables for it - mainly that allow power injection to power hungry projects.

[Ian.M]

The last official PICkit 2 standalone device file release was v1.62.14.  When Microchip took the device list page down, I archived the list as a forum post: http://www.microchip.com/forums/FindPost/775368.  The device file bundled with the PICkit 3 Programmer App and Scripting Tool v3.10 is v1.62.15 and only adds one PIC.

A bit further down that topic, there's a link to Jeff Post's Dat2Text utility, which can be used to get the device list from any PICkit 2 format device file.  Its very useful when comparing unofficial device files.

[KL27x]

Update:

In fairness, IPE is loads much faster on my computer, now, after a reboot. The programmers are recognized within a few seconds, now, too. It's totally useable. There are some nice added features over the PK2, to boot. I suspect there may be some conflicts between IPE and MPLAB 9. I had MPLAB open, earlier. Since MPLAB 9 is officially unsupported, I guess that is technically on me.

The hang issue in P2G persists on my genuine PK3s. And the bad jump with recovery is still evident on my W clones. 

I only ever had the one false verification with a genuine PK3. And I am not sure, but I might have been using a programming interface that has the gate of a small signal FET on the VPP line (I know any additional capacitance on the Vpp line is a no-no, but I have used it with PK2 for at least 7 years without an issue, and I unwittingly used it with the PK3, at first, before quickly finding out this caused programming failures). So I guess I'll just keep my fingers crossed.

In hindsight, I don't know why this even works on the PK2. Most small signal FETs have a max gate voltage of 8V. I don't have a way of figuring out what kind of FET I used, other than it's an N FET, but it's still working all these years. All it does is switch an LED when VPP is hot, to give visual feedback while the device is being flashed. This predates my custom PK2 piezo buzzer mod.

So I guess my only completely validated (in my mind) complaint against PK3 is that P2G is buggy, for my current app, anyway, which is an enhanced 1.8V PIC with 4 pages of code. For some of the other devices I have used, I have not had the hang issue. I have successfully used PK3 in P2G mode for flashing baseline PICs (much much faster with a short code, because PK2 is "dumb" and flashes the entire program memory due to OSCCAL being stored in the last register of program memory) without freezing up the PK3 every 10 flashes.

I don't use MPLAB X. So I haven't tried using the driver switcher application, yet. Maybe you need to switch the PK3 drivers to MPLAB X for IPE to fully work, correctly? It's not clear to me where IPE stands in that whole mess.

[KL27x]

Been using PK3 for quite a bit, now.

Here's an update on some of my previous posts

IPE is still slow as molasses. It only works reasonably spiffy after a clean reboot of my computer it seems. I think once I have used MPLAB 8.x, once, the damage is done. So my original time estimates are pretty accurate on my Win7 comp.

Opening IPE on my Windows computer:
1. At 24 seconds, the window finally opens.
2. At 45 seconds, the output window says "finished loading IPE software"
3. After plugging in the PK3, it takes about 30 seconds before you can successfully connect.
4. It takes another 30 seconds or so to connect after you hit "connect." If you don't wait for step 3, connection will fail and will take like 45 seconds before you can try again. 
5. It takes another 30 seconds or so to setup p2go.

Between all the waiting, it takes me probably 5 to 10 minutes to set up a single PK3 for P2GO. It takes only ~20 seconds to do the same thing on a PK2.

Programming speed:
In a variety of different firmwares with the same device, PK3 is sometimes a bit faster, and sometimes a bit slower (than PK2 set for fast programming; changing speed of the PK3 doesn't seem to do anything). So really no speed advantage at this point for my current use.

Reliability:
Well, after flashing many hundreds of boards, reliability has been pretty good. There is stlll a rare board that cannot be flashed with the PK3. One board, it could flash, but it couldn't reflash? PK3 flashed the board once, then couldn't reflash it; just left it code unlocked. PK2 worked no problem; tried again with PK3, no dice. MCLR was on and N/C, and DAT/CLK lines unused (high impedance, pullups on in the code), so this is just strange. I notice the Vdd is supplied all the time, once you start using it. I suspect the power doesn't cut out long enough for the circuit to always respond to Vpp-first programming, maybe? (Even though I'm not using MCLR on this board).

Also, it seems like the delay between MCLR going to Vpp and data being sent may be shorter than on the PK2. This may be cause for some of the reliability issues I am having. PK2 is such a long delay, I can use Vpp to activate SSR's for DAT/CLK, so I can leave the programmer plugged in for dev and still use those lines in my circuit. My attempts to do the same on the PK3 have failed.

So aside from a couple of major pros in P2GO mode (namely the ability to ignore device ID), the PK3 has very little improvement for me aside from the debugger and the improved device compatibility. And even for dev use, I am often preferring my (modified) PK2 for devices where I'm using ICSP pins.

If anyone knows a more recent firmware suite, lemme know. I have 4 different versions, latest is 1.34.11. I can't even figure out how/where to get these firmware files, anymore. Seems like a year ago I found a few new ones and had to install these through MPLAB, manually. I seem to recall it being a bit of a scavenger hunt even trying to find those. IIRC, I got them from links from random posters, rather than from a Microchip website. All my current searches just come up with answers like "firmware downloads automatically," which seems to suggest that most people don't even know you can change firmware suites. (I'm not talking about the different firmwares between device families; these are *.JAR files which are installed via MPLAB, and the suite version remains consistent even when the device downloads different firmwares between device families).

Some of these four firmwares are less buggy then the others. (P2GO on the original PK3 is buggy in all of them).

[macboy]

Been using PK3 for quite a bit, now.

Here's an update on some of my previous posts

IPE is still slow as molasses. It only works reasonably spiffy after a clean reboot of my computer it seems. I think once I have used MPLAB 8.x, once, the damage is done. So my original time estimates are pretty accurate on my Win7 comp.

...

You didn't mention using the MPLAB Device Driver Switcher utility to switch between MPLAB X drivers (for IPE) and MPLAB 8 drivers.  Are you doing this? Maybe your problem is with incompatible or conflicting drivers.

http://microchip.wikidot.com/mplabx:switching-usb-drivers

[Ian.M]

Its not.  The PICkit 2 and 3 are HID devices with no Windows system drivers (other than the MS native HID driver), so don't  need switching.  Microchip's other programmers and debuggers (ICD 3, Real ICE etc.) however, are not HID devices, and have Windows drivers that require switching.

[KL27x]

I didn't actually know that. I looked for the switcher, which I know I have. And I can't find it. I figured it's got that great feature of IPE where if you delete the shortcut, you might have to reinstall it.  So I just gave up. 

I am not using MPLAB X for anything right now, and I'm only using IPE to set up PK3 for P2go, because apparently I have to. So it looks like I don't need to reinstall the switcher.

With two of my earlier PK3 firmware suites installed on the PK3, I can go through the motions of setting up P2go in MPLAB 8.x, but it doesn't work. In the later FW suites, it looks like they just got tired of debugging 8.x and gave up, removing P2G from 8.x, completely. (Although the PK3 appears to work fine in MPLAB 8.x in every other aspect of programming/debugging.)

[Karel]

The PICkit 2 and 3 are HID devices ...

This explains why the programming takes so much time. Using hid device for usb avoids the need to make a custom driver at the cost of speed.
The pickit is meant for hobbyists. Don't use it for batch programming or when your time is precious.

[KL27x]

I don't think there's anything wrong with the programming speed that is caused by the driver. The flash speed in IPE, on my computer, is atrocious, mind you. But the speed in P2GO mode wouldn't be limited by the driver, and I have no complaints about the speed there. And I get approximately the same speed when using PK3 in MPLAB 8.x. The "slowness" that affects my usage is mostly related to the software.

[Karel]

I don't think there's anything wrong with the programming speed that is caused by the driver. The flash speed in IPE, on my computer, is atrocious, mind you. But the speed in P2GO mode wouldn't be limited by the driver, and I have no complaints about the speed there. And I get approximately the same speed when using PK3 in MPLAB 8.x. The "slowness" that affects my usage is mostly related to the software.

We use mainly pic32's. The ICD3 programs them about 5 times faster.

In general, I have no complaints about mplabx or ipe. It works fine and starts up fast enough. Maybe it's because we use Linux.

[Sal Ammoniac]

If you can afford it, get the ICD3 rather than a PICkit3.

The PICkit3 is okay for programming a PIC, but it's way too slow to use as a debugger. I think I'd rather be waterboarded than to have to use a PICkit3 to debug anything.

[JTR]

This explains why the programming takes so much time. Using hid device for usb avoids the need to make a custom driver at the cost of speed.

No, it is the scripting engine that is the major bottleneck. True enough that a USB class with greater bandwidth will provide quicker times but the gain would be somewhat less than if microchip provided optimized, device specific firmware - even with a FULL SPEED HID interface.  The native PK3 firmware (I.E. not the PK2 port) is somewhat towards this and thus faster than the PK2 scripting method but I would not claim that even this is what I meant by "optimal." 

The exception to this are older PICs which are simply slow to program due to the word only writes and longer write times.