Post by thread:Universal Programmer Design (was: PIC16C620 with 1

> > |Again for each EPROM the position, voltage, and algorithm are different for > |each part. The great thing about PICs are their consistency. All 12 bit parts > |program the same, all 14 bit parts program the same, all 16 bit parts program > |the same. It really simplifies things. > > Actually, there's a lot of consistency among the 27xx EPROMs. The > VPP is always in the same place (though not always the same voltage) > relative to the bottom of the chip, as is almost everything else. > The only somewhat tricky bits are [1] Having a programmable VPP, and > [2] having address drivers that can supply a good strong +5 at pins > 26 and 30 of a 32-pin device, since on 24- and 28-pin devices those > will be the VDD supply. > > As for PIC's, there are two methods for 12-bit parts (16C5x vs 12Cxx) > and two for 16-bit parts (the 17C42 requires parallel programming [why > the #$@$?] while the 17C56 allows for serial as well). The 17C42 was the very first 17CXX series part. I have engineering samples dated in 1993. Microchip probably hadn't figured out that serial programming is the best method when they designed it. {Quote hidden}> > |I had some thoughts along that line. Create a base unit that housed the > |intelligence (a PIC of course) and the PC interface. Then instead of having > |the complexity of trying to fit all possible chips into a single socket, and > |trying to shove all the programming code for a host of chips to program, go > |the route of modularizing via an expansion card. The card would contain three > |things: > > |1) The socket to program the part. > |2) Any extension circuitry required to program the part. > |3) A serial EEPROM that contains the programming algorithm. > > This sounds somewhat like the "personality modules" a lot of programmers > used to use; I'd go with a somewhat simpler design than yours, though: > use a pair of dual-row (0.1" spacing) 40-pin sockets, with one of them > tied pin-for-pin to a 40-pin ZIF and the other one wired to... > > 24-bits of bidirectional shift registers [wired as a group of 16 and a > group of 8]. Been thinking about that. I have a gut feeling that while more expensive that using PIC programmable pins would be more flexible. You'd get: - Input/output/float - bit or byte selectible - high current source/sink - programmible timed pins - extra RAM. While the 16C877 would be perfect for the job, until it's in wide production I'd consider using say 3 16F84 instead of a 16F84 and 2 or 3 shift registers with the other 2 16F84 being utilized as I/O subprocessors. A one pin serial interface using RA4 and a pullup should be sufficient to get the job done. {Quote hidden}> a programmable VDD [which also powers the shifters] > the programmer's [unswitched] VDD > 8 or so PIC port pins. > a programmable VPP pin [high-current VPP, VDD, and Vss, or floating] > feedback control for VPP > ground > > Setting the device up to program different devices would simply require > connecting together two 40-pin dual-row headers in an appropriate con- > figuration and giving the PIC suitable instructions for what it should > do. So in effect you'd still have personality modules but they'd be simpler to create. I'm also debating whether or not the module should have the programming code or if the programming code should be downloaded into the programmer. > > The base unit would be more complicated than the one you described, but > would avoid redundancy in the personality modules [since they wouldn't > need to include actual circuitry in most cases, nor would they have to > include a ZIF socket]. > > How does that sound for a design? All in all it's an excellent idea. BAJ

John Payson wrote: > > 24-bits of bidirectional shift registers [wired as a group of 16 and a > > group of 8]. > > |Been thinking about that. I have a gut feeling that while more expensive > |that using PIC programmable pins would be more flexible. You'd get: > > |- Input/output/float > |- bit or byte selectible > |- high current source/sink > |- programmible timed pins > |- extra RAM. > > Unfortunately, there's one thing the PIC doesn't give you very well > (and I forgot to mention using some buffer chips even for the "direct" > I/O): the ability to match the VDD of the device-under-test when output- > ting a logic high (or, in some cases, reading it back!). To really do > things right, though, would require using 3-state buffer chips running > off the DUT's VDD. I have been sketching out a design for a USB connected universal in system programmer. Coming up with a universal driver / receiver seems to be the hardest part of such a design. The simplest method I have found is to use analog switches for the VDD, VPP and GND drivers and using a comparator for the receivers. However, the number of parts gets a little ugly. --------------------------------------------------------------------- | Dr. Kevin Dale Kirmse, PhD EE | Portable System Design, High Speed Serial Links | FPGA Design, Video Hardware, Graphics Hardware | | King of Prussia, PA 19406 | spam_OUTkirmseTakeThisOuTnetaxs.com ---------------------------------------------------------------------

{Quote hidden}> > > 24-bits of bidirectional shift registers [wired as a group of 16 and a > > group of 8]. > > |Been thinking about that. I have a gut feeling that while more expensive > |that using PIC programmable pins would be more flexible. You'd get: > > |- Input/output/float > |- bit or byte selectible > |- high current source/sink > |- programmible timed pins > |- extra RAM. > > Unfortunately, there's one thing the PIC doesn't give you very well > (and I forgot to mention using some buffer chips even for the "direct" > I/O): the ability to match the VDD of the device-under-test when output- > ting a logic high (or, in some cases, reading it back!). To really do > things right, though, would require using 3-state buffer chips running > off the DUT's VDD. > But that issue would be the same whether or not PIC I/O or discretes were used. Pointing that out though has opened my eyes to the real problems of production programming. I've been looking at this from a strictly hobby experimenter's point of view. BAJ

> Unfortunately, there's one thing the PIC doesn't give you very well > (and I forgot to mention using some buffer chips even for the "direct" > I/O): the ability to match the VDD of the device-under-test when output- > ting a logic high (or, in some cases, reading it back!). To really do > things right, though, would require using 3-state buffer chips running > off the DUT's VDD. > |But that issue would be the same whether or not PIC I/O or discretes were |used. |Pointing that out though has opened my eyes to the real problems of production |programming. I've been looking at this from a strictly hobby experimenter's |point of view. If you use discretes, you can run them off the DUT supply (or a supply whose voltage matches the DUT supply). Obviously you'd have to choose suitable parts, but that shouldn't be too hard. A couple alternative approaches which could be used for the slow- er changing signals would be: [1] Use (or emulate) open-collector outputs, and use pullups to the DUT's VDD (or a supply that matches it). [2] Use resistors between the output drivers and the DUT's pins, and clamp the DUT's VDD to the desired level. Neither of these approaches is terribly wonderful, but they should work.