Programming a PIC with a PIC

Question

I'm building a device with two PICs, a PIC18F46K22 and a PIC16F88. I have a buffer on the 18F46K22 which contains a program that I want to write to the program memory of the 16F88. I can't do this manually, because it has to happen on the fly (the buffer might change), so the programming has to be initiated by the 18F46K22. The CONFIG bits can be set manually though, I don't need to change them on the fly. There is also no need to write to the 16F88's RAM or EEPROM by the 18F46K22.

The two chips are powered with 5V and there is no 12V supply available. I guess I'll have to go with Low Voltage Programming (LVP)?

Is there anyone who has done such a thing already? Is there some code or a circuit available somewhere to program a PIC with a PIC?

In the end, this is to make a basic PIC-based coding device: the user edits the buffer on the 18F46K22, programs the 16F88 with it. There will be an I²C interface between the two so that there can be some sharing of results. The programming to the 16F88 will be for mathematical purposes only: the chip gets some input over I²C and a START trigger on some pin. After that, the result is sent back over I²C.

Answer 1

Programming one PIC by another PIC is perfectly possible, and when you use LVP the circuit is trivial. The effort is in writing the code on the master PIC that implements the programming algorithm, according to the specs in the 'programming specification' document for the slaved chip. This is what most programmers (the hardware thingies, not the people) do, but note that in most cases the programming algorithm is at least partially implemented in the PC side software.

There are various examples that you can check, the pickit2 has already been mentioned. My Wisp648 firmware (in Jal) and PC side software (in Python) are also open source, and IIRC the software for Olin's programmers is too.

But the programming specifications are not that hard to read an implement from scratch, especially if you need to support only one target chip. Essentially you force the chip into programming mode (release reset while LVP is active), and then you feed it commands and associated data (in a SPI-like fashion), observing the required timing. Afterwards you can use an off-the-shelve programmer to check whether your programming effort was successful.

Another solution would to to put a bootloader in the F88. The down side is that you need to program the bootloader (but a suitable one might exit already) and that the bootloader takes some memory, but the up side is that you can choose the communication protocol (or stick to an existing bootloader, which will often use a UART-based protocol).

Answer 2

I agree with what Wouter said.

I also sell PIC programmers on the side. All the software and firmware for my programmers is included in the Development Software release at www.embedinc.com/picprg/sw.htm. There is a lot of complexity there, but that is because this software/firmware has to support so many different programming algorithms. Microchip's POD (Programming Obfuscation Division) has some very clever people that consistantly dream up new and different little things you have to do to program PICs. Despite their best efforts though, it is still possible to program all the various PICs, but it requires a lot of digging and reading between the lines of the sometimes outright wrong documentation. The software/firmware in that release would be vastly smaller if all PICs were programmed the same way.

Fortunately, your firmware can be specific to the particular PIC you are trying to program. You have to get the programming spec and read it carefuly, but you can afford to ignore all the other programming specs. You can probably make use of a bunch of lower level firmware modules I have, especially for the USBProg programmers. That is the EUSB firmware, which also uses common files names PICPRG_xxx.INS.ASPIC. All of that firmware is intended to run on a PIC 18, so much of it should be usable directly.

I usually have the programmer present roughly a address/read/write interface and have the host software deal with the higher levels. Fortunately, the higher levels is the relatively easy part. You will have to look in the host software for examples of the erase algorithms. I push those onto the host since each one is run only once per programming operation, so speed is not a big issue.

Ask here if you have any more specific questions.