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"