Searching \ for 'PIC16C620 with 16C84 code...Possible options?' 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/devices.htm?key=16C
Search entire site for: 'PIC16C620 with 16C84 code...Possible options?'.

Truncated match.
PICList Thread
'PIC16C620 with 16C84 code...Possible options?'
1999\03\15@175123 by Graeme Smith

flavicon
face
GRAEME SMITH                         email: spam_OUTgrysmithTakeThisOuTspamfreenet.edmonton.ab.ca
YMCA Edmonton

Address has changed with little warning!
(I moved across the hall! :) )

Email will remain constant... at least for now.


On Mon, 15 Mar 1999, Jim Robertson wrote:

{Quote hidden}

Yah...

What worries me, is I have this pile of 27XX and 27XXX Eproms sitting in
storage, that I got for free, and it looks like I am going to have to
re-invent the programmer to program them, even though I already have a
PIC programmer with the right number of pins....

I wanted to buy the Universal Programmer, but couldn't afford it.

Somehow I get the feeling from this list, that parrallel Eprom interfacing
is a lost art... only for the truely uninitiated that don't understand ISP
I2C and Serial Eproms, or for the really rich people who can afford
production programmers.

Considering the Apple used to reconfigure 27XX parts with a simple jumper
block, it seems rather wasteful not to have the ability to use my
PicStart+ to program them.

Obviously, most of the really cheap programmers are aimed at the midrange
devices, which use a serial interface, but when you get above that level,
is there any reason you couldn't include Parrallel Eprom capability?

> >Just not wanting to reinvent the wheel.
> >
> >BAJ
>
> I would suggest my code for the picstart 16C will do the trick. You can burn
> your own '84 and then use it to drive the TAIT programmer.
>
> Jim
>
Just how cheaply could someone create a development programmer that does
universal programming of a numer of different types of chips... For
instance can they redesign a TAIT to program 8051's?

If say they had different firmware for different types of chips, we could
have a programmer for our base chip, and a library of "Driver Firmware"
that would allow us to "Program" the same chip to burn alternate chips.

If they used a "Break-out" type interface, we could probably even, select
the "Lines" that went to each pin, and have a quickly reconfigured
programmer suitable for hobby use.

Then the main problem would be getting someone to experiment with the
combination of connections and code, so they could guide the re-tooling
process with a proper manual.

Maybe all I really need, is an "Adapter" and some "Driver" software that
will tell the PICSTART+ how to program an eprom....(Other than Micro-Chips
serial types)

                               GREY

1999\03\15@194009 by Byron A Jeff

face picon face
{Quote hidden}

Well EPROMS are a bit of a different dance. Every single one has a different
set of pin placements, programming voltages, and programming algorithm. IIRC
from Steve Ciarcia's Intelligent EPROM programmer that at least 7 different
pins on a 28 pin socket requires variable voltages for programming.
>
> Somehow I get the feeling from this list, that parrallel Eprom interfacing
> is a lost art... only for the truely uninitiated that don't understand ISP
> I2C and Serial Eproms, or for the really rich people who can afford
> production programmers.

Well it kinda got replaced by the PICs here. I used to use EPROMs for
programming 68K parts, and 8031s. Since the PIC has it integrated, the use
for EPROMs standalone have diminished greatly, at least on my part.

I do have an upcoming use on my now infamous endless list of things to do. That
is programming Boot EPROMS to put into Ethernet cards for diskless Linux
workstations. I man who needs a disk when you can get 256M of ram for $300?

>
> Considering the Apple used to reconfigure 27XX parts with a simple jumper
> block, it seems rather wasteful not to have the ability to use my
> PicStart+ to program them.

It's a big retarget IMHO. The PICSTART would have a much greater complexity
(and cost) if it targeted EPROMS too.

>
> Obviously, most of the really cheap programmers are aimed at the midrange
> devices, which use a serial interface, but when you get above that level,
> is there any reason you couldn't include Parrallel Eprom capability?

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.

{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.

So for example  the 8751 card would have all the elements required to program
it. The base unit would read the programming algorithm from the EEPROM, read
the program information from the PC interface, and use whatever extra circuitry
was to the card to program the part.

So you'd end up with a hybrid between a specialized programmer and a universal
one. Everyone would build the base unit, then folks could design and build
extension cards as necessary. So instead of having to try to shove all the
circuitry and code required to program everything into a single unit, one
could customize with the cards they needed. And of course we could share
card schematics and EEPROM code.

The base unit probably needs to be little more than a big PIC with a simple
interpreter that runs the EEPROM code, a serial interface to the PC, a
programmable voltage source, and an expansion card interface that sends
20-24 pins, power, and a serial EEPROM interface to an edge card connector.

>
> If they used a "Break-out" type interface, we could probably even, select
> the "Lines" that went to each pin, and have a quickly reconfigured
> programmer suitable for hobby use.

Still a bit much on the complexity front, but along the same lines.

>
> Then the main problem would be getting someone to experiment with the
> combination of connections and code, so they could guide the re-tooling
> process with a proper manual.
>
> Maybe all I really need, is an "Adapter" and some "Driver" software that
> will tell the PICSTART+ how to program an eprom....(Other than Micro-Chips
> serial types)

Yes but by the time you get done, you've built another programmer.

Just some thoughts. Again this is on my list of things to do.

BAJ
>
>                                 GREY
>

1999\03\15@200738 by Alan King

picon face
> > If say they had different firmware for different types of chips, we could
> > have a programmer for our base chip, and a library of "Driver Firmware"
> > that would allow us to "Program" the same chip to burn alternate chips.
>
> 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:


 Or better yet, come up with a way to make fitting all possible chips
into one socket simple instead of complex.  I have and am working on it,
just need some 877's to move the development along.  Look at the Top/Max
programmer in the back of CCInk.  It is what I envision doing for
$250ish street price..  They're making a killing at $999, but of course
they're a much larger company with people to pay, and I'm going to be
doing it as a one man project with less overhead..  That's why their's
is ready now and mine still a few months away..
Alan

1999\03\16@095743 by Byron A Jeff

face picon face
{Quote hidden}

There's no way to make fitting everything into a single socket simple. Between
EPROMS, PICS, 805X, GALs, PALs, FPGA and the myraid other types of programable
devices that a Universal Programmer has to program you literally end up with a
programmable voltage per pin situation, plus shoving all of the programming
code into the box, unless you download the code from the PC. This is where
the cost comes from.

Personally I don't want to have to pay hundreds of bucks for a programmer that
programs devices I never intend to use. With the modular approach you only
build extension cards for the devices you actually plan to program.

Just my thought on the subject.

BAJ

1999\03\17@123231 by John Payson

flavicon
face
|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).

|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].
 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.

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?


Attachment converted: wonderland:WINMAIL.DAT (????/----) (0002C6B6)

1999\03\17@214646 by Graeme Smith

flavicon
face
GRAEME SMITH                         email: grysmithspamKILLspamfreenet.edmonton.ab.ca
YMCA Edmonton

Address has changed with little warning!
(I moved across the hall! :) )

Email will remain constant... at least for now.


On Wed, 17 Mar 1999, John Payson wrote:

> 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.

Or some alternative....
>
> 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).
>
Obviously the 17c56 has a "Feature"

{Quote hidden}

An alternative... would be to wire one side of each of the 40 pin sockets
to the Zif Socket, and the other side to your selection of signal wires,
so you can essentially create a Plug-in out of a different type of socket
glued to a stiffener of some sort, so the "Personality Module" was simply
the arrangement of wires between the two "Mappings" of signals. You would
simply build one 80 pin "Personality module" for each different type of
chip.

Software wise, you would probably be able to do a similar profile
describing which signals you needed to be able to sample.

The difference between one device and another, would be reduced to setting
the voltage for Vpp Vcc, etc, and selecting the right hardware to go with
the right software profile.

If you had a bench supply, you could wire the VPP to the bench supply,
and dial it according to the VERSION of the chip. (Lots of these chips had
actual voltage levels printed as part of the packaging print job.
>
> 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].

This would also cut the cost somewhat.
>
> How does that sound for a design?
>
I think it's a good start....

but could you explain about the serial shift registers?

I am afraid I didn't figure that part out, quite yet.

Are they for triggering the "Address" bus?

                               GREY

1999\03\25@163941 by John Payson

flavicon
face
> 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).

|Obviously the 17c56 has a "Feature"

Right, but since the 17C42 is running code from ROM at boot time
it would have been trivial to use serial programming.  No extra
transistors required--just different code in the mask ROM.

>   24-bits of bidirectional shift registers [wired as a group of 16 and a
>     group of 8].

|An alternative... would be to wire one side of each of the 40 pin sockets
|to the Zif Socket, and the other side to your selection of signal wires,
|so you can essentially create a Plug-in out of a different type of socket
|glued to a stiffener of some sort, so the "Personality Module" was simply
|the arrangement of wires between the two "Mappings" of signals. You would
|simply build one 80 pin "Personality module" for each different type of
|chip.

That would be precisely the idea.  Thinking about it, though, it might
be easiest to have the center two columns of pins go to the ZIF and the
outer two be programmable (or vice versa); this would allow any signal
to be routed anywhere going "through" at most one column of pins.

|Software wise, you would probably be able to do a similar profile
|describing which signals you needed to be able to sample.

|The difference between one device and another, would be reduced to setting
|the voltage for Vpp Vcc, etc, and selecting the right hardware to go with
|the right software profile.

Yup.  Though I was just thinking it might be useful to have a few pins
going to the programming hardware whose purpose would be to identify
which "personality module" was installed; that way the programmer could
complain rather than frying chips.

|If you had a bench supply, you could wire the VPP to the bench supply,
|and dial it according to the VERSION of the chip. (Lots of these chips had
|actual voltage levels printed as part of the packaging print job.

A useful option, though needing to find a bench supply when you want to
burn a chip is a pain.

> How does that sound for a design?
>
|I think it's a good start....

|but could you explain about the serial shift registers?

|I am afraid I didn't figure that part out, quite yet.

|Are they for triggering the "Address" bus?

Yeah, basically.  The problem is that since the PIC can't drive the
programmer's pins directly (since the PIC's VDD may not match that of
the device being programmed) it's necessary to have some sort of hard-
ware between the PIC and the DUT.  For some of the control signals that
have to change quickly, it would be good for the PIC to have immediate
control, but for address/data pins the response doesn't have to be so
fast.  In addition, while some pins may have to serve as inputs and out-
pins in "wierd" combinations, the address and data busses may always be
switched "as a unit".

Perhaps it would be better to use 75HC373's or equivalent instead of
shift registers, but the important thing is that there are some pins the
PIC controlls 'quickly' and there are others where its response is slow-
er.

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