please dont rip this site

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:

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:

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:

Questions:


file: /Techref/microchip/16F877/taitlinux.htm, 7KB, , updated: 2006/7/10 22:02, local time: 2024/12/30 06:20,
TOP NEW HELP FIND: 
18.221.147.141:LOG IN

 ©2024 These pages are served without commercial sponsorship. (No popup ads, etc...).Bandwidth abuse increases hosting cost forcing sponsorship or shutdown. This server aggressively defends against automated copying for any reason including offline viewing, duplication, etc... Please respect this requirement and DO NOT RIP THIS SITE. Questions?
Please DO link to this page! Digg it! / MAKE!

<A HREF="http://techref.massmind.org/techref/microchip/16F877/taitlinux.htm"> Programming an '877 with a stripped down Tait (basically a cable) under Linux by Byron A Jeff</A>

After you find an appropriate page, you are invited to your to this massmind site! (posts will be visible only to you before review) Just type a nice message (short messages are blocked as spam) in the box and press the Post button. (HTML welcomed, but not the <A tag: Instead, use the link box to link to another page. A tutorial is available Members can login to post directly, become page editors, and be credited for their posts.


Link? Put it here: 
if you want a response, please enter your email address: 
Attn spammers: All posts are reviewed before being made visible to anyone other than the poster.
Did you find what you needed?

 

Welcome to massmind.org!

 

Welcome to techref.massmind.org!

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  .