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:

But there are also some drawbacks. Drawbacks that are not limited to this particular programmer but to most programmers that connect to the serial ports: And, most importantly, these programmers are not ICSP hardware! They employ the fact that modern PIC's CAN be programmed In Circuit but the programmer itself still is stand alone. Even worse: if you use this kind of programmer on the ICSP terminals of a commercial system, you're in for a surprise. You might as well end up with a fried serial port. And since all of these are on the mainboard nowadays, you might be standing in line for a new mainboard the next day.

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 - rogrammable
   
and 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:

  1. +5 Volt (to power the programmer)
  2. Vpp (aka MCLR)
  3. Ground
  4. Ground
  5. Serial clock (aka RB6)
  6. Serial data in/out (aka RB7)

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:

One of the things that turn me off on the internet is the fact that many people refuse to pay money for anything else than their PC and their broadband internet access. Everything else seemingly needs to be for free.
People spend EUR 10 on a PIC processor, but the programmer may cost nothing. And I think that's bad. It's bad for economy, but it's also bad for the state of western engineering. If we keep producing too many of these 'free beer' projects, the far east companies will soon take over and we will not only loose the unskilled labour, but also the skilled labourers, making development countries from the european states where the developments were started in the first place.

Therefore my drive is to make projects that work on ALL platforms and under all circumstances. At least the hardware part of it. The software part may need some effort from dedicated programmers, looking for a (free, but not as in 'free beer') challenge.
The Parino card is used by hobbyists who feed their fishtanks with it during longer holidays, but there are also some farmers who have automated parts of their farm equipment with it. The card is stable. It will accept damage, but it won't pass the damage through to the computer.

I want my ICSP programmer to be based on the same kind of rigidity. If you spent EUR 1000 on a computer, EUR 200 per year on internet access, you can also spare another EUR 25 for a decent and reliable ICSP programmer (that might even work on other CPU's as well).

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.

ICPPPP hardware

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
Microchip PIC ICSP Clock Output Serial clock
Data Input / Output Serial data, bidirectional
Vpp Output Raised to +13 Volt to enter ICSP mode
Atmel AVR 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
Atmel AVR 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!

Project abandoned.

Shifted my attention to the AVR line of processors

Follow it in the AVR section.

Page created January 2004,

Page equipped with FroogleBuster technology