Programming second generation PIC processors
The (for me) first generation of PIC processors needed to be programmed in a parallel manner. They needed
extensive hardware support in the form of (in my case) a PICstart 16B development system.
This was a good system, but Microchip decided it could get better. So they invented the ICSP system in which
the processor could be programmed while inside the target system. This opened a lot of perspective for
companies that were going to use the new generation since it could be loaded with the most recent code just
before shipping.
I don't know how many companies actually do so, but I think it's practically none. It doesn't fit in with
warehousing techniques, so I guess most of the big companies still program the chips at the end of the
assembly line, and not at the exit of the warehouse. Thank you, MicroChip, for making it possible. But my
accountant says it's too expensive to use anyway. So much for progress.
Anyway, although the PICstart 16B can handle the early ICSP models like the 16C71 and probably also the 16C84,
the newer processors may cause small problems while code-burning. So it was time to shop around on the world
wide shopping net. There are many 'free' (as in 'free beer') programmers that fit the serial port or the
parallel port. Just about all of these programmers claim to be ICSP programmers but they're not.
They DO program the ICSP programmable processors in a serial manner but that's not the essence of an ICSP
programmer. As we will see later.
One of the first reliable serial port PIC programmers was the LudiPiPo programmer which came with a
programming IDE that closely resembled the original from MicroChip. But the Ludipipo could not handle the
PIC's that were fitted with Flash memory very well.
Since then, a lot of other programmers have seen the light. All of them were special and free (as in 'free
beer') but they all seemed to work. Or they didn't work. Or they worked sometimes. And since these gadgets
were 'free' (as in 'free beer') there was no warranty and no reason for the inventor to make a model that
worked on ALL hardware.
Strong and weak points of existing PIC programmers
In front of me, I have the JDM programmer like it is used in the picprog project. I can only say, that this is a novel design. The voltages of the serial port are well used such that:
The ICPPPP project
I have been thinking a lot about how to improve current designs. Many of these designs work on one PC and
refuse on a similar system at a friends place. Of course I could blame it on gravitational waves, earth
radiation and gnomes that interact with the density of the aether.
But I'm an engineer so I don't believe in fairytales. If the circuit doesn't run on all systems, it's not the host computer that is to blame. No, to blame is the design of the programmer circuit. A design must work on all systems, not just the one system that is available to you.
Therefore I want to exploit the fact that these chips are ICSP, which is short for
I - n C - ircuit S - erial P - rogrammableand so that's the way we are going to tackle the problem.
Since we're going to program the chip IN-CIRCUIT, we need a finished PIC project. Just go about with your CAD
software and design a neat little gadget with your PIC. Go about like you always did, but keep in mind that
we're going to program the processor AFTER it is soldered in place.
This means that we are going to mount a 6 pin connector somewhere on the board which contains:
On the board, you must isolate the RB6, RB7 and MCLR pins from the actual design by means of a 4k7 resistor
like you can see in the drawing on the right.
Now we can externally drive the RB6, RB7 and MCLR/Vpp pins from the side of the ICSP hardware.
This kind of programmer has several advantages:
The ICPPPP hardware
Below, you see the previous version of the ICSP hardware I am going to build. The circuit is simple and
straighforward, but I will explain anyway. The text already has the new contents. I need some days to update
the drawing. The new circuit will be made like Niklaus Wirth says it: as simple as possible, but not
simpler...
We start out by filtering the +5 Volt we got from the target system. We do so with the two capacitors of 100
nF and 10 uF. After this we feed the +5 Volts into a DC/DC converter which makes a nice but unstabilised +15
Volts out of it. We smooth out the +15 Volts with the 10 uF capacitor.
I'm going to make a flexible Vpp voltage. We start out with the 15 Volts we just made with the DC/DC
converter. We control the Vpp voltage with a serial DAC of type
TLC 5618,
TLC 5615,
or MAX 515. This DAC is fed with a +5 Volt reference so it produces 0 - 5 Volts.
But we need more, so we have to amplify it. That's what the TLC-272 is for. We boost the voltage to 0 - 15
Volts and the transistor also makes the output current larger.
The DAC is controlled by three datalines of the parallel port. Each signal line is first buffered by means of
a gate of the ULN 2007 chip.
The amplified Vpp signal is fed into the respective pin on the ICSP connector.
The serial programming lines RB6 and RB7 are controlled by datalines 0 and 1. Each dataline is also buffered
by a ULN 2007 open collector gate.
The signal coming out of RB7 is fed back to the parallel port interface via a comparator input (LM 339). I use
the comparator because I want to be independant of the technology that was used to manufacture the LPT
interface inside your system.

As you see, all signal lines are adequately buffered. There will be no loading of the parallel port interface.
The DAC is meant to be able to deliver a good and variable Vpp level. Since we use a DAC, we also need a
decent voltage to derive the Vpp from. For this reason we need the DC/DC converter. You may be tempted to
build your own, but I doubt it will be as good as the ones you can buy for a few euro's.
ICSP connectors
Both Atmel (AVR) and MicroChip (PIC) use ICSP technology to get program code into their processors. Below you
will see a small table with the names of the involved pins and their data directions. The table is not
complete. If you can complete it, send me an E-mail and I wil update the page immediately.
| Processor family | Functionality | Pin name | Data direction | Explanation |
| ICSP | Clock | Output | Serial clock | |
| Data | Input / Output | Serial data, bidirectional | ||
| Vpp | Output | Raised to +13 Volt to enter ICSP mode | ||
| ICSP | SCK | Output | Serial clock | |
| RESET | Output | Reset pin of AVR | ||
| MOSI | Output | Serial data TO the AVR target | ||
| MISO | Input | Serial data FROM the AVR target | ||
| JTAG | TCK | Out ??? | JTAG driving clock ??? | |
| TDO | Out ??? | Data going into JTAG system ??? | ||
| TDI | In ??? | Data coming from JTAG system ??? | ||
| Vref | Out ??? | ADC reference voltage ??? | ||
| TMS | ??? | - | ||
| NSRST | Out ??? | Some kind of RESET ??? | ||
| NTRST | Out ??? | Some kind of RESET ??? | ||
The 'data direction' is referenced to the pins of the parallel port. So an Output signal leaves the LPT port
and drives the ICSP system.
Right now I'm still unsure what the data direction is on the AVR JTAG pins. If there are not too many
inputs/outputs, we are going to try to make the ICP also fit for a supercheap JTAG interface. 5 to 6 outputs,
1 to 2 inputs and an analog voltage output are no big deal for the ICP.
The ICPPPP software.
As soon as I have built the hardware, I will start working on the software to drive the ICSP hardware programmer. Count on something like April 2005. But if you can beat me, please do so!
Page created January 2004,
Page equipped with FroogleBuster technology