Searching \ for 'Programming PICs in-circuit' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devprogs.htm?key=programming
Search entire site for: 'Programming PICs in-circuit'.

Truncated match.
PICList Thread
'Programming PICs in-circuit'
1995\12\20@185311 by Chris Smolinski

flavicon
face
I'm working on a project at work where I've managed to incorporate some PIC
chips (which I have been trying to do ever since I started playing with
them myself). Actually, not just some PICs, but 256 of them! I won't go
into terrible details, but basically each PIC monitors a sensor and outputs
status information onto a common bus, when instructed.

Here's my first (of probably many) questions:

I want to be able to program the PICs in circuit, so I'm using the 16C84.
That would make it very easy to modify their program in the field if bugs
are found (not that that ever happens ;-) or new features are required. It
also should make initial testing easier.

Programming speed isn't an issue. If it takes even a half an hour to
program all 256 PICs, that's OK. (but obviously faster is better) My
question is, how can I easily and economically parallel up the two inputs
(RB6 and RB7 if memory serves) used for programming? I can afford to
dedicate these two pins for programming, they aren't needed for actual
system use. Can I just tie them all together, assuming that the PICs that
aren't being programmed will tri-state their pins? (Decode circuitry is
used to place the appropriate voltages on MCLR on the selected PIC) My
concern is that the other PICs will load down the lines.

Also, the PICs seperated by about 2 meters total length, so I already know
I'll have to keep the programming speed down, and use termination, to avoid
reflections and other nasty transmission line problems.

Nothing like diving in head first on your first PIC project at work, eh?

Thanks in advance,

Chris



----------------------------------------------------------------------------
|Check out my WWW page at http://www.access.digex.net/~cps/ for ham radio    |
|software for the Mac; Free Radio, Shortwave Radio, and Spy Numbers Stations |
|information.                                                                |
|Finger me (spam_OUTcpsTakeThisOuTspamaccess.digex.net) for my PGP Public Key                      |
----------------------------------------------------------------------------

"Those who would gladly sacrifice liberty for security deserve neither."
                      -Ben Franklin

1995\12\20@194821 by Mike Keitz

flavicon
face
Chris Smolinski wrote:
>I'm working on a project at work where I've managed to incorporate some PIC
>chips (which I have been trying to do ever since I started playing with
>them myself). Actually, not just some PICs, but 256 of them! I won't go
>into terrible details, but basically each PIC monitors a sensor and outputs
>status information onto a common bus, when instructed.
>
>Here's my first (of probably many) questions:
>
>I want to be able to program the PICs in circuit, so I'm using the 16C84.
>That would make it very easy to modify their program in the field if bugs
>are found (not that that ever happens ;-) or new features are required. It
>also should make initial testing easier.


>
>Programming speed isn't an issue. If it takes even a half an hour to
>program all 256 PICs, that's OK.

If you use all the program locations, even under ideal conditions it will.
10 ms per location * 1024 locations * 256 chips = 43 minutes.  If your
program is smaller, or provisions are made for programming all or several
PICs in parallel at once, (then verifying them seperately) than the 30
minute time may be achievable.

(but obviously faster is better) My
>question is, how can I easily and economically parallel up the two inputs
>(RB6 and RB7 if memory serves) used for programming? I can afford to
>dedicate these two pins for programming, they aren't needed for actual
>system use. Can I just tie them all together, assuming that the PICs that
>aren't being programmed will tri-state their pins? (Decode circuitry is
>used to place the appropriate voltages on MCLR on the selected PIC) My
>concern is that the other PICs will load down the lines.

Consider connecting all the MCLRs together, and mutiplexing the programming
clock (RB6) to each PIC.  This pin is TTL-level and input only during
programming mode, so it might be easier to multidrive in a multiplex
arrangement than 13 V on MCLR to each one.  Also the multiplexing hardware
may be useful during operation to independently address each PIC.

>Also, the PICs seperated by about 2 meters total length, so I already know
>I'll have to keep the programming speed down, and use termination, to avoid
>reflections and other nasty transmission line problems.

Maybe break the PIC array up into 'banks' of 32 or so and using a seperate
Vpp driver and RB7 driver/receiver for each bank.

-- Mike
TIME CARD SAYS YOU'RE NAME'S "JOE" / BUT WE'LL CALL YOU "6-3-0"

1995\12\21@011503 by John Payson

flavicon
face
> Programming speed isn't an issue. If it takes even a half an hour to
> program all 256 PICs, that's OK. (but obviously faster is better) My
> question is, how can I easily and economically parallel up the two inputs
> (RB6 and RB7 if memory serves) used for programming? I can afford to
> dedicate these two pins for programming, they aren't needed for actual
> system use. Can I just tie them all together, assuming that the PICs that
> aren't being programmed will tri-state their pins? (Decode circuitry is
> used to place the appropriate voltages on MCLR on the selected PIC) My
> concern is that the other PICs will load down the lines.

The following suggestion may or may not work; I make no guarantees:

[1] Use eight drivers for D6, eight drivers for D7, and four for /MCLR.
   Arrange the chips in an 8x8x4 matrix [256 total].

[2] To program an individual chip, raise its /MCLR line to 12 volts while
   grounding the other three, and send out clock and data signals on its
   clock and data pins while leaving the other ones alone.

[3] You can probably program several chips at once, and verify them using
   a different pattern.  I'd suggest programming four at once [raise all
   for /MCLR's to 12 volts for programming, then use one D6/D7 pair at a
   time to program the chips] and then verifying the chips either one at
   a time or eight at a time [all the chips associated with a given /MCLR
   /D6 pair simultaneously].  If your /MCLR +12 supplies are beefy enough
   you may be able to program 32 at a time [use the same /D7 wire for all
   32 and stagger the clocks to ensure they don't all switch on their VPP
   supply simultaneously].

> Also, the PICs seperated by about 2 meters total length, so I already know
> I'll have to keep the programming speed down, and use termination, to avoid
> reflections and other nasty transmission line problems.

Not a bad idea...

> Nothing like diving in head first on your first PIC project at work, eh?

Hehehe...

More... (looser matching)
- Last day of these posts
- In 1995 , 1996 only
- Today
- New search...