EEVblog Electronics Community Forum
Products => Computers => Programming => Topic started by: perdrix on December 23, 2022, 05:30:44 pm
-
Has anyone been there, done that? This is to program a PIC from another microcontroller (an ARM as it happens).
Microchip have a rather dense document which defines the protocol, but I'd really like to find some working portable C code.
Thanks
David
-
Yes, a number of times.
It depends on the family, but for 8bit devices it's rather trivial, but i don't have code i can provide to you.
Depending on the host MCU you will be able to use SPI, or you will have to bitbang the protocol. But generally the first thing you have to do is enter ICSP mode (assert MCLR and send MCHP) and then send the command to read the device ID to verify you're in ICSP mode.
Then just write (load address, load data, begin write)
The rather dense document is not so dense :)
-
This is to program a PIC from another microcontroller (an ARM as it happens).
Thanks
David
The PicKit and PicStart Plus had a PIC MCU inside. I suspect the ICD's and others do too. A lot were sold and work well. So yes, you can use another microcontroller to program a PIC.
There are lots of knock-offs for the PK devices. Some might have source code available.
-
https://diyodemag.com/projects/arduino_pic_programmer (https://diyodemag.com/projects/arduino_pic_programmer)
-
Thank you,
Sadly, that appears to be aimed at some very old PICs - anyone have code that will work with a dsPIC33?
Thanks again, David
-
Sadly, that appears to be aimed at some very old PICs - anyone have code that will work with a dsPIC33?
But the code is written in fairly vanilla C so will run, with minor modification, on any processor.
-
will run on any processor.
I think they're asking about the PIC33 as a target, not as the programmer.
I don't know offhand whether PIC33s (16bit PICs with DSP functions) use the same protocols as the 8bit PICs, or whether there is any code for handling them :-(
-
One of the issues is the many subtle variants of Microchip's ICSP protocol over the years and different device families. If Perdrix needs to program a dsPIC33, that narrows it down a lot, but to be certain one's got the right 'flavour' of the ICSP protocol, one should always check the programming documentation for the specific part.
@Perdrix,
If the dsPIC in question is on the PICkit 2 device support list or is very similar to one that is with the same ICSP protocol documentation, it may well be worth looking at the PICkit 2 firmware source to see how Microchip handled programming it. You'll probably also need to look at the application source to see what commands are being sent to the programmer. See: https://www.microchip.com/forums/FindPost/804296 (https://www.microchip.com/forums/FindPost/804296) for links to everything PICkit 2 related that you may need.
The PICkit 2 firmware sourcecode is written in Microchip C18 to run on a PIC18F2550, and C18 was notorious for not being fully ANSI C89 compliant, so porting the code may offer some challenges other than just changing hardware platforms. YMMV.
-
Yes indeed it is a dsPIC33FJ12MC201 that is the target IC that I wish to program. And YES it is supported by the PICKit2/3 - that's good.
Whether the source makes sense only time will tell.
Thank you.
David
-
Might not worth the time, on Amazon there are plenty of programmers between $10-$50.
https://www.amazon.com/Pic-Programmer/s?k=Pic+Programmer (https://www.amazon.com/Pic-Programmer/s?k=Pic+Programmer)
If you want to write your own code, this is the protocol for dsPIC33. Less than 20 pages including C code snippets:
https://ww1.microchip.com/downloads/en/DeviceDoc/dsPIC33-PIC24-FRM,-Flash-Programming-DS70000609E.pdf (https://ww1.microchip.com/downloads/en/DeviceDoc/dsPIC33-PIC24-FRM,-Flash-Programming-DS70000609E.pdf)
-
I should warn you the PICkit 2 firmware and application code is fairly complex, as it handles all the different 'flavours' of ICSP required by stringing together script commands to do the actual bit-twiddling work rather than by loading different binary 'blobs' for each 'flavour' as the PICkit 3 (in MPLAB mode) and later programmers do. However its what we've got that is open source and sufficiently documented . . . .
@RoGeorge: The object appears to be to support programming a slave dsPIC from a blank ('factory fresh') state *WITHOUT* needing to use an external programmer for it, presumably to simplify production line programming of the whole system. I fail to see how a budget development programmer clone from Amazon can help, but maybe you can enlighten me . . .
@Perdrix: Have you considered taking an end-run round the whole problem and ordering your dsPIC33FJ12MC201 chips from MicrochipDirect, pre-programmed with a bootloader of your choice?
-
Thank you to all,
The pointer to the PICKit3 firmware source was *most* helpful. The reason for doing this is to reprogram PICs that are in Gemini-2 telescope controllers that are out in end user's hands, without needing them to return them for re-programming, or to learn to use a PICKit3/4 themselves.
Thanks again, David
-
Is using the PTG feature in the PICkit3 or 4 out of the question? If PTG works on the cheap PK3 clones that's probably the easiest, cheapest and fastest way.
-
Thanks, we did consider that option.