PICs for my PICKIT2

[bktemp]

dsPIC33FJ64GP802 is a great little chip: DIP28, 16kByte SRAM, lots of peripherals with pin multiplexers.
The DAC is a delta-sigma audio dac needing a constant data stream, but it is probably one of the worst audio dacs ever (only 61dB SNR).

[MarkF]

I've put together a list of PICkit 2 supported PICs with full data from the Microchip parametric search page.  See attached spreadsheet in Excel 97 format.
I've added a couple of extra columns:-

• 'MPLAB PK2 Support' - if its 'No' you need to use the standalone application with the unofficial 1.63.146 device file.
• 'PK2 Debug / Header' - If its 'Yes' you can debug the PIC directly, if a debug header is listed, you need it, unless it is marked * which are optional headers.
  

F.Y.I.   The unofficial device file that I posted earlier is version 1_63_148 for use with the standalone application.

[Ian.M]

Developing on parts you cant debug is a 'hair shirt' experience so I'd strongly recommend the O.P. restricts himself to parts with MPLAB PICkit 2 debug support, without an expen$ive mandatory debug header.   The standalone app part support list was included for completeness - if you want to seriously develop on the newer parts, for %DEITY%'s sake and your own sanity, invest in a PICkit 3!

However for those determined to proceed with the old-skool build-burn-crash development cycle, Device file 1.62.148 is probably fine as well, but the trouble with unofficial device files is "Who maintains the version number and functionally tests them?"  The 1.63.146 version I linked to is hosted by AU Group Electronics, a noted PICkit 2 clone and improved compatible programmer manufacturer that was actively involved with Microchip in extending the capabilities of the standalone PICkit 2 application, so is more trustworthy than many.

If you have a supposedly newer version of PK2DeviceFile.dat, one needs to dump it with Jeff Post's Dat2Text utility or with PK2CMD -?P to find out what it supports (and then hope the new devices actually work and no-one's goofed and broken any of the old devices).

[MarkF]

You can add new parts to the PICkit2 with the "PICkit2 Device File Editor".  I can't remember where I got it.  So, I attached the version I downloaded.

Were you able to add for example the PIC16F17XX series? Up until I wanted to start using those chips I typically found a way to use the PICKIT2 but I couldn't for the life of me get the PICKIT2 to work with those chips. Thats when I gave up and just bought a PICKIT3.

I haven't added any parts at all.  I did however modify one  part that was entered incorrectly.
The device file I uploaded has the following parts:
    PIC16F1782    PIC16LF1782
    PIC16F1783    PIC16LF1783
    PIC16F1784    PIC16LF1784
    PIC16F1786    PIC16LF1786
    PIC16F1787    PIC16LF1787

[MarkF]

Developing on parts you cant debug is a 'hair shirt' experience so I'd strongly recommend the O.P. restricts himself to parts with MPLAB PICkit 2 debug support, without an expen$ive mandatory debug header.   The standalone app part support list was included for completeness - if you want to seriously develop on the newer parts, for %DEITY%'s sake and your own sanity, invest in a PICkit 3!

However for those determined to proceed with the old-skool build-burn-crash development cycle, Device file 1.62.148 is probably fine as well, but the trouble with unofficial device files is "Who maintains the version number and functionally tests them?"  The 1.63.146 version I linked to is hosted by AU Group Electronics, a noted PICkit 2 clone and improved compatible programmer manufacturer that was actively involved with Microchip in extending the capabilities of the standalone PICkit 2 application, so is more trustworthy than many.

If you have a supposedly newer version of PK2DeviceFile.dat, one needs to dump it with Jeff Post's Dat2Text utility or with PK2CMD -?P to find out what it supports (and then hope the new devices actually work and no-one's goofed and broken any of the old devices).

The zip file for version 1.163.148 has both the PI2DeviceFile.dat and a html file with the parts list with the following notes
   "Added PIC16F527, PIC16(L)F145x,PIC12F501,PIC16(L)F1508/1509, 18F26K80-66K80, 18F J13, 18F J53".

I have both PICkits and the biggest drawback I see is that the PICkit3 can NOT supply enough power to program most PICs.

[Howardlong]

I have both PICkits and the biggest drawback I see is that the PICkit3 can NOT supply enough power to program most PICs.

I've never encountered that. Is this in circuit or standalone? Which devices have that problem?

 

[MarkF]

I was using a pic18f2550 in-circuit.  However, the supply for the PIC and the rest of the circuit are separate just to avoid the problem.  After re-reading the spec, the programming mode and run mode have different current requirements.  Maybe, the PIC can be programmed by the PICkit3 and I didn't realize it at the time.  I need to try it again.

I wonder now if it can be debugged with the PICkit3 since it can't supply the running current?

[Ian.M]

You shouldn't have any problems debugging a PIC running on external power, provided the ICSP/ICD pins are dedicated and there is no voltage difference between Vss and PC chassis.

However when you debug a PIC18F2550 or other USB PIC with an active USB device interface, you cant single step or successfully resume execution after a breakpoint as the host's USB stack will have timed out due to failure of the PIC device to respond while being held by the debugger.  Its fine for post-mortem analysis e.g inspecting memory after a crash. Usually disconnecting the PIC's USB interface, resetting it and reconnecting the USB will allow you to continue the debug session, but worst case, if you are unlucky with the exact timing and your host drivers, you may even need to reboot the host PC.