What Microchip hides from Dave after his Pickit3 video, yes new Pickit4 :)

[Howardlong]

Don’t forget they’ll be earing through 58 layers of abstraction, including JNI, to target the hardware.

You can see where the delays are to some degree when you hit the program or debug buttons.

If you compare it with the performance of the old MPLAB non-X, you wonder what “progress” is in the minds of some engineers.

[NorthGuy]

If you compare it with the performance of the old MPLAB non-X, you wonder what “progress” is in the minds of some engineers.

I wonder wouldn't it be easier for them to port pre-X MPLAB to Linux/Mac (if that's was the goal)? But I think they honestly believe MPLAB X is faster and better. Parallel reality.

With all these acquisitions, I now wonder if they're inclined to continue with PICs at all. I think they like AVRs better, so MPLAB is moving to AVR world and PICs are slowly retiring while donating their peripheral organs to new AVRs. Looks like a very possible scenario.

[josip]

An example-
a 256k pic32mm has a chip erase time of 20ms,  a row write time of ~1.5ms which means 1024rows * 1.5ms + 20ms = ~1.5s to program the whole chip (these are self program numbers)
usb hid fs can do 64bytes x 1000 for irq transfers = 64000bytes/s (although I think one can use control transfers/reports to crank that up significantly)

so, the chip can do 256k in 1.5s, usb fs hid can transfer 256k in ~4sec, but it takes about ~80 seconds to program the 256k from the pickit3/pkob- I know there are a number of little gears between the input and output of this transmission system, but it does seem like the clutch (software) has some major slippage.

They could probably double the speed (or more) with not much effort, it would seem to me.

Similar example:

MSP430G2955 is new device, but it belongs to 20 years old 2xx flash family. It has the same flash module as 20 years old 2xx devices, and I am using it for example only because of largest memory in 2xx family (and due to largest memory it will give best performance numbers for my flasher).

You can calculate maximum flash writing rate using datasheet numbers for block write (at 476kHz, that is max flash frequency), and it is (if I remember right) little over 50 KByte/sec (these are self program numbers). My flasher using little lower flash frequency of 461.5 kHz for target device flash, and by datasheet calculation for 128 bytes in flash clock cycles is...

25 (1st word, block start) + 63 * 18 (63 words) + 6 (block termination) =  1165

and with 461.5 kHz flash frequency, flash writing rate will be 49.5 KByte/sec (these are self program numbers).

Benchmark (write command) for my flasher with this target device connected, on Win / Linux / OS X, will show 48.3 KByte/sec. In this rate (time) is included elapsed time from the moment before PC send write command (with all data) to flasher and after PC receive information from flasher that job is done. For communication between PC and flasher is used CDC (OS drivers) that doesn't need any extra installation, plug and play.

Double? You can do much better. 1.5 sec is too optimistic, you need to transfer data to the chip, then spend some time on verification. But about 5-6 sec sounds about right. And you don't need FPGAs, fancy 32-bit MCUs to achieve this speed. You can get pretty good speed with a little programmer made of little PIC16.

And my flasher is based on 10 years old 24 MHz MSP430 device. Most important thing is to have all things running in parallel without any latency, but this must be hard coded in assembler, and there is nobody crazy enough (except me) today, to lose time on this. C++ with 5 abstraction layers is mostly used today (as I can see in TI FET's open sources), and in combination with people that don't know how to do it, result is as it is.

[Howardlong]

I've been attempting to use this device on a PIC16F1509 over the past couple of days.

First off, the PICkit 4 (and ICD 4) doesn't recognise the device's debug header, so I have had to switch around some pins on the DUT board to free up the debug pins.

Second, and it's early days, I found a "Hardware tool emergency boot firmware recovery" option in the Debug menu of MPLAB X 4.15. Nothing ventured, nothing gained. After a bit of fannying around, I reset the firmware on both the ICD 4 and PICkit 4, and, touch wood, since then the devices have behaved themselves, and enumerated. (I tried the PICkit 4 on two other PCs and experienced the same enumeration problems I'd been having on my main PC over a number of different USB ports and hubs). When in its recovery mode, it shows up as a COM port by the way.

If you unplug and immediately plug in the PICkit 4 into the USB cable, it doesn't enumerate, "USB device not recognised". If you switch ports, magically it does usually enumerate at that point, but MPLAB X won't recognise it. I've tried all sorts of combinations but regrettably other than trying another day, I'm buggered if I can get it to enumerate again, and be recognised by MPLAB X.

As well as being able to break you code at a specific point while it's running, the PICkit 4 also supports software breakpoints, great for those MCUs with single breakpoint capabilities.

On the PIC16F1509, programming is just as slow as other debuggers, so no real advantage there as I've seen with some other devices in the PIC24 and PIC32MZ series.

God knows why I bother with this shit, just like the ICD 4, it's an unfinished steaming pile of turd. The ICD 4 has had a few months to settle down but it's still useless for my purposes. I'd imagine the same problems will drag on for ever with PICkit 4 too.

[Howardlong]

It looks like the only way I can get the PICkit 4 to re-enumerate after removing it (or MPLAB X stops recognising it) is if I use the Hardware Boot Emergency Boot Firmware Recovery in the Debug menu of MPLAB X 4.15.

It show itself as a COM port first on VID/PID 04D8/9012, and the new firmware is installed, then it shows itself as 04D8/9017. In MPLAB X, new firmware is installed and it then shows itself as 04D8/9012 again, but as a Micorchip WinUSB device. I can then use it, until either I remove it or MPLAB X stops working with it again, whereupon I have to start again.

I also notice that it draws quite a bit of back current if you leave it connected to the DUT but unplug the USB cable (150 to 350mA).

Not sure if anyone else is having similar problems, or maybe I just have a crap example.

[mikeselectricstuff]

I also notice that it draws quite a bit of back current if you leave it connected to the DUT but unplug the USB cable (150 to 350A).

I assume you mean mA..?

On a quick test, I noticed it doesn't seem to tri-state its outputs after programming. ISTR ICD4 had an option for this so maybe there's an option I've not found yet

[Howardlong]

I also notice that it draws quite a bit of back current if you leave it connected to the DUT but unplug the USB cable (150 to 350A).

I assume you mean mA..?

On a quick test, I noticed it doesn't seem to tri-state its outputs after programming. ISTR ICD4 had an option for this so maybe there's an option I've not found yet

Yes, mA!

Do you have any problems in it re-enumerating after unplugging it from the USB after a programming or debug session?

Edit: I should add that typical quiescent current through the USB port is from 60mA to 160mA.

[mikeselectricstuff]

I also notice that it draws quite a bit of back current if you leave it connected to the DUT but unplug the USB cable (150 to 350A).

I assume you mean mA..?

On a quick test, I noticed it doesn't seem to tri-state its outputs after programming. ISTR ICD4 had an option for this so maybe there's an option I've not found yet

Yes, mA!

Do you have any problems in it re-enumerating after unplugging it from the USB after a programming or debug session?

Edit: I should add that typical quiescent current through the USB port is from 60mA to 160mA.

I've not used it in anger yet - too busy with real work to play with new tools.

[VEGETA]

I wonder if it allows programming AVR chips too. I hope it is supported in Arduino IDE so we could have one programmer to rule them all.

[stj]

no AVR support.

[Howardlong]

I also notice that it draws quite a bit of back current if you leave it connected to the DUT but unplug the USB cable (150 to 350A).

I assume you mean mA..?

On a quick test, I noticed it doesn't seem to tri-state its outputs after programming. ISTR ICD4 had an option for this so maybe there's an option I've not found yet

Yes, mA!

Do you have any problems in it re-enumerating after unplugging it from the USB after a programming or debug session?

Edit: I should add that typical quiescent current through the USB port is from 60mA to 160mA.

I've not used it in anger yet - too busy with real work to play with new tools.

Good job, it's an extensive rabbit hole all of its own that's for sure.

[VEGETA]

no AVR support.

Then why they bother doing a v4 of it?

Pickit3 was good enough on its own, so why pickit4? what will I gain from 4 that it is not in 3?

I really hoped to have one that does both while being from original manufacturer not some Chinese company.

Perhaps we should ask: Is it really possible to have one programmer for both AVR and PIC?

[mikeselectricstuff]

no AVR support.

Then why they bother doing a v4 of it?

Pickit3 was good enough on its own, so why pickit4? what will I gain from 4 that it is not in 3?

I really hoped to have one that does both while being from original manufacturer not some Chinese company.

Perhaps we should ask: Is it really possible to have one programmer for both AVR and PIC?

I have little doubt that AVR support will be addded at some point, as well as JTAG.
The main potential improvements are speed, not having to download new FW when changing device families, and the SD card for programmer-to-go mode. It also looks like there may be more protection on the ports.
I often use PTG mode for production - I send a preprogrammed PicKit 3 along with the test jig to the assembly house - if I need to update the FW  I need to either send another programmer or walk them through the non-trivial procedure to update ( which can be complicated by the fact that this process is flaky if you don't have target power at the time).
With the new one (in principle, assuming it works), I can just send them a file to stick on the SD card.

[Fire Doger]

Then why they bother doing a v4 of it?

Pickit3 was good enough on its own, so why pickit4? what will I gain from 4 that it is not in 3?

Speed

I really hoped to have one that does both while being from original manufacturer not some Chinese company.

Everyone could program their avr when ATMEL was separate manufacturer, why to bother to make all in one? As you saw pk4 and icd4 have issues, imagine if they had included avr and arm too....

Perhaps we should ask: Is it really possible to have one programmer for both AVR and PIC?

Everything is possible, the  question is if there is enough market for it to make higher profit by selling all in 1 solution.

[Howardlong]

I realise we all have our own way of debugging, and many will only be interested in its programming features. My use case includes programming, but most of the time I use them as part of my debugging workflow. Yes, I also add plenty of real time telemetry too while debugging, but I also use the debugging features a great deal too.

Its main features from a debugging perspective over the PICkit 3 are speed of programming (especially for larger devices), software breakpoints, and the ability to place arbitrary breakpoints while the DUT is running. (Note that I have seen little if any speed improvement in some PIC16 devices, but I certainly have with PIC24 and PIC32).

The software breakpoint thing is especially useful for devices which only have a limited hardware breakpoint capabilities: some lower end devices only have a single hardware breakpoint for example.

[SiliconWizard]

If you compare it with the performance of the old MPLAB non-X, you wonder what “progress” is in the minds of some engineers.

I suspect this may not be any engineer's decision.

A big factor, unfortunately, which pushes a lot of companies to switch to Java solutions, apart from the hype factor (which is starting to vanish actually) is the difficulty to hire young software engineers who can develop in anything else than Java. It's the number one factor IMO for managers.

[mikeselectricstuff]

According to the Microchip forum

We are hoping to have PICkit 4 OTG supported by the Aug release of MPLAB X.

***ing AUGUST ? 

Obviously someone has decided designer-case wankery is more important than usefulness. Idiots.

[Warhawk]

those of us working in semi business know that the perspective has already changed and marketing is more than any engineering. Welcome to engineering in the 21st century.
The worst thing is that it works. When you see the profile of a typical college graduate, his/her skills and knowledge of electronics, you will find out why.

[KL27x]

if I need to update the FW  I need to either send another programmer or walk them through the non-trivial procedure to update ( which can be complicated by the fact that this process is flaky if you don't have target power at the time).
With the new one (in principle, assuming it works), I can just send them a file to stick on the SD card.

With the PK2, I removed the EEPROM chips and wired them to a 5 pin female pin header. I just made up a few dozen EEPROM boards with male header that plug into the socket. This works great on PK2, because all of the P2G data is on the EEPROM, including target power, device, MCLR, etc. The only thing that is not stored on the EEPROMS, AFAIK, is whether the PK2 should boot up to P2G mode or not. Once set for P2G, the EEPROM board is all I need to swap or send. (I figured this out by trial). I never got around to trying this on PK3, so I don't know what problems could arise.

AFAIK, the PM3 can do what you want, right now. But of course if costs a heck of a lot more than a PK3. If you have a long-term partner, this might be worth consideration.

the non-trivial procedure to update

It's nontrivial, even for me, and I do it many times a month, on average. PK2 is so much faster and far less click-maze routine. Unfortunately, it looks like Microchip is patting themselves on the back for the PK3 and might be hellbent to make even more "improvements," rather than undoing some of the ones they already made. When I read the PK4 continues the tradition of using their own USB driver, I figured it would just be the next evolution of making bugs and pissing people off. The enumeration problems that Howardlong has described are pretty much how PK3 always acted for me.

I guess you have some projects where you don't do the whole bootloader flashed by the factory, and panels of devices updated via mousebite, thing?

I have a simple device for quickly flashing bare chips. Fast and easy enough that I use ICSP pads/interface only as emergency backup. Still wondering if there's any need for this invention in the modern world. Customs can hit you sending micros back and forth to China, of course, but I do a lot of my own PCB assembly.

[nomadd]

***ing AUGUST ? 

***ing MPLAB-X? 

[NorthGuy]

Obviously someone has decided designer-case wankery is more important than usefulness. Idiots.

Not at all. Appearance is everything. Nice case will bring you more sales than good functionality. When you look at the mice case, it awakens desires within you and you buy. Once you discover the functionality flaws, you just learn to live with them. Without a nice case, you wouldn't buy and would never know anything about functionality.

[cv007]

Appearance is everything

That may be true for consumer items to a degree, but I don't think it applies in this case. You are not buying PicKitX because of its looks, its because you have and want to program a pic and there is no other option from the manufacturer of that chip. Its not like shopping for a computer accessory where there are dozens of choices. What they produce is what we get. They could make them in awkward round cases, and people would still buy them

[NorthGuy]

Appearance is everything

That may be true for consumer items to a degree, but I don't think it applies in this case. You are not buying PicKitX because of its looks, its because you have and want to program a pic and there is no other option from the manufacturer of that chip. Its not like shopping for a computer accessory where there are dozens of choices. What they produce is what we get. They could make them in awkward round cases, and people would still buy them

This is a very narrow view of appearance. Appearance is everything which is not related to actual usability. For some it is a metal box, for you it is Microchip logo (although I can imagine people abandoning Microchip because the sky over STM32 seems brighter to them), for Mike it may be FPGA and powerful ARM32 inside. Regardless of what it is, marketers manipulate appearance, test responses and move in the direction where the profit is maximized. When you buy it, you endorse the whole complex of appearances, so what you buy is likely to continue and what you don't buy is likely to be eliminated. This process has nothing to do with engineering. If it was, you would never see PICkit3 replacing PICkit2 (which had better design), or MPLAB X replacing MPLAB 8.

[Howardlong]

One of the machines I was trying PICkit 4 on, without much luck, was a Mac but running Windows 10 natively (all my tests thus far have been on Windows 10 x64 machines).

I tried it last night in OS X, and in the limited testing I did it did seem to work, it was a far cleaner test.

[JPortici]

***ing AUGUST ? 

in the meantime i hope they will focus on adding parts support. ALL the PICs I use are still not supported or beta supported. (both on ICD4 and PK4)