John Payson wrote:
>
> > I hear you but not even on my worst day would I concieve of such a
> > design.I have barely started on my project so I carefully current
> > limited all I/O pins.My experience (limited) programming PC's told
> > me to expect the unexpected from my software for a while.Now my task
> > is to find a programming software package that will properly set the
> > config bits and I'm on my way. bye
>
> Well, what happened was that when I first designed the thing, I had been
> planning to have it keep the inserted chips in program or reset state, and
> never let them execute code.  Further, since chips can't run without a
> clock, I figured the likelihood of any errant code actually running was
> essentially nil.
>
> Despite this, I still would have 'liked' resistors on the all the pins, but
> pins 1 and 18 are the ground/power pins for the 12C508.  Having the program-
> mer do double-duty required either having these lines switched, or else just
> figuring that they'd be okay.  Given that the latter was much easier, and
> that I was operating under the former assumptions, this was not a hard choice.
>
> The problem came when I added a header to let the programmer program and run
> 16C84's on a remote system.  Without fully realizing the consequences, I made
> it so that when the unit finished programming, it would output highs through
> the (resistively-coupled) clock and data signals and set the reset line to +5.
> Even here I would have been okay had the 16C620's I'd been using not been set
> for RC mode (in my project I was too lazy too hook up a crystal and in fact
> wanted to be able to toy with the speed to see how slow it could run accept-
> ably).  Since the programming clock wire for the 12C508 is the same as the
> input clock wire on the 16Cxx, the resistor I had between that pin and the
> PC printer port (to protect the port) worked very nicely as an RC clock resis-
> tor and ran code out of the part.  Grrrr...
Tony M. responded:
 I did'nt mean to sound derisive as I suppose after rereading this post
I did ,merely defensive.
I had built the an589 compatible programmer with care and a clear
understanding of it's intended
function.Then I sought and found software to operate it.After installing
and trying several
packages I found one that "appeared" to operate properly.The 16c84
however after programming was
inert as a dry goldfish.I assumed my hardware was at fault and went
round and round.It was only
after I yelled for help on the list that the problem was solved.The
software was not configuring
the osc to rc like I told it to.I found yet another software package and
it brought my 16c84's
back to life and the test program I wrote works ok.The software is a dos
command line type but a
batch file and a shortcut later and now I'm just a double click away
each time.
 I was only able to obtain the microchip microcontroller data book and
the non-volatile memory
products data book when I ordered the PIC's as the more general one was
out of stock.So you will
probably see some equally elementary questions from me for a while.
 Also  I have decided that programming a device with 1k of memory in
anything other than it's
native code is probably not the best approach for me which means a
steeper learning curve.I have
so many questions. ciao Tony M.