1
\$\begingroup\$

Specifically, using the GPIO pins of a Raspberry Pi, which PICPgm does explicitly support, but I think that's irrelevant unless it's an XY problem.

PICPgm's home page lists a bunch of devices that it's explicitly compatible with, but my relatively new one isn't in that list. There's a way to add a new programmer by editing a config file, but adding a new device is glaringly absent from any documentation that I can find. PICPgm's forum is 404, and Microchip's forum isn't very helpful either.

Microchip's Programming Specification for my device suggests that the hardware is okay, in that the Pi's GPIO pins are capable of providing and accepting the right signals for Low-Voltage-Programming (LVP). So before I dive into this ratsnest of hardware again and bury another new module into it, how can I be sure that I won't have to dig it back out again just to put my PICkit on it?

(I'll just leave the programming interface permanently connected to the GPIO's, which are normally configured to let the chip run.)

\$\endgroup\$
3
\$\begingroup\$

Looks like this particular case was an XY problem. I never found how to add my device to PICPgm's supported list, but a slightly different permutation of the Google search terms got me a thread that I hadn't seen yet on Microchip's forum, where someone mentioned a different programmer that I hadn't seen before either.

"Pickle" appears to come primarily as source code, although there is a token precompiled image available for the Pi. I built it from source, so if I really need to, I can make it do anything at all. That won't be necessary right away, as it already recognizes the device that I'm using at the moment.

And it does indeed program the part in LVP mode (given an explicit command-line switch - otherwise it tries to use HVP, which isn't available for this project), and verify correctly, using 3 GPIO signals at 3.3V: !MCLR, PGC, PGD. Verifying before programming fails as expected, and succeeds after programming, so it did indeed change something. And it releases !MCLR by default so that the chip can start running with the wires still hooked up, which then does what it's programmed to do.

The argument structure seems a bit odd to me, but once it's in a script that my IDE can call, that doesn't matter.

(!MCLR is called VPP in the config file, and what it calls PGM is not used: set that one to -1, and the others to the GPIO numbers (not pin numbers) that you want to use)

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.