ZEPPP: Arduino-based PIC programmer for several old-school microcontrollers.

[battlecoder]

This is a project I finished around September and it wasn't until now that it occurred to me that it was perhaps a good idea to share it here. 

ZEPPP (Zero External Parts PIC programmer) is basically a PIC programmer that requires only two things: A standard Arduino Nano/Uno/Pro-mini and your computer (and the PIC of course!)
It connects directly to your target microcontroller (or any dev board with a LVP-capable ICSP connector).

The command line tool works on Linux, Windows and OSX.

It currently supports the following PICs:

• 16F87, 16F88
• 16F627A, 16F628A, 16F648A
• 16F873A, 16F874A, 16F876A, 16F877A.

While I guess it makes little sense to most developers or engineers to use such "outdated" devices, I think they are still great for learning, and for simple projects.

This is perfect for people who want to try their hand at PIC programming but don't want to (or can't) invest in proper programming hardware. In fact, I started this project for a workshop I was organizing; I had made PIC demo boards for everyone, but it was too unpractical to get PIC programmers for all the attendants, or to expect them to bring their own. Now, most of them already had Arduino boards, and I had several of my own that I could take with me for those who didn't have one.

I made a quick post about this programmer on my blog, but you'd probably be more interested in its GIT repository, where all the latest files are.


If any of you give this project a try let me now! Feedback is always a good thing to have (said no audio engineer ever).

[jaromir]

Thanks for sharing.

I made similar programmer for newer 8-bit devices - https://github.com/jaromir-sukuba/a-p-prog - and really didn't bother to support the older ones (with PGM pin), so your work is great addition to simple PIC programmers.

[battlecoder]

Awesome project, jaromir! Indeed quite similar to what I did. I'm glad to see something aimed towards more modern microcontrollers, especially with such a wide range of supported devices!

For ZEPPP supporting more than one family was a real pain in the rear ...panel. A lot of timing and protocol differences. The programming specs for older devices are all over the place. Hopefully the latest iterations of Microchip's programming specs are more streamlined after their years of experience. I can't imagine the pain of supporting that many devices if the spec are as wildly changing as they used o be.

[rrinker]

 Interesting - if I didn't already have a PICKit 2. I have a box full of 16F873/877 (whichever the complementary ones are, where the one has more memory but is otherwise identical). An old circuit I was going to use used the smaller chip, I figured the extra memory wouldn't for the most part break code written for the one with less memory, and so managed to get several dozen as samples. I've since changed my approach and instead of building someone else's interface design using the PIC chips I am designing my own with Atmel micros. I should do something with all those PICs though. Port my code and make some of my board with the PIC, but I'd rather not have a mix of devices, even though it is all for personal use. I suppose if they would be indistinguishable at the sharp end, it wouldn't matter. At any rate, I hate to see a box full of potentially useful chips just go to waste, at some point I'll come up with some project to use them in.

 These may be older chips, but there are still plenty of applications that don't need the speed and/or memory of ARm cores and the like. Using faster micros where the project involves mostly waiting for user input just means the thing executes more keyboard scans than a slower one - the old slow ones are more than capable of performing the task.

 Neat thing about this - I could just set it up as a shield with a ZIF socket and use the same Arduino with my ATTiny shield, or a PIC shield, depending on what I wanted to program. Effectively one platform for multiple purposes. In fact, if it's possible to change around some of the pins being used - it could be BOTH, depending on the code loaded to the Arduino.

[battlecoder]

At any rate, I hate to see a box full of potentially useful chips just go to waste, at some point I'll come up with some project to use them in.

Same, but eventually -even if it's 7 years later- I always find a use for the stuff I have (it has happened), and everything is fine again (except for all the stuff I bought during those 7 years, that will sit there unused, bothering me for probably an equally long time).

Neat thing about this - I could just set it up as a shield with a ZIF socket and use the same Arduino with my ATTiny shield, or a PIC shield, depending on what I wanted to program. Effectively one platform for multiple purposes. In fact, if it's possible to change around some of the pins being used - it could be BOTH, depending on the code loaded to the Arduino.

That's a really great idea. Pins can be changed to whatever you like. All communication happens using regular digital pins. It would be even better if the same firmware can talk to both PIC and Arduino devices, depending on handshake and/or serial instructions being issued by the host. That could be the beginning of an extremely simple multi-microcontroller programmer.

[NorthGuy]

I have also designed a PIC programmer once. It was PIC based and supported over 1500 different PIC parts. It also worked very fast. It isn't open source, so I cannot share the code, but it was lot of work to deal with all the individual PICs. Microchip is really idiosyncratic.

[battlecoder]

I have also designed a PIC programmer once. It was PIC based and supported over 1500 different PIC parts. It also worked very fast. It isn't open source, so I cannot share the code, but it was lot of work to deal with all the individual PICs. Microchip is really idiosyncratic.

I'd love to see that. I really like the concept of DIY Programmers (or DIY instruments/gear in general). Building your own tools definitely feels good. And yes, the programming protocol specifications for different families can vary a lot. Especially for older devices.

Did your programmer use HVP though? ( I can't imagine supporting 1500 parts with LVP. There are many variations of the "handshake" and many limitations with LVP).

I have to say I kinda imagined that many of you had already designed programmers with support for a gazillion devices. Mine basically supports a list equivalent to the one my first PIC programmer supported, lol. But I'm quite happy with that. Will look into adding support for more modern devices though, but with projects like the one by jaromir, I don't know what the usefulness of that would be.

[NorthGuy]

Did your programmer use HVP though? ( I can't imagine supporting 1500 parts with LVP. There are many variations of the "handshake" and many limitations with LVP).

HVP and LVP are practically the same. The only difference is the entry routine. However, you need to supply higher voltage. This higher voltage was used to do flash programming, but this was very long time ago. Now PICs just sense the presense of high voltage - you don't need neither good regulation nor high current. I programmed in all the logic, but you would need to supply the 9V or 13V voltage for it to work.

I have to say I kinda imagined that many of you had already designed programmers with support for a gazillion devices. Mine basically supports a list equivalent to the one my first PIC programmer supported, lol. But I'm quite happy with that. Will look into adding support for more modern devices though, but with projects like the one by jaromir, I don't know what the usefulness of that would be.

If it is useful to you, it may be useful to others.

[battlecoder]

HVP and LVP are practically the same. The only difference is the entry routine. However, you need to supply higher voltage. This higher voltage was used to do flash programming, but this was very long time ago. Now PICs just sense the presense of high voltage - you don't need neither good regulation nor high current. I programmed in all the logic, but you would need to supply the 9V or 13V voltage for it to work.

Yes, but not all devices support LVP, and those that DO support it, have several different entry methods. That was my point: It would be harder to support a broad range of devices if restricted to LVP only. Even if you are wiling to implement all the variations of the LVP "handshake", you are already starting with a subset of the whole PIC catalog.

[NorthGuy]

Yes, but not all devices support LVP, and those that DO support it, have several different entry methods. That was my point: It would be harder to support a broad range of devices if restricted to LVP only. Even if you are wiling to implement all the variations of the LVP "handshake", you are already starting with a subset of the whole PIC catalog.

This is a very big subset. I'd say over 90% of all currently sold PICs support LVP. All PIC24/dsPIC33 are LVP-only (some of smaller PIC24 can do HVP), all PIC32 are LVP-only. All modern PIC16 and PIC18 support LVP (and HVP). It is not that many HVP-only PICs - a limited number of older/smaller PIC16/PIC18 parts and most of the PICs from the totally obsolete dsPIC30 group.

[battlecoder]

All PIC24/dsPIC33 are LVP-only (some of smaller PIC24 can do HVP), all PIC32 are LVP-only. All modern PIC16 and PIC18 support LVP (and HVP). It is not that many HVP-only PICs - a limited number of older/smaller PIC16/PIC18 parts and most of the PICs from the totally obsolete dsPIC30 group.

Oh, that is quite interesting. I never got into dsPIC, PIC24 or PIC32. Didn't know they were mostly LVP-only devices. In my experience (with PIC16/18 parts) PICs were either "HVP/LVP compatible", or "LVP-only". Thanks for the correction. Glad to have that piece of outdated knowledge in my head updated.

[NorthGuy]

I never got into dsPIC, PIC24

You should try them. They're very interesting. They're a little bit similar to PIC16/18, but they are way more powerful.

Their programming algorithms are very complex though - it would take a while to figure out. You can program then through so-called serial command execution, but it is so slow that you have to upload a small program called "programmer executive" (bootloader if you will) which accepts data from the programmer and programs flash.

But it's not as bad as PIC32. The serial execution in PIC32 is done through JTAG-over-ICSP and is so slow that even uploading the programming executive is costly. You need first upload a loader which will then help you to upload programming executive which, in turn, lets you program the flash.

[battlecoder]

You should try them. They're very interesting. They're a little bit similar to PIC16/18, but they are way more powerful.

Their programming algorithms are very complex though - it would take a while to figure out. You can program then through so-called serial command execution, but it is so slow that you have to upload a small program called "programmer executive" (bootloader if you will) which accepts data from the programmer and programs flash.

I have several PIC programmers, one of them being a PicKit3, so I guess I should be good to go. Will start reading about them. I have to admit it's been a while since the last time I tried a new PIC microcontroller. Any particular device you'd recommend?

[jaromir]

For sake of completeness - you can program PIC32 using Arduino, using PIC32prog; it supports more than this programming interface, though. I wrote quick how-to here - https://hackaday.io/project/27250-mcu-how-tos-reviews-rants/log/148016-programming-pic32-with-arduino
It is not the most useful way of loading PIC32 (it takes almost three minutes to load 512k of FLASH), but can be useful as last resort method; or perhaps low cost way to load bootloader once and use the bootloader afterwards.

You can get PIC32 in DIP packages, fine for prototyping - I have a few PIC32MX250F128B in my drawer, those are quite universal and proven devices. Similar is also PIC32MX270F256B with even more memory. If you are into higher pin count packages, you may take a look at PIC32MX470F512 or perhaps newer PIC32MZ2048EFH064. Notice the EF in middle of partnumber, avoid EC parts; despite being similar, its errata sheet is more spicy.
Oh and always check errata of the part you intend to use. That is also reason I'm not much into the most recent MCUs - the errata list is usually growing in first few years, improving later. The same goes for documentation and online resources; and holds true not only for Microchip.

[NorthGuy]

For sake of completeness - you can program PIC32 using Arduino, using PIC32prog; it supports more than this programming interface, though. I wrote quick how-to here - https://hackaday.io/project/27250-mcu-how-tos-reviews-rants/log/148016-programming-pic32-with-arduino
It is not the most useful way of loading PIC32 (it takes almost three minutes to load 512k of FLASH), but can be useful as last resort method; or perhaps low cost way to load bootloader once and use the bootloader afterwards.

This is rather on a slow side. My programmer could program PIC32MX570F512 in 11 sec. But I'm sure if you optimise it a little bit, it can be done much faster than 3 minutes with Arduino.

[jaromir]

It's not my work, I just wrote the article (I made the PIC16/18 programmer mentioned earlier, though) Yes, it is glacially slow, but work nonetheless, costs two dollars and can be repurposed for something else. I had intentions to start my own PIC32 programmer a few times, but looking into PIC32 programmings specs put me off every time.

On the other hand, your programmers are the fastest ones known to me (faster than the official Microchip tools) and I'm pretty sure it took a lot of work to optimize it. My hat's off to you.

[NorthGuy]

Any particular device you'd recommend?

There are lots of different PIC24/dsPIC33 devices, so it depends on what you want.

There are small devices - PIC24F..K - they are the most similar to PIC18 and very cheap, but they have PIC24 CPU.

Big monsters with USB controllers, such as dsPIC33EP...GU..., dsPIC33EP...MU...

Small devices with fast PWM/ADC designed for SMPS and similar - dsPIC33EP...GS...

Slow general purpose devices with 1MB flash PIC24FJ1024GB6...

Recent addition with dual core - where the second core runs from RAM and has to be pre-programmed by master dsPIC33CH...

Take you pic(k).

[JPortici]

I have also designed a PIC programmer once. It was PIC based and supported over 1500 different PIC parts. It also worked very fast. It isn't open source, so I cannot share the code, but it was lot of work to deal with all the individual PICs. Microchip is really idiosyncratic.

I also did a programmer, actually a software library to update the code for the slave pic from the master pic.
 The one bit i never understood is the reverse order SPI (LSB first) do you have any idea why they did it this way?

[JPortici]

Anyway, My goto dsPIC is the 33EV series which is 5V only (really, 4.5 to 5.5V. If device doesn't work check VDD first) but has a lot of goodies, and less gotchas than the MU series (like IC and OC modules are truly independent)

Then of course for 3.3V the 33CH/CK series. Extremely versatile beasts, altough no usb (hence why i had to implement a programmer for a pic that acts as an usb bridge. Why? Because no usb/whatever bridges in extended temp range and at sane prices)

The architecture is very nice IMHO, with clear and simple assembly and a lot of grunt thanks to the dsp and many addressing modes

[NorthGuy]

The one bit i never understood is the reverse order SPI (LSB first) do you have any idea why they did it this way?

I don't know why they did it. Since these are instructions, it might have been done either way.

When you enter into the programming executive mode, it connects the PGC/PGD pair to SPI1. So, your programming executive simply uses the SPI module to communicate with the programmer. Then it naturally becomes MSB first.

[NorthGuy]

On the other hand, your programmers are the fastest ones known to me (faster than the official Microchip tools) and I'm pretty sure it took a lot of work to optimize it. My hat's off to you.

In the early days, when I started, I found your web site on debugging PIC18. It was the best information on the subject I could find and it gave me good understanding on how PIC18 debugging works. Thank you for that web site! Although I'm now busy with other things, hopefully I find time to finish the debugger GUI.

[ThaZ]

Hi, is there any chance that this programm is gonna be supports the PIC18F47J53 ?

[battlecoder]

Hi, is there any chance that this programm is gonna be supports the PIC18F47J53 ?

In theory support for that kind of device can be added, but it uses a completely different method to enter programming mode, and apparently a newer revision of the ICSP spec so it may take a bit to implement. My programmer is designed for old chips but I may eventually update it to support newer PICs. Just can't promise anything.

Anyway, I'd advise you to check the comments of other users in this thread. Some of them have made similar projects but for a wider range of devices, most of them from the newer families that mine does not support.

[panoss]

Hi battlecoder, thanks for sharing your work.
I 'm trying to understand your code and how e.g. from the 'PIC16F627A/628A/648A EEPROM Memory Programming Specification' you created the code you created.
(because I want to be able to do the same for any MCU or EEPROM and specifically for an EEPROM I have(EN25F80))

I read in the above mentioned document, page 11:

To perform a Bulk Erase of the program memory, the following sequence must be performed:
1.Execute a Load Data for Program Memory with the data word set to all ‘1’s (0x3FFF).
2.Execute   a   Bulk   Erase   Program   Memory   command
3.Wait TERA for the erase cycle to complete.

From this you created this code:

Code: [Select]

ReturnCode execute_serial_cmd() {
switch (cmdCode) {
// PGM Memory Erase --------
    .................
    case ZEPPP_CMD_PGM_MEM_ERASE:
      load_pgm_mem (0x3fff); 
      bulk_erase_pgm_mem();   

Am I correct?

[amyk]

A set of wires connected to a PC parallel port will do LVSP just as well.