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.
There might be a setting somewhere to control this
The 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.
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.
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.
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.
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 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
If you're ordering from microchipdirect.com, the code EW2018DT should give you 25% off.
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 ...
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.
Roughly 3 to 3.5 seconds per KB. ICD3 is maybe 20-30% faster but much less convenient for batch flashing.
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.
Reason 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.
High 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.
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.
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.
QuoteWhere 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