Byron A. Jeff  byron at cc.gatech.edu says:

It's possible to build a 16F87X programmer out of a cable, two resistors, a switch and an LED. Could completely automate it by replacing the switch with a MOSFET.

Software wise I'm using what I know: picprg 2.2 under Linux. Be aware that for 2.2 kernels it requires a patch and some dancing. Let's talk about these first.

The patch is required because PicPrg uses the lp_struct from linux/lp.h Unfortunately this completely changed with the addition of parport. What I did is remove the following from lowlvl.c line 57:

-----------------------------------------------------
/* Sometimes this is in /usr/include/linux/lp.h sometimes not */
struct lp_struct lp_table[] = {
        { 0x3bc, 0, 0, LP_INIT_CHAR, LP_INIT_TIME, LP_INIT_WAIT, NULL, NULL, },
        { 0x378, 0, 0, LP_INIT_CHAR, LP_INIT_TIME, LP_INIT_WAIT, NULL, NULL, },
        { 0x278, 0, 0, LP_INIT_CHAR, LP_INIT_TIME, LP_INIT_WAIT, NULL, NULL, },
};
-----------------------------------------------------

And replaced with an equivalent structure:

-----------------------------------------------------
unsigned mylp_table[] = { 0x3bc, 0x378, 0x278 };

#define LP_B(x) (mylp_table[x])
-----------------------------------------------------

because picprg only uses the base address from that structure through the LP_B macro.

Now the dance is setting up the correct port. With the advent of parport parallel port number assignment has become dynamic. In kernel 2.0 lp0 was always 0x3bc, lp1 -> 0x378, etc. Now the first detected port becomes lp0 no matter what base address is assigned. This confuses picprg because it expects static assignments. The quick hack around it is to simply link the port that matches the base address of lp0 to the port that picprg expects. For example say you have a single parallel port at 0x378. The 2.2 kernel assigns that port to lp0. However picprg expects that address to be assigned to lp1. So the following:

# rm /dev/lp1
# ln -s /dev/lp0 /dev/lp1

Makes picprg happy because it can now open /dev/lp1 even though it doesn't really exists.

I have a student working on patching this so that picprg 2.3 (I guess) will do the static assignments if /proc/parport doesn't exist and will dynamically fill the array with the correct addresses if it does. I think also changing the port assignment to the base address will simplify the problem. So instead of saying port 2, say the port with address 0x278. Then picprg can automagically find the correct device that matches the port so even if you remove/add a parallel port to your system, picprg 2.3 will still have the correct assignment.

The final patch to picprg 2.2 is changing the 0x08 begin programming command in lowlvl.c to 0x18, which is the 16F87X equivalent. We plan on adding a switch so that the existing PIC16F84 programmer can be used to program both 16F84 and 16F87X parts.

Now at this point you can use a normal Tait style programmer to program 16F87X parts under current Linux 2.2 kernels.

But the 16F87X has low voltage programming mode. That means that none of the high voltage generation circuitry is required to program the part. Since a Tait style programmer is little more than a straight parallel cable with HV generation circuit, once you remove the HV circuit, all that's left is the cable.

PicPrg2.2 is quite flexible in its pin assignments. Here's my 16F84 config file:

--------------------------------
# Linux PIC programmer configuration v2.0
port=1
vpp=+5
vdd=-4
clock=+3
datao=-2
datai=+10
idaddr=2000
eeaddr=2100
cfaddr=2007
colors=1
----------------------------------

So on my cable I'd simply have to wire the pins listed:

• Pin 5 from the cable goes to RB3 (LVP)
• Pin 3 from the cable goes to RB6 (clock)
• Pin 2 from the cable goes to RB7 (DataOut). But since the parallel port doesn't have tristated drivers, there must be a 1K resistor between the cable and the pin. So when RB7 drives the pin it doesn't short.
• Pin 10 from the cable also goes to RB7 (DataIn) which will detect when the RB7 is driven.

The switch, resistor, and LED are for Vdd so that 5V can be switched to the programmer and show when the programmer is on or off. Again pin 4 could be wired to a logic level MOSFET that will provide the part power automatically. BTW I'm stealing power from the keyboard. It's also possible to steal power from a PS/2 or game port also.

That's it (Note the polarities may be incorrect, Run picprg's config and test the signals on the cable first).

Programming should be:

• Turn programmer off
• Insert part
• Turn programmer on
• Run picprg 2.2 to download
• Turn programmer off
• Remove part.

Of course you can remove the programmer off/on if Vdd is wired from the Voila! And if you configure the part for HVP by clearing the LVP bit then you'll even get RB3 back once you put the part into its circuit. Of course you could simply blow in something like Tony's ROMZap, get RB3 back, and further program the part in circuit via the serial port. But as a one off the cable should be doable in about a 1/2 hour.

Comments:

• ~NOSPAM~vettemphspam at yahoo.com

  /techref/microchip/16F877/taitlinux.htm I believe this concept is missing something. I have never programmed a pic before but i have been doing alot of reading and will sone do so, anyway, This post claims that connecting pin 5 from the cable to RB3 will be enough to enter programming mode for LVP. (pin 5 used to control 13 volts to Vdd for HVP) The Microchip programming guide states that to enter LVP you must set RB3 to Vdd, Then set /MCLR to Vdd. the cable described in this post (and assocciated software???) does not mention /MCLR. what should i do?
  BTW I made a DIA circuit of the infomation thus far and will update and post it when all is fixed.

  +

Questions:

• ~NOSPAM~dsnydersspam at istop.com asks:

  I am getting ready to program my '877 for the first time. I get the impression that I do not need to connect the timing crystal circuit, just RB3, RB6 and RB7. Is hooking up the crystal one of those "givens" like hooking up the power - so obvious that you don't need to mention it? Or is the crystal not needed because the RB6 (clock) is supplying the timing?

  +

  .