-
Maybe because I am in the US. Microchip direct ships to me from their Thailand location. Maybe in the UK, you are covered by a different distribution center.Quote
I frequently use an ISP pin to transmit UART debug output ( using in programmer mode, not debugger, obviously) - no reason the programmer should be driving the pins when not active.
At any rate, even if there's not, this hardware fix will probably work fine, if/when you have the time. You just have to find a signal to trigger it off of. So the relays can close and connect the PK to the PGC/D pins when it needs them, and cut it out of circuit the rest of the time. For me, the only downside of closing those relays off the Vpp was that on the now obsolete baseline devices, the rewriting of corrupt OSCCAL didn't work. I just added two solder jumper pads to the outside of the case to permanently close the relays (and restore the programmer to stock configuration) if/when desired with a soldering iron. Not that the automatic recalibration was accurate enough to even bother with. But I did occasionally sit down a recalibrated a batch of chips with a calibration firmware and a frequency reading on a DMM. If you use the debugger, frequently, I suppose you need a different signal or to add an additional physical switch.
There might be a setting somewhere to control this
I got even fancier on the button thing, with my dev programmer. I made an intermediary pcb with in/out headers on it (straight pass through on the regular ICSP pins, and circuitry only on the new 7th button pin) with a USB mouse chip and a switch. So with the flip of a switch, the button on my ICSP pogo pin interface could act as left mouse button. This is so handy when you are debugging a product and you want to double check the firmware revision (assuming you can leave DATA EEPROM unlocked and give yourself a register or two for an firmware revision number). Hover the mouse pointer over the "read" icon in the software, and then you can read the device with your pogo interface without needing 3 hands or learning to use the mouse lefty. Universal, works with all programming software. If ever you needed to read/verify/erase or write with a pogo interface.
If it sounds like I spent a lot of time modifying PK's, yeah. My dev PK2 is permanently installed in my bench. It's that reliable. I think I only ever had to unplug/replug the USB plug once. My P2G PK's all have integrated Li ion battery, charger, 5V boost output, button mod with extra header pin. I'm not sure when I will have time to play with the PK4, but it will be upgraded, eventually. -
[I originally posted this on the Microchip forum without the pics]
One of these arrived this morning. Very early days, but here are my initial findings.
The biggest problem so far is that I am having some trouble with it enumerating, I've tried different USB ports and hubs but it seems random, on the same port sometimes it enumerates, sometimes it doesn't. The error isQuoteThe last USB device you connected to this computer malfunctioned and Windows does not recognise it.
Recommendation
Try reconnecting the device. If Windows still does not recognise it, your device may not be working properly.
OS is Windows 10 x64 on a dual Xeon E5-2696v2 24C48T monster with 64GB RAM, so plenty of horsepower.
When it works, there is a dramatic improvement when programming over the PICkit 3, on a blinky on a PIC32MX170F256B, the PICkit 3 takes 22s whereas the PICkit 4 takes 7s. ICD 3 took 11s, so the PICkit 4 seems faster in this example than an ICD 3.
When programming (as opposed to debugging), unlike other programmers, the PICkit 4 seems to assert reset or otherwise stops the processor from running after programming. You need to remove the programmer from the DUT to see it run.
Unlike the PICkit 3, you can set breakpoints while the processor is running, which I use a lot on the ICD 3 and RealICE.
MPLAB X frequently seems to deny the PICkit 4 is connected after it's already enumerated correctly and been used. I'm not yet sure of the sequence of events that makes this happen, but restarting MPLAB X sometimes fixes it. Sometimes you have to change USB ports for it to show up in MPLAB X.
A welcome new feature of the PICkit 4 seems to be that it stores debugger firmware for several devices so it doesn't need to update every time you change devices. I don't know how many devices it will remember. I was swapping between a PIC24F08KA101 and PIC32MX170F256B.
In short it's promising, but as is so often the case nowadays with Microchip, the quality of the software and associated in house testing leaves an awful lot to be desired, leaving the rest of us to do that for them.
-
A welcome new feature of the PICkit 4 seems to be that it stores debugger firmware for several devices so it doesn't need to update every time you change devices. I don't know how many devices it will remember. I was swapping between a PIC24F08KA101 and PIC32MX170F256B.
I'd sincerely hope it now has just one FW image that covers all devices, and only needs updating when something new comes along or bugfixes.
I only had a quick look but haven't yet seen anything about the SD card functionality - will be interesting to compare the standalone programming speed, as this is something I use PK3 for a lot. I worry that the overhead for the SD protocol might actually make it slower, especially for smaller parts.
The fact that the product page links to the SQTP spec suggests it may now support serialisation in standalone mode, which would be nice. -
It may well be the case that there’s no target-specific firmware at all stored on the programmer, or at least all the necessary algorithms are stored on the programmer ahead of time in a single image. I don’t remember seeing it going through the AP and RS etc programming stages that you get on the ICD 3 and PICkit 3.
I didn’t try any programmer to go functionality, it’s not something I use, so I didn’t feel I’d be able to do it justice, having no experience of using the finctionality in anger.
If the standalone programming speed is as fast as I’m seeing when PC attached, then I may well start to use that functionality. At present, any bulk production programming I have to is in an emergency, and is through the old IDE which is much faster than MPLAB X. -
When it works, there is a dramatic improvement when programming over the PICkit 3, on a blinky on a PIC32MX170F256B, the PICkit 3 takes 22s whereas the PICkit 4 takes 7s. ICD 3 took 11s, so the PICkit 4 seems faster in this example than an ICD 3.
And what is the size of that blinky example? To put programming rate in KByte/sec. -
If the standalone programming speed is as fast as I’m seeing when PC attached, then I may well start to use that functionality. At present, any bulk production programming I have to is in an emergency, and is through the old IDE which is much faster than MPLAB X.
programming-to-go IS blazing fast on pickit 3.
I use it when i have many boards that don't have a header, but it has contact pads instead: i press the button, programming done in a couple of seconds at most.
I'm sure that most of the lag come from the communication between programmer and software, because there is none when the PK3 is in PtG: blue led steady when last programming was successful, blinking if not successful. green and red led change states when the target is detected. If they'll add SQTP in PtG mode the PicKit4 it will make me very happy -
programming-to-go IS blazing fast on pickit 3.
I use it when i have many boards that don't have a header, but it has contact pads instead: i press the button, programming done in a couple of seconds at most.
I'm sure that most of the lag come from the communication between programmer and software, because there is none when the PK3 is in PtG: blue led steady when last programming was successful, blinking if not successful. green and red led change states when the target is detected. If they'll add SQTP in PtG mode the PicKit4 it will make me very happy
Because they don't know how to do it right. I am the author of flasher (not for PIC) that has no any latency related to PC (USB) -> target device data transfer, and it is faster than other (similar) tools that are replicating downloaded code (firmware stored in master device RAM, no PC connection).
Again, what is blazing fast programming rate (in KByte/sec)? -
I would be interested what the programming time would be if you leave the connection to the tool open. I also agree that connection setup overhead in Microchip devices is excessive.
In cases of my ARM toolchain flow, I've an openocd server constantly running that already has probed the target board for power, chip ID and memory setup. It can go straight to downloading code and running the executable whenever I do so. I think MPLABX has a similar option in their embedded section, that allows you to leave tool connection active outside programming/debug sessions.
Thereby I would suspect that if you want to measure kB/s for a small blinky program, you will probably get very low numbers. Better get some kind of large binary (e.g. 64 or 128kB) and time how long it takes extra. -
programming-to-go IS blazing fast on pickit 3.
I use it when i have many boards that don't have a header, but it has contact pads instead: i press the button, programming done in a couple of seconds at most.
I'm sure that most of the lag come from the communication between programmer and software, because there is none when the PK3 is in PtG: blue led steady when last programming was successful, blinking if not successful. green and red led change states when the target is detected. If they'll add SQTP in PtG mode the PicKit4 it will make me very happy
Because they don't know how to do it right. I am the author of flasher (not for PIC) that has no any latency related to PC (USB) -> target device data transfer, and it is faster than other (similar) tools that are replicating downloaded code (firmware stored in master device RAM, no PC connection).
Again, what is blazing fast programming rate (in KByte/sec)?
I haven't measured it tbh but it goes from 5-10 seconds to just after the button is pressed. Fast enough for me, i use programmer-to-go in PIC16LF1823 based boards, just a couple of kilobytes to transfer -
I would be interested what the programming time would be if you leave the connection to the tool open.
If this question is related to me (and my flasher), than there will not be any difference, because there is no latency (of any kind) during sending data over USB (CDC, unlimited size buffer, complete firmware is sent at once). Programming time will be identical.Thereby I would suspect that if you want to measure kB/s for a small blinky program, you will probably get very low numbers. Better get some kind of large binary (e.g. 64 or 128kB) and time how long it takes extra.
I hope that this blinky using full flash memory, because I can't imagine that today (2018) some brand new tool need 7 seconds for downloading 1 KByte program. And that is reported as miracle. -
I haven't measured it tbh but it goes from 5-10 seconds to just after the button is pressed. Fast enough for me, i use programmer-to-go in PIC16LF1823 based boards, just a couple of kilobytes to transfer
This is too slow for me, but I am not familiar with PIC and it's flash memory characteristics.
For example, 20 years old MSP430F2xx devices are with flash memory that is limited to 50 KByte/sec writing rate. -
If you're ordering from microchipdirect.com, the code EW2018DT should give you 25% off.
Thank you. I just ordered a pickit4 and the code worked perfectly
I contacted Microchip to know when a specific dsPIC33 will be supported and they replied "Support for these parts should be in the April release of MPLAB X v4.20". This might also fix the connection problem ... -
It is somewhat dependent on the part and the code size - I've seen from 2 to about 20 secs
programming-to-go IS blazing fast on pickit 3.
I use it when i have many boards that don't have a header, but it has contact pads instead: i press the button, programming done in a couple of seconds at most.
-
If you're ordering from microchipdirect.com, the code EW2018DT should give you 25% off.
Thank you. I just ordered a pickit4 and the code worked perfectly
I contacted Microchip to know when a specific dsPIC33 will be supported and they replied "Support for these parts should be in the April release of MPLAB X v4.20". This might also fix the connection problem ...
I noticed most, if not all, of the dsPIC33Ex and PIC24Ex series aren't yet supported in the MPLAB X 4.15 release notes. In addition among others, some of the early PIC32MX aren't yet supported.
On Wondows installs, the default file location to check is: C:\Program Files (x86)\Microchip\MPLABX\v4.15\docs\Device Support.htm -
Quote
This is too slow for me, but I am not familiar with PIC and it's flash memory characteristics.
For example, 20 years old MSP430F2xx devices are with flash memory that is limited to 50 KByte/sec writing rate.
I wonder why such a huge difference? Maybe due to PIC internal charge pump circuitry? If I understand correctly, many of the modern micros are flashing themselves, in a way, rather than relying on the external programmer to get the voltage correct and potentially suffering voltage drop issues.
The flash speed certainly depends on the parts. In the 8 bit pics I use, the PK3 flashes almost exactly the same speed as PK2 in almost all cases and is essentially the same speed whether through USB or P2G. Roughly 3 to 3.5 seconds per KB. ICD3 is maybe 20-30% faster but much less convenient for batch flashing.
-
Roughly 3 to 3.5 seconds per KB. ICD3 is maybe 20-30% faster but much less convenient for batch flashing.
There are lots of different PIC16/18, older are slower, newer ones are generally faster, but 3 sec/KB is certainly way too slow and the reason for this it is certainly bad PICkit3 design. -
I see about 3K/sec for a pic32mm curiosity board (PKOB=PK3). When using the command line tools to program, it takes about 10 seconds for the programming software to get to the point of actually programming the chip.
I would rather see them take the cheapest pic32 w/hs usb, <5x5cm size, simple design, cut the parts count down, open source the hardware/software and let the best ideas float to the top. Sell them like candy, toss them out at parades, put them in vending machines. They could bundle this pk-mini with all future curiosity boards also (I don't see them slapping a $15 retail sam micro on future curiosity boards).
question- since the PK4 will have JTAG(?), will this enable the use of JTAG debugging on something like the pic32mm which has that capability? I read about the J-link Base which can debug a pic32 (not mm) without using a debug executive. Or is this just their dream- add a few pins for the capability, but the software guys will need another 5 years to get to it (after they get the basic features to work right).
-
Yeah, my mistake. Misremembered. Looking at the code I was using, I have almost 4x the size I thought I did. I'm seeing a little over 1KB per second on an enhanced midrange.
I don't remember having major difference with the basic 8 bit, though. Except with the PK2, it wants to write the entire program memory with 0's, because osccal is in the last register. PK3 was programmed to not be retarded on these PICs. Not that anyone uses these, anymore. -
I wonder why such a huge difference? Maybe due to PIC internal charge pump circuitry? If I understand correctly, many of the modern micros are flashing themselves, in a way, rather than relying on the external programmer to get the voltage correct and potentially suffering voltage drop issues.
Many micros can be flashed by themselves, and (most of the) PIC's too. And external programmers use the same principle. They download small part of flashing code to target device, and than execute it from there. Taking care to supply that executing program on target device with flashing data on time. And if this program on target device always have data on time (not waiting for them, and USB with 1 MByte/sec from PC side can provide this) then there should not be any (or some with minimum impact) latency.
I found this...
http://www.microchip.com/forums/m881530.aspxQuoteReason is very simple : Pickit2 uses internally a PIC18. Pickit3 uses internally a PIC24.
Both these PICs uses USB Full Speed (12Mbits/s)
ICD3 and Real-Ice have an internal FPGA which has USB High Speed (480Mbits/s)
If you use ICD3 or Real-Ice, you can program PICs up to 512KB in less than 15s ;=)
If you program a 512KB PIC32 with Pickit3, it will last about 3mn30.
Where is clear that they (Microchip) don't know how to do it. And they need a huge amount of horse power to compensate this. Or flash module on their devices is designed on bad way, and only huge amount of horse power can handle this. Again, their falut.
BTW, don't know how to comment this (from MPLAB ICD 3 features) at all...QuoteHigh Speed Programming - Fast programming allows both quick firmware reload for fast debugging and for in-circuit re-programming. Programming times are improved up to 15x over MPLAB ICD 2.
That older version of the same product was so bad, that the new one is 15x faster, and they are proud because of this.
Just want to add something to linked topic related to PIC flash writing speed and USB...
There is nothing wrong with USB, and CDC. USB is made for large transfer (at once) and in micro world (Full speed) up to 1 MByte/sec working just fine. It is not made for frequent transfer of small data chunks (few bytes). I can find on plenty of places where (slower) HID is preferred over "problematic" CDC. Maybe it is only me, but I didn't found any problems ever with CDC, that have native OS support, and today it is also on Win 10 plug and play (without driver installation request). -
i was going to get one, but after looking at the site i changed my mind.
marketing bastards have decided it wont work with AVR parts even though it's now a microchip range and the programmer could handle it.
they still want you to buy a seperate programmer!
hell, even pickit2 could do AVR unofficially - and pickit3 probably could with a little work.
-
Yeah, my mistake. Misremembered. Looking at the code I was using, I have almost 4x the size I thought I did. I'm seeing a little over 1KB per second on an enhanced midrange.
I don't remember having major difference with the basic 8 bit, though. Except with the PK2, it wants to write the entire program memory with 0's, because osccal is in the last register. PK3 was programmed to not be retarded on these PICs. Not that anyone uses these, anymore.
Sure. Like the old PIC18F6723 can be fully programmed in 4.5 seconds while a newer PIC18F67K22 can be programmed in 3.3 seconds. They're both 128K memory (which BTW means that full speed USB has way more than enough bandwidth). Even with PICkit3, it is not as slow as you described. I timed these with PIC3CMD and it was 50 and 34 sec respectively - close to 3KB/s. -
Yesterday I found that like the ICD4, the PICkit 4 won't anywhere near reliably debug devices like the PIC32MZ series when running at higher clock speeds. It consistently breaks after only three or four single steps.
This and a few other anomalies suggest that they've leveraged the ICD4 ancestry and ported it to this new device, which is a reasonable thing to do. Or it would be, if only it worked in the first place! -
Quote
Where is clear that they (Microchip) don't know how to do it. And they need a huge amount of horse power to compensate this.
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. -
Quote
Where is clear that they (Microchip) don't know how to do it. And they need a huge amount of horse power to compensate this.
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.
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. -
Quote
Double? You can do much better
I was referring to MCHP, so I set the bar low with 'double' (and I also said without much effort).Quote1.5 sec is too optimistic
I was giving the minimum times for each potential bottleneck to show its not the chip or lack of HS usb. I always assumed moving to HS usb would make a big difference, but it appears that is not the problem. The speed gains of the PK4 are probably due to the fact that it can't get any slower than the PK3, and ANY rewrite of code would bring more speed.