Searching \ for 'The MIPI concept (was PIC programmers)' 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=programmer
Search entire site for: 'The MIPI concept (was PIC programmers)'.

Truncated match.
PICList Thread
'The MIPI concept (was PIC programmers)'
1995\08\31@133853 by David Tait

flavicon
face
Hi Siegfried,

> That is another point to discuss. The data book says, MCLR must be at least
> 0.85*Vdd ...

Thanks for your critique of the circuit I posted.  As I said in private
e-mail to you, I should have read your demands more carefully - I assume
that VDD is 5V.  I agree that with a 10k pull-down I can't quite meet the
0.85*VDD spec of the 16C84 even with a 5V supply (I see the spec is
a little different for other 16CXX chips).  The solution is simply to
increase the value of the pull-down (or even leave it out altogether
I suppose, but my experience tells me it's a good thing).  Having said all
that, the circuit works just fine as it is with VDD = 5V.

> THREE outputs with RS232???
> I only know of RTS and DTR. Or do you abuse the TxD line like the Erik-
> Hermann-ultracheap-RS232-programmer?

Sorry for the confusion, but the circuit is driven by a _parallel_
port.  I derive the parallel signals from the RS232 port using a few
CMOS chips; I call this interface a MIPI (for Machine Independent
Parallel Interface).  The MIPI is designed to work with any computer
with an RS232 port.  It is my answer to the problem of bootstrapping a
PIC based universal PIC programmer without needing a PIC programmer in
the first place.  Perhaps you will forgive me if I use my reply to your
question to see if I can explain the idea to any members of the PICLIST
who are still reading (non hobbyists and owners of store bought
programmers will have skipped to the next message before they reached
here :-)

I would contend that Robin Abbott's ETI design is a machine independent
universal PIC programmer.  Universal in the sense that it can be used
to program all the PIC chips.  Machine independent in the sense that
it is connected to the host computer via the RS232 port and virtually every
computer has an RS232 port.  Provided you forgo a flashy graphical interface
it should be possible to write host software that is highly portable
between different platforms.  The only gripe is the one expressed by
Ray Bellis and others, that is, you need access to an existing PIC
programmer to make Robin's design (or have to pay Robin to get your
PIC programmed).

My aim is to design a machine independent (i.e. RS232 hosted) universal
PIC programmer without this chicken and egg problem.  The programmer
hardware will still use a PIC (one of the serial-programmable 16CXX
chips) for simplicity.  Then, if you have an IBM clone, there is no
problem in bootstrapping the project by building a simple programmer
and using the Silicon Studio software by Antti Lukats and his team.  In
fact, if you have an IBM clone this might be all you want anyway.  So
let's consider people without IBM clones but who do own computers with
an RS232 port.  That is, they could make use of the programmer if they
could build it, but they can't build it because they have no means of
burning the PIC used in the programmer (and they, like me, are too cheap
to have someone else program the PIC :-)

I guess some people could get Erik Hermann's RS232 based programmer going
on their non-IBM machine.  Here we stray into a grey area; Erik's programmer
makes unconventional use of the RS232 signals and though it should work well
with an IBM clone, it's not necessarily easy to fiddle with the modem lines
on all computers.  So, let's say the RS232 port has minimum functionality:
GND, TXD and RXD (that's all that Robin's programmer needs by the way).

With such a restriction we have no option but to throw some hardware at
the problem.  In fact the hardware is likely to be more complex than the
programmer we want to build.  It would seem like a waste to build a
complicated bit of kit that was going to be redundant after it has been
used just once.  Well, I thought an RS232 hosted parallel port might be
a nice toy to have: it could be used to hook up a simple PIC programmer
to bootstrap the PIC based version, but it would still be useful for other
projects.  That was the birth of the MIPI.

The MIPI consists of a few cheap CMOS chips and provides three parallel
outputs and four parallel inputs; a very modest amount of I/O I know,
but that's more than enough to bit-bang SPI/I2C protocols (albeit slowly)
using the RS232 port of any computer.  The outputs are available as
both true and inverted logic signals (5V CMOS) and also in open drain
form.  It is these signals that should be used to drive the in-circuit
programmer I described in the previous message.  The MIPI can be built
in two forms.  For maximum machine independence the RS232 interface is
built using a MAX232 and power is supplied externally.  If DTR/RTS are
available the MIPI can be powered from the RS232 port itself.

I have a document (still unfinished because of pressure of work) which gives
a full description of the MIPI design and implementation.  If anybody really
wants a copy just ask and I'll send you a draft (all the schematics are in
ASCII so you don't need any special facilities to view them; it took me
longer to draw these than to build the hardware!).  If you can wait a bit,
I should be able to complete the specification of the machine dependent
library routines needed to make MIPI applications machine independent (I'm
unhappy with the specification in the current draft and that's the reason
the document is still unfinished).  In any case you might be able to get a
good idea of what's involved by looking at the block diagram I've included
at the end of this message.

Back to my reply to Siggi.  Feel free to modify my software for your
own programmer design, but you might be more interested in further
modifying a version that was put together by Frederic Rible.  It's
called PP10.ZIP and it's on the Microchip BBS and also on the Silicon
Studio FTP site.  Or, as Don McKenzie has already said, just show Antti
your design and he will have a PC driver ready quicker than you can blink!

Sorry for the long waffle, but I hope some found it interesting enough
to make it all the way to here.

Cheers,

David
--
spam_OUTdavid.taitTakeThisOuTspamman.ac.uk


                   Machine Independent Parallel Interface
                   ======================================

                       Copyright (C) 1995 David Tait

                           +---------------------------+
                           |                           |
         +----------+      |    +--------+         +--------+
  TXD    |  RS232   | SIN  |    |  MONO  | /M2     | RESET  | RST
   >-----|   I/F    |------+----|  1/2   |---------| 1/2    |-------+
         |          |      |    |  4098  |         | 4013   |       |
  RXD    |  MAX232  | SOUT |    +--------+         +--------+       |
   <-----|    OR    |--+   |                                        |
         | DISCRETE |  |   |    +--------+         +-----------+    |
         +----------+  |   |    |  MONO  | /M1     | CLOCK GEN |    |
                       |   +----|  1/2   |---+-----|           |----+
DTR/RTS  +----------+  |   |    |  4098  |   |     |   4027    |
   >-----|  POWER   |  |   |    +--------+   |     +-----------+
         | 78L05 OR |  |   |                 |       |   |   |
   >-----| DISCRETE |  |   |   +-------------+  CLK2 |   |   |CLK0
  VIN    +----------+  |   |   |  +------------------+   |   |
              |        |   |   |  |  +---------------|---+   |
              | VDD    |   |   |  |  |        CLK1   |   |   |
              +-->     |   |   |  |  |               |   |   |
                     +-----------------+           +------------+
           DIN0 >----|    INPUT MUX    |           | DATA LATCH |---> DOUT0
           DIN1 >----|                 |           |   1-1/2    |---> DOUT1
           DIN2 >----|      4512       |           |   4013     |---> DOUT2
           DIN3 >----|                 |           +------------+
                     +-----------------+


      Parts: 4098 (or 4528), 4027, 2 X 4013, 4512, 3 X VN10KM.
             (plus either: MAX232, 78L05; or 2 X BC547, BC550, TL071.)


'The MIPI concept (was PIC programmers)'
1995\09\01@050432 by Erik Hermann
flavicon
face
>                    Machine Independent Parallel Interface
>                    ======================================

Looks interesting.
But too much parts. :-)

What about using a Basic Stamp for the serial interface ?
A single 16C56 with PBasic should be even cheaper than this graveyard of
CMOS chips. ;-)
(Nothing against Your design, it is interesting, though).

Ok, everyone should be able to get these parts.
That is the main advantage.

Regards
  Erik

1995\09\01@072232 by Byron A Jeff

flavicon
picon face
>
> >                    Machine Independent Parallel Interface
> >                    ======================================
>
> Looks interesting.
> But too much parts. :-)
>
> What about using a Basic Stamp for the serial interface ?
> A single 16C56 with PBasic should be even cheaper than this graveyard of
> CMOS chips. ;-)
> (Nothing against Your design, it is interesting, though).
>
> Ok, everyone should be able to get these parts.
> That is the main advantage.

No the main advantage is that it doesn't require $30 in parts plus
development system to use. You have to get PBasic on that 16C56.
You have to program that Stamp. If you're starting with nothing it
requires quite of bit of investment to do what you're proposing.
This design is especially geared to non PC machine because PC machines
have a parallel port. This is a synthetic parallel port.

David's key point is trying to break the chicken and egg cycle of having
to have something programmed (which both of your suggestions are) in
order to build the programmer across machine environments.

It does take a few parts. But you build it once and you have a couple
of controllable ports of IO that you can do stuff with. Like program
PICS, program seral EEPROMS, monitor a couple of bits of I/O in a circuit,
data logging among other things. And it's with cheap and available hardware.
And it works on any platform that has serial I/O - and every computer
known to man at least the size of a subnotebook has serial I/O.

A programmed PIC can do the job. I even have a set of routines that
theoretcally can do 38400 simplex using a 20 Mhz 16CXX PIC. But you
have to program it. If you don't have a PC available this becomes a
difficult proposisition. David's proposal makes it easier to make the
transistion from nothing to something without having to pay out the
nose for something already programmed.

I quote from the original message my comments in [brackets]:

I would contend that Robin Abbott's ETI design is a machine independent
universal PIC programmer....  The only gripe is the one expressed by
Ray Bellis and others, that is, you need access to an existing PIC
programmer to make Robin's design (or have to pay Robin to get your
PIC programmed).

My aim is to design a machine independent (i.e. RS232 hosted) universal
PIC programmer without this chicken and egg problem.
The programmer
hardware will still use a PIC (one of the serial-programmable 16CXX
chips) for simplicity.  Then, if you have an IBM clone, there is no
problem in bootstrapping the project by building a simple programmer
and using the Silicon Studio software by Antti Lukats and his team.  In
fact, if you have an IBM clone this might be all you want anyway.  So
let's consider people without IBM clones but who do own computers with
an RS232 port.  That is, they could make use of the programmer if they
could build it, but they can't build it because they have no means of
burning the PIC used in the programmer (and they, like me, are too cheap
to have someone else program the PIC :-)

I guess some people could get Erik Hermann's RS232 based programmer going
on their non-IBM machine.  Here we stray into a grey area; Erik's programmer
makes unconventional use of the RS232 signals and though it should work well
with an IBM clone, it's not necessarily easy to fiddle with the modem lines
on all computers.  So, let's say the RS232 port has minimum functionality:
GND, TXD and RXD (that's all that Robin's programmer needs by the way).

With such a restriction we have no option but to throw some hardware at
the problem.  In fact the hardware is likely to be more complex than the
programmer we want to build.  It would seem like a waste to build a
complicated bit of kit that was going to be redundant after it has been
used just once.  Well, I thought an RS232 hosted parallel port might be
a nice toy to have: it could be used to hook up a simple PIC programmer
to bootstrap the PIC based version, but it would still be useful for other
projects.  That was the birth of the MIPI.

--------

What I get from this explaination is that David is trying exactly to
avoid what you proposed. I thought that what I read the first time.

Simply put having a box that gives you a few inputs and output that can
be controlled from the serial like is a Good Thing (tm). And not requiring
a $130 development kit to do it is even better.

BAJ

1995\09\01@074342 by David Tait

flavicon
face
Hi Erik,

> Ok, everyone should be able to get these parts.
> That is the main advantage.

Yes, that's the whole point.  Given a PIC programmer here's how I'd do
it:


                     +----------+      +----------+
              TXD    |          |      |          |
               >-----|          |------|          |======>
                     |  RS232   |      |   PIC    |        Parallel
              RXD    |INTERFACE |      |          |          I/O
               <-----|          |------|          |<======
                     |          |      |          |
                     +----------+      +----------+


In fact there was a design for such a thing in a recent edition of
Electronics World and Wireless World.  The EW&WW article had the
inevitable "The author sells pre-programmed PICs for this project".

Of course, I _do_ have a PIC programmer so I could build something like
the above, but the aim was to make PIC programming accessible to all.
My yardstick is the Sun Sparcstation ELC I'm typing this on; I have used
the MIPI to program 16C84s on this machine, but it took ages.  I run the
serial link at 9600 bps for one thing (the MIPI will work to 115,200 bps
and beyond, but I wanted to get a feel for what's possible at low
speed); the real problem is that I do character at a time I/O.  I
couldn't believe how inefficient this is on the Sun.  Doing the same
thing on a PC using bios calls for I/O was many times quicker.  At
present I'm re-writing the low level MIPI driver to permit buffered
I/O but I want this to be invisible to MIPI application software.

Your idea of using a STAMP is good, but I doubt if it's cheaper than my
"CMOS graveyard".  As for parts count, I think I'm just a bit more
conservative than you.  Anyway, thanks for your interest, for that you
win a copy of my draft MIPI description :-)

Cheers,

David
--
.....david.taitKILLspamspam@spam@man.ac.uk

1995\09\01@143020 by David Harmon
picon face
On Fri, 1 Sep 1995, Erik Hermann wrote:
> Let's start a competition. Build the cheapest and easiest RS232-to-parallel
> converter and win a free PICLIST membership ;-)

Many years ago, I saw an application specific IC for this job.  It was
called a "UART".  Maybe something similar still exists?  ;-)

1995\09\01@163140 by Henry Carl Ott

picon face
David Tait writes:
{Quote hidden}

David,

I can't help thinking that the above design is much simpler (from a
hardware viewpoint) than the discrete CMOS design. I can understand the
desire to support people without pic programmers, but I think a lot of us do
have the capacity.

Would it be possible to make the two circuits interchangeable? Write some
pic code to emulate the discrete implementation, then one would just build
whichever interface one had the capacity for. Also, I'm sure that most
people (at least on this list) would have little problem obtaining a
pre-programmed mipi chip for anything more then $3.00 (assuming a 16c54 and
a kind hearted list member).

I do know I would much rather lay out a circuit board for a pic/max232
design then the (admittedly) small handful of cmos chips in the discrete
mipi design.

Just my .02
carl

----------------------------------------
Henry Carl Ott      N2RVQ
carlottspamKILLspaminterport.net
http://www.interport.net/~carlott/
----------------------------------------

1995\09\01@171408 by David Tait

flavicon
face
>
> Many years ago, I saw an application specific IC for this job.  It was
> called a "UART".  Maybe something similar still exists?  ;-)
>
Thanks for that.  Of course you are absolutely right.  However about
the only non-MPU interface UART around these days is the 40-pin 6402.
Like all UARTs it needs a clock generator; and it also needs a bit of
glue logic to play the games I want it to.  All in all a UART based
design was marginally less attractive than a bunch of CMOS chips
which cost cents rather than dollars.  Thanks for the sanity check
all the same.

David
--
.....david.taitKILLspamspam.....man.ac.uk

1995\09\01@180509 by David Tait

flavicon
face
Carl Ott wrote:

>  I do know I would much rather lay out a circuit board for a pic/max232
> design then the (admittedly) small handful of cmos chips in the discrete
> mipi design.

Carl,

If you can get hold of the copies of ETI with Robin Abbott's PIC programmer
design you don't even need to lay-out the circuit board because it's been
done for you.  As I said in an earlier post, if you have access to a PIC
programmer then Robin's design is what you want (the Hex dump of the PIC
code is on the Silicon Studio site, and the required dialogue between host
software and programmer is published in ETI); forget all this MIPI rubbish,
it's not for you.

I must admit I'm talking to the wrong audience here on the PICLIST.  Perhaps
there is no audience at all, but I thought there might be some hobbyist
somewhere in the world who doesn't own an IBM clone (has a Mac say), and who
doesn't mind chucking a few CMOS chips on a bit of stripboard to get a
PIC programmer for his/her trouble.

Your idea of designing the PIC based programmer so that the PIC can be
emulated by the MIPI (and vice-versa) is definately worth considering.
Also bear in mind that the MIPI is only to bootstrap the programmer so
when (perhaps if) I get around to writing the PIC code for the final
project you will be able to use that code straight away if you already
have a PIC programmer (or have one at work or whatever).  Anyway, thank
you for your interest and comments.

Cheers,

David (also a ham by the way - G0JVY).
--
EraseMEdavid.taitspam_OUTspamTakeThisOuTman.ac.uk

1995\09\01@190016 by William Chops Westfield

face picon face
   > Let's start a competition. Build the cheapest and easiest
   > RS232-to-parallel converter and win a free PICLIST membership ;-)

   Many years ago, I saw an application specific IC for this job.  It was
   called a "UART".  Maybe something similar still exists?  ;-)

Building a serial to parallel printer converter is trivial.  But things like
stamp programmers use the parallel port in random ways (ie stamp programmer
different than PIC programmer different than xxx) as an externally visible
bit array.  Creating a port capable of doing this in a general fashion,
while maintaining the ability to control timing of the bit-twiddling to
a very fine degree (which is probably why the parallel port was used in
the first place) is going to be a difficult task.  (How fine does the
timing need to be?  You can probably get down to about 1mS accuracy without
many problems, but getting to 10uS is likely impossible...)

BillW

1995\09\01@192611 by John Payson

flavicon
face
> My aim is to design a machine independent (i.e. RS232 hosted) universal
> PIC programmer without this chicken and egg problem.  The programmer
> hardware will still use a PIC (one of the serial-programmable 16CXX
> chips) for simplicity.  Then, if you have an IBM clone, there is no
> problem in bootstrapping the project by building a simple programmer
> and using the Silicon Studio software by Antti Lukats and his team.  In
> fact, if you have an IBM clone this might be all you want anyway.  So
> let's consider people without IBM clones but who do own computers with
> an RS232 port.  That is, they could make use of the programmer if they
> could build it, but they can't build it because they have no means of
> burning the PIC used in the programmer (and they, like me, are too cheap
> to have someone else program the PIC :-)

How's this for a design?  [Just sketched this on the "back of an envelope";
untested--does anyone think it will work?]

Components:
 RS232 plug [signals called RxD and TxD]
 Quad-NOR gate [signal pins called N1a, N1b, N1y, N2a, N2b, N2y, etc.]
 555 timer with R/C [wired as 50us monostable; signals called Trig and
   TOut]
 Input current-limitting resistor to prevent RS232 voltage from popping
   the quad-NOR gate; wires called R1a and R1b
 Another resistor to minimize contention with the PIC during read cycles.
   [R2a, R2b]
 The PIC [Pclk, Pdat]

Recipe:
 Power and grounds as "normal"
 RxD -> R1a
 R1b -> N1a, N1b
 N1y -> Trig, N2a, N2b, N4a
TOut -> Pclk, N3a
 N2y -> R2a
 R2b -> Pdat, N3b
 N3y -> N4b
 N4b -> TxD

Check the timer to ensure that it is JUST OVER one bit time at 19.2KBaud.
If the timeout is much over one bit time, or is under at all, the programmer
will fail.

Sending a single low bit [e.g. a start bit followed by an FF] will write a
0 bit to the pic; sending two [or more] will write a 1.  To read the PIC,
send two [or more] consecutive 0's: if only one comes back, the PIC is
reading a zero; if both come back, it's reading a one.

To be more specific about operation, a 0 bit will trigger the 555 and will
also appear on the PIC's serial data line.  If it only lasts a single bit
time, however, it will be gone by the time the 555 times out [giving the PIC
a falling edge on its clock line] whereas if it lasts longer, the clock line
will fall first.  For reading, each output pulse will be at most as long as
the input pulse, and if the PIC is reading a zero, it will only last the 555
time.

To get decent speed, each byte may be used to send 3 bits of data; to send
the bits a', b' and c' [inverted], for example, you should send "1a01 b01c"
[note: while data is written MSB first, it's sent LSB first, and preceded by
a start bit].  While the programming pulses resulting from this system may
be a little long they should still be okay.

Well, what do you think?  Do you understand it?

1995\09\02@133213 by David Harmon

picon face
I wrote: UART ;-)

David Tait wrote:
> about the only non-MPU interface UART around these days is the 40-pin
> 6402.  Like all UARTs it needs a clock generator; and it also needs a bit
> of glue logic to play the games I want it to.

I hope I'm not conflating two threads here: the serial port driven
programmer and the PIC expander.  I would not suggest a UART for the
latter, where you can use a data pin and clock pin and shift the bits out
in any format you want.  But for the general case of a serial port, you
may not have any extra pins to play with and you may not have close
control over the character timing.

If you really want to build a programmer that can be used on a generic
serial port with pins 2, 3, and 7, like say on a UNIX box, I think it has
to have a baud rate generator, the functionality of a UART, and plenty of
glue.  I would be delighted to learn that's not true.

William Chops Westfield wrote:
> Creating a port capable of doing this in a general fashion, while
> maintaining the ability to control timing of the bit-twiddling to a very
> fine degree (which is probably why the parallel port was used in the first
> place) is going to be a difficult task.

Yep.  I would expect that things like the timing of a program pulse would
have to be done with a one-shot or something.  And you might still need
the CMOS shift register on the UART outputs to expand to the number of
bits you need.  And yes, a non-MPU-buss UART is probably 40 pins.

Maybe this is all much more complicated than what you wanted to build.
If so, chalk it up to the ramblings of a software weenie.  BTW, I'm
perfectly happy with bit twiddling on a PC parallel port; it's just the
opposite of "universal" though.

1995\09\03@022642 by Kalle Pihlajasaari

flavicon
face
> Yep.  I would expect that things like the timing of a program pulse would
> have to be done with a one-shot or something.  And you might still need
> the CMOS shift register on the UART outputs to expand to the number of
> bits you need.  And yes, a non-MPU-buss UART is probably 40 pins.

Standard Microsystems Corporation (SMC) were selling a 20 PIN UART
that regrettably needs a processor, one data and handshake each way
with internal baud rate generator.

20 Pin PLCC and DIP

Part number COM81C17

They might have a small pin programmable UART one though.
Year old contact details, Hauppage NY, (516) 273-3100

Cheers
--
Kalle Pihlajasaari     kallespamspam_OUTdata.co.za        ( soon @spam@kalleKILLspamspamip.co.za )
Interface Products     Box 15775, Doornfontein, 2028, South Africa
+27 (11) 402-7750      Fax: +27 (11) 402-7751  ( soon 402-7723 )

1995\09\04@052033 by David Tait

flavicon
face
John Payson wrote:

> How's this for a design?  [Just sketched this on the "back of an envelope";
> untested--does anyone think it will work?]

    ... [much deleted] ...

This sounds very similar to my original ideas on how to tackle the
problem.   I'm pretty sure that something along the lines you describe
will work just fine.  My design was a bit more complicated and in the
end I abandoned it in favour of the MIPI circuit; the argument being
that the MIPI would still be useful even after bootstrapping the PIC
programmer but dedicated bootstrapping hardware would probably be
redundant after it had served its purpose.  The argument would be less
persuasive if the hardware could be made very simple so I would like
to encourage you to work your ideas into a prototype and let us all
know the results.

David
--
KILLspamdavid.taitKILLspamspamman.ac.uk

1995\09\04@062707 by David Tait

flavicon
face
David Harmon wrote:
> If you really want to build a programmer that can be used on a generic
> serial port with pins 2, 3, and 7, like say on a UNIX box, I think it has
> to have a baud rate generator, the functionality of a UART, and plenty of
> glue.  I would be delighted to learn that's not true.

David,

Although I could argue about the need for a baud rate generator (I use
a monostable to recover timing) I don't think that I can really refute
what you say.  If I wanted an RS232 hosted 8-bit bi-directional parallel
port I would use a UART without question.  I didn't; I wanted a simple
interface to bit-bang SPI/I2C using the serial port.  That's enough
functionality to program the 16C84 at least.  I admit the circuit I came
up with is not so very simple, but it is probably no more complex than
a UART based design.  Furthermore it has the advantages of smaller size
(it doesn't use a 40-pin chip), lower cost and can be powered directly
from the RS232 port in many cases.  I also admit it could be done
better by a micro-controller but that defeats my main objective.
I will even admit that the name Machine Independent Parallel Interface
is probably over the top for such a modest thing.

If you (or anybody else for that matter) is interested I can e-mail a
copy of my circuit and description and you would then be in a better
position to judge if the idea has any merit at all.

You quoted William Chops Westfield:
> > Creating a port capable of doing this in a general fashion, while
> > maintaining the ability to control timing of the bit-twiddling to a very
> > fine degree (which is probably why the parallel port was used in the first
> > place) is going to be a difficult task.
and wrote:
> Yep.  I would expect that things like the timing of a program pulse would
> have to be done with a one-shot or something.

One of the things I really like about the PIC16C84 is the fact that the
programming operation is self-timed (though you have to make sure you
don't ask it to program another location until 10ms or so has elapsed).
So I see a 16C84 as being the heart of my universal PIC programmer.  The
downside is that the 16C84 doesn't have enough I/O to program the 16C5X
PICs without the addition of some glue.  I guess that I could get the
complexity of the final programmer down to a bare minimum by a two-step
boostrapping process: use MIPI to program 'C84; use 'C84 to program 'C64
(say); use 'C64 in final design.  I think this is taking things a bit
too far.

As I said in one of my (too frequent) recent posts, I don't see members of
the PICLIST as being the primary audience for this project, so perhaps
I should tout my wares elsewhere.  Thanks to you and everyone else who
has contributed to the discussion.

David
--
RemoveMEdavid.taitTakeThisOuTspamman.ac.uk

1995\09\04@102701 by Walter.Anderson

flavicon
face
> downside is that the 16C84 doesn't have enough I/O to program the 16C5X
With the  addition of the 16C61 and soon the 16C62 to the mid-range
line, there doesn''t seem to be much need for a 5X programmer.  The
61 is not much more expensive then a 54, but provides all of the
benefits of the midrange (interrupts, 8-level stack, etc).  In short,
just stick to serial programmed pics is not a real problem for the
probably target audience.

Walter
------------------------------------------------------------
Walter Anderson, CCP          email: spamBeGonewandrsonspamBeGonespamonramp.net
2500 Guerrero, #221           callsign: KD4KIL
Carrollton, Texas 75006       url: <in progress>
------------------------------------------------------------

1995\09\04@102905 by Roger Books

flavicon
face
Actually, if the MIPI stuff could be made simple enough to breadboard the
reusability arguement kind of goes away.  Most people who would be interested
in doing PIC projects own a breadboard.  So, I breadboard it, burn my initial
pic, take it apart, and build the real programmer.  So I have a few extra
parts left over at the end.

Roger

1995\09\04@130612 by David Tait

flavicon
face
OK.  Putting the ideas from Walter Anderson, Carl Ott and Roger Books
together we have a 16CXX-only programmer, that initially uses a circuit
to emulate the controller PIC, but a circuit which is simple enough to
be "breadboardable" and disposible.  If we follow this line of thought
for a bit we see that the RS232 interface and the few transistors that
are needed to control MCLR can be built as part of a skeleton final
programmer (let's not bother trying to switch VDD, though we can provide
+5V for programming PICs that are not already in circuit).  We get
something like this:

            +----------+      +----------+      +----------+
     TXD    |          |      |          |      |          |
      >-----|          |------|  EMPTY   |------|  THREE   |------> MCLR
            |  RS232   |      |  18-PIN  |      |TRANSISTOR|------> VDD
     RXD    |INTERFACE |      |  SOCKET  |------|   ISP    |------> RB6
      <-----|          |------|          |------| CIRCUIT  |------> RB7
            |          |      |          |      |          |
            +----------+      +----------+      +----------+

The "PIC emulator" (i.e. something like my MIPI circuit) is connected
to an 18-pin header and (perhaps using a special version of the
final host processor software) used to burn a 16C84.  The PIC
emulator is thrown in the bin and replaced by the 16C84 and we
have the final programmer (not universal anymore, but perhaps Walter's
argument has convinced you that the 16C5X series are not likely
to be used in new designs).

Fine, the MIPI circuit uses 5 CMOS chips and 3 VMOS transistors.  I
think I could reduce the count by 1 chip.  I guess somebody, Erik?
will be able to reduce the chip count even more.  Any takers?

David
--
TakeThisOuTdavid.taitEraseMEspamspam_OUTman.ac.uk

1995\09\04@154523 by John Payson

flavicon
face
> Fine, the MIPI circuit uses 5 CMOS chips and 3 VMOS transistors.  I
> think I could reduce the count by 1 chip.  I guess somebody, Erik?
> will be able to reduce the chip count even more.  Any takers?

For doing "blind" programming of an '84 ["blind" meaning the host can't
tell anything about what the PIC is doing, or even its existence] I think
the simplest possible circuit is two resistors and a cap [plus the power
supplies].

R1 should be about 10K or so and should connect the PIC programming clock to
TxD.  R2 should be a 10K POT between the PIC programming data and TxD.  The
cap should be about 0.1uF or so and should connect the pgm data line to ground.
To send a "1" bit, send 00h; to send a "0" bit, send FFh.

How does that sound for simplicity?

1995\09\04@165525 by Kalle Pihlajasaari

flavicon
face
> > will be able to reduce the chip count even more.  Any takers?
>
> For doing "blind" programming of an '84 ["blind" meaning the host can't
> tell anything about what the PIC is doing, or even its existence] I think
> the simplest possible circuit is two resistors and a cap [plus the power
> supplies].
Radical design reduction, better than the 3 pin serial programmer for
one off designs.

> To send a "1" bit, send 00h; to send a "0" bit, send FFh.
At what baud rate ?-)

> How does that sound for simplicity?
Wonderful, if the program does not work the first time, just try again
until the test program communicats with the pc serial ports to test
the one wire programmer then do one more blind program to burn in the
programmer code.
--
Kalle Pihlajasaari     RemoveMEkallespamTakeThisOuTdata.co.za

1995\09\04@233629 by Roger Books

flavicon
face
One last thing, is the 16c84 the appropriate chip for this?  I realize the
EEPROM is nice, but it does add significantly to the cost of what should end
up being a one shot deal.  Of course, I guess if you socket the 16c84 then
you can burn an OTP and yank out the 84 if you feel it necessary.

Roger (Looking forward to trying this on my Sparc I, even though I do have a PC)

1995\09\05@075408 by Scott Stephens

flavicon
face
This is a challanging project. My solution would be to trade the price for
two C84's, which would both be programmed by the host serial port. One C84
would be the master, the other a slave port. Maybe a couple ports could be
used as charge pumps for a 13V programming source. They could handle serial
and paralled devices, bi-directional communication, tri-state leads (exept
for a bjt on MCLR.

1995\09\05@101633 by Don McKenzie

flavicon
face
As Danny Da-Vitto says: OK-OK-OK-OK-OK-OK!!

I couldn't help myself. Everybody has a different idea. There are no
correct answers and possibly no prizes.

This is what I visualize as a possible answer to David's MIPI concept:

It is not a definitive design down to component level, it's a concept.

RS-232 to TTL conversion isn't used or required.

Power supply, I'll ignore at this stage only to fend off controversy,
however it should be noted that this device must program all devices in
the MicroChip "Serial" arsenal. It is assumed that only "Serial" devices
will be programmed with this unit.

INPUT:
DB-9 Connector. Any modern RS-232 port. (DB-9 or DB-25)

THE BOARD:
It's built on a PCB, 3.5" square. Don't they all come in that size?
There are 3 by 18 pin sockets.

Socket 1 is connected up so that an 84 can be programmed via the RS-232
signals only. A very simple circuit. This will be used only to get
the bootstap program into an 84.

Socket 2 has the 84 to be used for the RS-232 serial to parallel converter
micro that is used to program all other "Serial Family Members".

When the bootstap code is programmed into the 84 in socket 1, it is
removed and installed into socket 2.

OUTPUT:
Additional 18 pin devices can now be programmed using socket 3.

With the addition of a 4PDT switch and a 10 pin IDC header, In-Circuit
programming can be achieved easily for the 84 family.

A simple adapter PCB can be used to plug into socket 3 for conversion to
28 and 40 pin devices if required.

OK Guys, Start shooting!   :-))

Don...

Don McKenzie                ~~   _--_|\    ~~   Email: donmckEraseMEspam.....tbsa.com.au
29 Ellesmere Cres.,         ~~  /      `\  ~~   Phone:   + 61 3 9338 6286
Tullamarine 3043 Australia  ~~ (         ) ~~  Mobile:   + 61 019 939 799
(10 Miles from Melbourne)   ~~  \/~^~\_@/  ~~   Same address for 21 years
See my promo.zip disk at:   ~~         v   ~~
ftp://rasi.lr.ttu.ee/pub/sis/prod/microchip/3rd-Party/Don.McKenzie/

1995\09\06@134645 by John Payson

flavicon
face
> > For doing "blind" programming of an '84 ["blind" meaning the host can't
> > tell anything about what the PIC is doing, or even its existence] I think
> > the simplest possible circuit is two resistors and a cap [plus the power
> > supplies].
> Radical design reduction, better than the 3 pin serial programmer for
> one off designs.
>
> > To send a "1" bit, send 00h; to send a "0" bit, send FFh.
> At what baud rate ?-)
>
> > How does that sound for simplicity?
> Wonderful, if the program does not work the first time, just try again
> until the test program communicats with the pc serial ports to test
> the one wire programmer then do one more blind program to burn in the
> programmer code.

The baud rate would depend upon R2 [the adjustable one], C, and the design
of the serial port feeding the unit.  If you can manage NOT to send anything
between a 1 and a 0 bit for a byte time, then you should try to adjust the
RC so that the shmidt trigger will hit after 5 bit times; if you cannot do
so, then send $E0 instead of $00 for a 1 bit and adjust the shmidt trigger to
go after 3 bit times.  There's a pretty big margin of error in this commun-
ications approach, so while I've not tested it, it should probably not be too
hard to make it work.

E.g. if the transmitting computer's output is 12 volts with an equivalent
series resistance of 1K, then we want that 12-volt signal to pull the data
wire from 0 to 4 volts in 300us [assuming 9600 baud].  Thus, [calculator not
handy] the RC time constant should be about 600us [since that's how long it
would take to pull the line to about 8 volts if the clamp-diodes didn't
interfere] and with a 0.1uF cap you should have a 6K resistor.

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