I use the Baradine Microburner for all PIC programming. It is relatively
inexpensive (a few hundres $CDN) and it uses a standard ASCII interface so
it will work with any computer.
I have also written a command-line interface which is available on the
microchip BBS (3rdparty file area) and a few ftp sites as BURN.ZIP.
Adapters are available for all *EXISTING* PICs (16c64 is comming), I have
them all, It works much better than PICSTART (I have one of them) and
Promaster (have one of those too).
>Could you please explain what do you mean by "It works much better than
>PICSTART"? I have PICSTART and it works. What would be "much better" than
>that? No irony, I'm just wondering.
(What follows is a peeve, so the tone may sound a bit harsh...)
It's just that I find Picstart programmer is annoyingly slow. The Picstart
and Promaster share the same front-end shell which is all manually driven,
messes with the video mode, and does not provide usable error return codes.
They both communicate with proprietary, un-published protocols, so people
with other computers (mac, unix, etc.), or who use safer developement
practices like makefiles, rcs etc. are left in the lurch.
They work great as toys (to play with settings, etc.) but I'm to
absent-minded to remember to manually set the fuses right each time!
> On Aug 8, 1994, Alex Freed wrote:
>
> >Could you please explain what do you mean by "It works much better than
> >PICSTART"? I have PICSTART and it works. What would be "much better" than
> >that? No irony, I'm just wondering.
>
> (What follows is a peeve, so the tone may sound a bit harsh...)
>
> It's just that I find Picstart programmer is annoyingly slow. The Picstart
> and Promaster share the same front-end shell which is all manually driven,
> messes with the video mode, and does not provide usable error return codes.
> They both communicate with proprietary, un-published protocols, so people
> with other computers (mac, unix, etc.), or who use safer developement
> practices like makefiles, rcs etc. are left in the lurch.
>
> They work great as toys (to play with settings, etc.) but I'm to
> absent-minded to remember to manually set the fuses right each time!
>
> - Don
>
I must agree with Don's comments. Having to set the fuses every time is
annoying. In my opinion, a major improvement would be for it to simply
remember the last settings when it starts up.
I have experienced other problems using PICSTART. I find that often
(with 16C71s, at least) it takes 2 or 3 goes to program properly: verification
fails initially, but it will eventually succeed. Is this a problem that others
have found? Something to do with firmare perhaps? (Mine is PICSTART-16B,
Firmware V1.7).
Another point to consider: the programming specs (eg. DS30153D) say that the
devices should be verified at VDD min as well as VDD max, yet I see no
evidence that PICSTART does this. Does anyone know what goes on here? The
PICSTART user's guide is silent on such issues. Seems to me that you could
easily program a device that verifies at 5V, but fails at 3V.
>...Having to set the fuses every time is
>annoying. In my opinion, a major improvement would be for it to simply
>remember the last settings when it starts up.
The various spec sheets define addresses for all fuses. ASPIC supports
setting these in the source files, and I prefer to use programmers which
also do.
>Another point to consider: the programming specs (eg. DS30153D) say that
the
>devices should be verified at VDD min as well as VDD max, yet I see no
>evidence that PICSTART does this. Does anyone know what goes on here?
Microchip has pointed out many times (at least on their BBS) that PICSTART
is NOT considered a "production" programmer, however, we only use Baradine
Microburners,
which I don't believe program VDD (I may be wrong). Getting the fuses
wrong and the
accumulated labour of manually going through all of those menus on
Promaster are more
of a concern than the small chance that a product which passes all other
tests will fail under low voltage (which will reset anyway)!
> I must agree with Don's comments. Having to set the fuses every time is
> annoying. In my opinion, a major improvement would be for it to simply
> remember the last settings when it starts up.
>
If you hit "Read device" before loading in your object code, the fuses are
automatically set to how the current device was last programmed. Only works
for the EE part (16C84), though. :-)
> I have experienced other problems using PICSTART. I find that often
> (with 16C71s, at least) it takes 2 or 3 goes to program properly: verification
> fails initially, but it will eventually succeed. Is this a problem that others
> have found? Something to do with firmare perhaps? (Mine is PICSTART-16B,
> Firmware V1.7).
I have found that every once in a while our PICSTART refuses to program
properly, but I put it down to the ZIF socket - devices placed centrally
do not program properly but ones placed at the left side program OK.
> Another point to consider: the programming specs (eg. DS30153D) say that the
> devices should be verified at VDD min as well as VDD max, yet I see no
> evidence that PICSTART does this. Does anyone know what goes on here? The
> PICSTART user's guide is silent on such issues. Seems to me that you could
> easily program a device that verifies at 5V, but fails at 3V.
PICSTART is classed as a DEVELOPMENT programmer, and the programming spec.
states that only PRODUCTION class programmers need to have the variable
voltage capability. I suppose it's how they get away with such crappy drive
software as well.
>I have found that every once in a while our PICSTART refuses to program
>properly, but I put it down to the ZIF socket - devices placed centrally
>do not program properly but ones placed at the left side program OK.
Hmmm...
I've used the PICStart 16B since version 1.4 (keep getting upgrades, like
candy), and it's always been flakey. I have one at work and another at
home. Both the same.
I've never even tried shifting the part in the ZIF socket. Sometimes it
programs first time, usually it takes three attempts. Without shifting the
chip at all. I chalk it up to flakey timing and bad exception handling.
Which is also pure conjecture... My $0.02
I'm interested in that "Unix" code the other guy has.
- JohnR
--
John R. Haggis haggisspam_OUTnetcom.com
Millennium Research
(408) 269-1814 vox
(408) 269-9323 fax
I'm interested in programming info for the entire line of pics (16xx
and 17xx series.) I'd like to build a serial programmer that can handle
all of them by using some hardwired personality modules. What data
books describe the programming algorithms and signals needed? I'm not
at all familiar with Microchip's policy on data books. Do they always
charge for them? What if you're a college student? Basically, I need
everything there is to know about the 16xx and 17xx lines. Is the
"Microchip Full Line Data Book" advertised in DigiKey for $8.60 what I
want? What about the "Embedded Control PIC Applications Handbook?"
Thanks in advance for any help!
Chris Kristof
Junior ECE
Carnegie Mellon University
I have been looking over the docs on how to preform parallel programming
of a pic. The 6/7/8 all program similar. However they all reference a
"RT"pin. Which pin is this? I assume that on the 18 pin devices that it
is the RTCC pin(as all of the others are used). however on the 40 pin
devices I am not sure. could it be/is it the timer0 pin???? Any help
would be nice. BTW if you wonder why I am using parallel its because
1)its a personal project and 2)Its 10X faster.
later
John
-----------------------------------------------------------------------------
John Johnson Team OS/2 member | @spam@johnsonjKILLspambga.com | KILLspamjohnsonjKILLspamutdallas.edu
-----------------------------------------------------------------------------
And the Seventh version of OS/2 raised into the air its bow of blue steel and
cried," It. Is. Done." Around him lay Bill Gates and Microsoft apps. Their
evil in this world at an end.
Revelations of InfoWorld, Oct 11 1994
My first experience of a PIC was in building a controller, serial comms device
and remote unit controller with LCD support and 16 remote units running
on a twisted pair network.....
Programming was done in serial mode from a compiler and programmer I wrote
in BASIC (euch! but only choice - no PC at home). Problem was, I ruined
several PICs, as the CP bit set itself no matter what I wrote to the fuses...
Bit of a bugger when you've got a _small_ budget!
OK now I-m working on a PICSTART, but I tried this idea of sending the
parallel data to do bulk erase, but it didn't work. It would be very nice
to build the serial bulk erase command into it.
Bryan
--
---------------------------------
BRYAN CROTAZ - RemoveMEb.crotazTakeThisOuTic.ac.uk
---------------------------------
TECHNICAL MANAGER
Student Television Of Imperial College
Beit Quad, Prince Consort Road
London SW7 2BB
Tel. 071-594-8104
Fax. 071-225-2309 attn. STOIC
John asks what I did to prevent it...
I worked for the BBC over the summer and they bought me a PICSTART
kit for a project, which I subsequently borrowed and did it by
parallel means....
No serial solution to setting CP...or so _I've_ found.
Interested to know if someone's suggestion of sending the parallel
codes does actually work, and I just mucked it up....
Bryan
--
---------------------------------
BRYAN CROTAZ - spamBeGoneb.crotazspamBeGoneic.ac.uk
---------------------------------
TECHNICAL MANAGER
Student Television Of Imperial College
Beit Quad, Prince Consort Road
London SW7 2BB
Tel. 071-594-8104
Fax. 071-225-2309 attn. STOIC
> John asks what I did to prevent it...
> I worked for the BBC over the summer and they bought me a PICSTART
> kit for a project, which I subsequently borrowed and did it by
> parallel means....
> No serial solution to setting CP...or so _I've_ found.
> Interested to know if someone's suggestion of sending the parallel
> codes does actually work, and I just mucked it up....
I've used a PICSTART-16B (V1.6 firmware) and although I can't be sure
how it deals with bulk erase, I do know that it uses _serial_mode_
programming for 16C84s. Which, by the way, is useful to know if you
have a PICSTART but really wanted something for In-System Programming
(ISP); all you need to do is hook up 4/5 wires (Vpp, Vdd (maybe), RB6,
RB7 and GND) from the PICSTART ZIF socket to your application circuit.
Before I built my own ISP circuit that's what I used to do. Perhaps
things have changed with the latest PICSTART firmware.
As I mentioned previously, I found the parallel codes for bulk erase work
in serial mode. As I seem to be the only person to have said that, and
Bryan doesn't think it's true, I guess it would be helpful if someone
else could give some input to the discussion.
Hello, I am working on a PIC16C84 programmer for Linux. So far things
have been going prety well, but this eveing I have run into a small problem.
When I read back the fuse and ID data I have programmed it is zero!
Programming and reading all of the data memory, and eeprom memory works
just fine. I have even built a distinctive ring switcher and used it for
several months with no problems.
I just added ID and fuse verification to the program, so this problem
has probably always been there :>
The method for programming ID is somewhat confusing in the PIC16C84
programming specs. It says to do a load config command, and then a
program cycle, etc. The way I do things is like this:
Load Config command
send 0x3FFF to pic
load data (0x02) command
ID data
program command
Read data command(0x04)
If the data is wrong, I re-try up to 25 times.
then loop for 3x the wrong count:
load data command
ID data
program command
Increment address finally!
Do this for 0x2000-0x2003
Skip over 0x2004-0x2006
load data command
send fuse data
read data command
if bad, print error message
end of program routine.
Can anyone see a problem with this sequence? This follows the diagram
on page 4 of the 16C84 programming spec.
Thanks,
Brian
------------------------------------------------------------------------------
"Everyone is a prisoner holding their own key." | finger TakeThisOuTblaneEraseMEspam_OUTseanet.com
-- Journey | PGP 2.6 email accepted
------------------------------------------------------------------------------
Do you have a copy of David Taite's 16c84 programmer? I
don't recall that the 16c84 requires recursive programming.
This is required for the eproms but not the eeproms.
In case you don't have his program, I'll include a copy of the config
routine.
> Brian,
>
> Do you have a copy of David Taite's 16c84 programmer? I
> don't recall that the 16c84 requires recursive programming.
> This is required for the eproms but not the eeproms.
The 16C84 document that I have does it this way. Previously I wasn't
and it seemed to work. I added it to try and solve my ID/Fuse bug.
So do you thin the configuration programming chart was lifted out of
another document? I've seen motorola manuals that do this alot.
I've found the problem with my ID/Fuse programming. It wasn't the
program sequence after all. It was my read/varify routines. I send out a
load config command to set the PC to 0x2000, but I was forgetting to send
a dummy data value. This caused things to get confused, and it wouldn't
read the id and fuse data correctly.
Yes, I have a copy of his code. Thanks.
Brian
------------------------------------------------------------------------------
"Everyone is a prisoner holding their own key." | finger RemoveMEblaneTakeThisOuTseanet.com
-- Journey | PGP 2.6 email accepted
------------------------------------------------------------------------------
I just tried to program a 16c64 while it was in situ. The chip appeared to
accept the program and it even verified at 5.5V but when I switched to 4.5V
the verify intermittently failed. I kept thinking that my programmer wasn't
working. After a few hours of looking at the hex listings, I finally thought
to remove the chip from the circuit. Once I did this, the programmer work
flawlessly. Finally, I determined that it was the oscillator that was messing
everything up.
DON'T apply an oscillator signal to the clkin pin when programming a pic chip!
>
> When you say an osc shouldn't be applied during programming, does this
> include a mere crystal, or an external clock generator?
>
> Bryan
Hi Bryan,
The only case that I know is when I used an oscillator. If you use a
crystal, that may be different. You could check to see if the crystal is
inactive during programming mode by putting a frequency counter or an
oscilloscope on the clkin pin. If it is active, I would think that you
would get the same poor results as I did, but maybe not.
>I don't suppose that the '61 is programmable with my PIC-START system I
use
>for the '5X family???
Surprisingly enough Paul it is.
The PICStart-16B1 which programs the '5x family also programs the '71 and
'84. When this programmer came out these were the only midrange chips
available and being 18 pin devices they were included with the '5x parts.
With the introduction of the '64 and '74, both 40 pin devices, a new
PICStart-16C was introduced to support all 40 and 28 pin midrange PICs.
Since the '61 is basically a '71 with no A/D its programmer compatible
with the '71 and may be programmed with the PICStart-16B1.
As even more midrange parts become available we'll just have to wait for
another of life's little mysteries to unfold and reveal how they'll be
supported by PICStart.
> Surprisingly enough Paul it is.
>
> The PICStart-16B1 which programs the '5x family also programs the '71 and
> '84. When this programmer came out these were the only midrange chips
> available and being 18 pin devices they were included with the '5x parts.
> With the introduction of the '64 and '74, both 40 pin devices, a new
> PICStart-16C was introduced to support all 40 and 28 pin midrange PICs.
>
> Since the '61 is basically a '71 with no A/D its programmer compatible
> with the '71 and may be programmed with the PICStart-16B1.
>
> As even more midrange parts become available we'll just have to wait for
> another of life's little mysteries to unfold and reveal how they'll be
> supported by PICStart.
>
> Something's just defy explanation...
>
> John E. A. 7:)
I have a couple of questions regarding the PIC....
1) Not to start a religious debate or anything, but... Is there anyone out there
who has used both the HC11 and the PIC and would be willing to share their
experiences with both?
2) From the FAQ, it seems that a programmer can be made simply for the 16C84,
but there are no references to programmers for other parts. Are there any
available without dropping $200? If so, where can I get more info?
3) How do you get out of digest mode? I had to unsubscribe and resubscribe!
Admittedly I am still figuring things out here ... but let
me ask this question ... Why is David Tait's 16C84 programmer
only labeled as for 16C84's? Other PIC's have in-system serial
programming! Isn't it just a question of software?
Why couldn't I use David Tait's programmer to program a
16C74?
>
> Admittedly I am still figuring things out here ... but let
> me ask this question ... Why is David Tait's 16C84 programmer
> only labeled as for 16C84's? Other PIC's have in-system serial
> programming! Isn't it just a question of software?
>
> Why couldn't I use David Tait's programmer to program a
> 16C74?
One word: EEPROM
See the 16C84 EEPROM is self timed on the write. So once you send a
begin programming command it'll stop programming automatically.
All the other parts however use EPROM. So the programmer is obligated to
send a STOP programming in addition to the BEGIN program command. I believe
that the time is only 100 uS pulses which is difficult to get with any
accuracy in software.
Best bet would be a 16C84 that would handle the task easily. It can be self
programmed and then the programm driven by a 16C84 could programm all
the other parts.
The Load Configuration command is actually the 6 bit code (OOh)
that is sent to RB7 before the configuration data is sent in 16
bit chunks (1 startbit,14 data, 1 stopbit). After receiving the
the Load Configuration command, the PIC resets the program
counter to 2000 hex, which is the beginning of the configuration
memory space. The increment command is then used after every
write/read to advance the PC to the next location. The load
configuration sequence has to come after the program eeprom and
data eeprom cycles because it "locks up" the system, requiring a
reset to once again gain access to the program and data EEPROM.
I have another question about PIC16C84 programming. The
programming voltage is specified at 12-14 volts. I would like to
use a MAXIM chip that produces 12v+ for Flash memory,regulated to
+- 5%. Will this voltage be as reliable as 13.5 volts in
programming the PIC16C84? I know I can use a MAXIM switching
regulator to get 13.5v, but would rather not use an inductor. The
12v+ chip uses a charge pump.
> The Load Configuration command is actually the 6 bit code (OOh)
> ...
Argh! Yes - thats what the data book says. But what does the actual 16 bit
data field in the Load Configuration command actually do? If you look
closely in the data book, you will see it has a data field, just like the
rest of the Load commands. *But* - there is no mention anywhere of what
this field actually does. All that is mentioned is that it advances the PC
to 2000h. (Yes, it says something vague about loading configuration, but
no explanation of what any bits actually do).
The fuses etcetera are mapped onto program memory, at 2000h onwards, so
they are blown with Load Program, not load configuration.
(I should say Im working off an old 16C84 data sheet - marked Preliminary.
I think its the '93 data book from memory. Any friendly microchip reps
interested in throwing a newer edition my way? ;-)
The "load configuration" and "load data for program memory" commands
are both actually commands that load data for program memory. The
only difference is that the "load config" command will also set the
address pointer to 02000h i.e. near the configuration register
(actually 2000 is the start of our test memory area).
So the answer to the question "What is in the 16 bit field?" is that
normally you will place your data for the bits in the configuration
register here with the "load config" command, and then do 7 increment
commands to point the address to 2007 then do a program command.
______________________________ Forward Header __________________________________
Subject: Re: Question on PIC programming
Author: Peter Knight <RemoveMEP.J.KnightTakeThisOuTspamBRADFORD.AC.UK> at Internet_Exchange
Date: 6/16/95 6:37 PM
On Fri, 16 Jun 1995, Greg Riddick wrote:
> The Load Configuration command is actually the 6 bit code (OOh)
> ...
Argh! Yes - thats what the data book says. But what does the actual 16 bit
data field in the Load Configuration command actually do? If you look
closely in the data book, you will see it has a data field, just like the
rest of the Load commands. *But* - there is no mention anywhere of what
this field actually does. All that is mentioned is that it advances the PC
to 2000h. (Yes, it says something vague about loading configuration, but no
explanation of what any bits actually do).
The fuses etcetera are mapped onto program memory, at 2000h onwards, so
they are blown with Load Program, not load configuration.
(I should say Im working off an old 16C84 data sheet - marked Preliminary.
I think its the '93 data book from memory. Any friendly microchip reps
interested in throwing a newer edition my way? ;-)
> I'm hoping to develop and design apps for the 16C5x, 16Cxx line of the
> PIC processor. However, can anyone tell me of a good working enviornment
> for Windows or Linux. I'm looking for an editor, compiler(if avaliable),
> assembler, simulator type of package that uses windows. If nothing
> exists, can someone suggest to me the best environemtnt to develop. Thks
> for all the help.
Under Linux there is an assembler called pictools from a progrmammer in
England(He's probably on this list, I did some beta on it and lost
touch). For programming the 16C84 you can use a Russ Reiss
programmer(from CCI last year) and my picpgmr program available from
ftp.eskimo.com/~blane/
I don't remember the site for pictools, but an archie search should
find it.
Brian
- ---------------------------------------------------------------------------
email RemoveMEblaneKILLspamguetech.com with 'Subject: blane-info' for PGP key
>Is the serial programming mode of the 16C84 the same as for
>16C74 /64 ?
Pretty much ... in a general sense.
>
>Can I use the In-Circuit programmer for 16C84 with 16C74 ?
The circuit from AN589 is OK, for example.
>Are the voltages and the timings the same ?
The timing is, according to the Microchip programming spec.
not as critical for EPROM parts as I first thought (compared
to the EEPROM 16C84). The commands you send the EPROM parts
are different in what Microchip calls the "Program Cycle" than
the EEPROM part. In particular you have to send an "END
PROGRAMMING" command to the EPROM parts whereas you just wait
(>~100ms) for the EEPROM parts to automatically stop their
programming cycle. Voltages are the same.
Also there are some differences in the configuration fuses, as one
would expect.
If you want to program these parts serially you should get the
Microchip data book (you can buy it from Digikey if you want, ~$8)
and read the section on the programming spec.
You can then do one of several things.
1)David Tait suggested to me that I use the circuit from AN589
and look at his code (because I was going to write some of my
own code to program these EPROM parts). This was a good suggestion
and seems to work. David Tait's code is pretty easy to read, is
cleaner and more complete than the code in AN589. Although you
may also look at the AN589 code for reference. (i.e. you can
build and write your own like I did. It's not too hard!)
You might add some things to the circuit for debug. (e.g. I liked
David Tait's LED indicators so I added some the the AN589 circuit)
2)You can wait until I finish debugging my code that should work with
the AN589 circuit. Then I'll send you a copy. (or post it or
something.) It is pretty much working now ... It's written in
Turbo C.
3)You can modify David Tait's code to program the parts. I can
see that this will probably work without too much difficulty, now
that I've built and programmed my own.
A concern that people expressed before is that a ~1us resolution
timer was needed (or should be used) to program the EPROM parts.
So I wrote a "Loop calibration function", for lack of a better
name, that uses the PC Timer 2 and gives me a few microsecond
resolution on executions of an assembly language loop (vs a C "for"
loop). This is probably not really needed though.
>Hi.
>
>I've seen a very simple circuit to read (program ?) the 16C84
>directly via PC-Parallel Port.
>But I don't remember where.
>
>Does anyone know how to do this, or where to get this circuit ?
>
ftp://rasi.lr.ttu.ee/pub/sis/msdos/pgmtools/pip-02.zip is a
programmer software for PIC family micros + Serial EEPROM's
able to work with many selfmade PIC16C84 programmers
Programmer drivers are in:
ftp://rasi.lr.ttu.ee/pub/sis/msdos/drivers/
for schematics you may browse: http://rasi.lr.ttu.ee/~sis
there are few links to pages with embedded
Programmer schematics.
>> I've seen a very simple circuit to read (program ?) the 16C84
>> directly via PC-Parallel Port.
>> But I don't remember where.
>
>Perhaps you mean Microchip application note AN589. A Postscript copy
I've already buildt this circuit, thanks.
But I'm looking for a simpler an cheaper circuit, because this part will
perhaps be used as an educational system for students.
That means, every student has to buy one.
>
>Details of another approach are available; get:
>
>ftp://ftp.ee.ualberta.ca/pub/cookbook/comp/ibm/pic84*
> I've already buildt this circuit [AN589], thanks.
> But I'm looking for a simpler an cheaper circuit, because this part will
> perhaps be used as an educational system for students.
> That means, every student has to buy one.
Well, the prize for the most simple circuit must go to Mark Cox. The
PIC-FAQ has details of the primary FTP site for his design, however,
if you visit Silicon Studio's site as recommended by Antti in an
earlier post, you can grab a copy from there:
> >ftp://ftp.ee.ualberta.ca/pub/cookbook/comp/ibm/pic84*
>
> Ist this your cuircuit ?
> I know it.
Yes. I guess the implication is that you know it but have rejected it
also. If you haven't looked at the cookbook site for a while then you
can now pickup some PCB artwork by Mike Laidlaw (pic84art.zip) which
is a bit more integrated than the version that has been there for a
while (pic84pcb.zip).
I am trying to program a PIC16c84 chip with serial mode. I have tried three
different programmers (all based on David Taits programmer). However, I have
not succedid to get any of them to work. The hardware is mega simple, and I
have checked the hardware many times, but cant find any errors.
Have anybody any clue what might be wrong. I get a verify error when I try
to program a PIC.
I'm sorry to hear you have had a problem, but it's probably better to
e-mail me directly than trouble the list. Anyway, the short answer to
the question above is: Yes! :-). Just in case anybody else is stuck,
it's probably worth repeating that there is a FAQ on the programmer
available as:
Please grab this file and see if the information it contains helps
you. (You'll find some PCB artwork - pic84art.zip - in the same
places and you might consider using that).
If you are convinced the hardware is OK you could have more luck by
using the more advanced software from Silicon Studio. Have a look
around their FTP/WWW site:
> I am trying to program a PIC16c84 chip with serial mode. I have tried three
> different programmers (all based on David Taits programmer). However, I have
> not succedid to get any of them to work. The hardware is mega simple, and I
> have checked the hardware many times, but cant find any errors.
>
> Have anybody any clue what might be wrong. I get a verify error when I try
> to program a PIC.
>
> (Is David Taits programmer supposed to work ??)
I built a programmer which REALLY oddly enough, would simply not work
on my computer. I switched and tried 3 different parallel ports, booting
off a disk, and many other things. It just didn't like my CPU or something.
It works on every other computer though. I did notice that my parallel port
was putting out 3.5 V instead of the usualy 5V on other people's parallel
ports. I probably blew something up with my other projects.
D. Taits soft usually works. However you are not the first one saying
he cant get it working. Try to slow down your PC both the CPU clock
and BUS speed, don run D. Tait software in a Windows DOS box!
there are no good ways (yet) to merge the two files together you may
save a dummy file with PICSER, take a text editor copy paste and
fixup up the start addresses. Or you could write the chip once
without CP with taits software and then readback with PICSER,
ok taits software doesnt run on _your_ PC, use the neighbours.
I just uploaded DISASM like stuff to
/pub/sis/prod/microchip/disasm/
nothing very good but something useable amongst.
look yourself, have fun
I have DISASM84 written myself but very early stage.
well works. not uploaded anywhere
antti
----------------------------------------------------------
-- Antti Lukats Silicon Studio --
-- TakeThisOuTsisKILLspamspamrasi.lr.ttu.ee PO Box 3500 --
-- ftp://rasi.lr.ttu.ee/pub/sis Tallinn EE0001 --
-- http://rasi.lr.ttu.ee/~sis Estonia --
----------------------------------------------------------
Tobias wrote:
I can not get D. Taits software to work.
and Antti replied:
D. Taits soft usually works. However you are not the first one saying
he cant get it working.
I always find such statements a bit confusing; that is because I
provide software in three different forms: Turbo-C source (PP.C),
QBasic source (PP.BAS) and an executable (PP.EXE). Which of these
don't work? All of them?
Tobias:
If the hardware works with PICSER then I expect my QBasic program will
work too. Did you try that? If you tried it but it didn't work, fit
a 10k pullup on the ACK pin and have another go. My PCs don't seem to
need one but apparently some do. Antti tells me his software makes
special provision for the lack of a pullup. With PP.BAS working you
can then take Antti's advice to program a PIC using your separate
program and data files and use PICSER to dump a merged file. After
that you can throw my software in the bin and use PICSER from then on.
I want to point out that there is nothing wrong with PP.C either. The
same can't be said of PP.EXE though. In my FAQ I mentioned that I
thought my compiler (Turbo-C V2.0) had a bug in the routine used to
determine the vital programming delay. I can now confirm that.
I compiled and ran this simple program on several different machines:
#include <stdio.h>
#include <dos.h>
void main()
{
int i;
printf("start\n");
for ( i=0; i<2000; ++i)
delay(10);
printf("finish\n");
}
This should print "start" then wait 20 seconds before printing
"finish". This works as expected on my old 386DX-20. On a 486DX-33
the waiting period dropped to 9 seconds and on a 486DX4-75 it was only
3 seconds. Compiling and running the same program using a more recent
version of Turbo-C (actually Turbo-C++ now) gave a uniform 20 seconds
delay on all PCs.
If you don't have access to a C compiler just let me know and I'll
send you a new PP.EXE as uuencoded mail (that also goes for anybody
else bitten by this problem); make sure you tell me whether you are
using inverting (7406) or non-inverting (7407) buffers. I will
replace the archived copies of PP.EXE in the next few weeks.
>First, I am using PSIM v 2.42 , PASM v2.3, and DS30015I data sheet for the
>PIC16c56.
> I just wrote some code to do a BCD to binary coversion (the hard way, a 10X
>loop of ADDWF) and I had to redo some of the code and I don't really have a
>good grasp of why.
John Payson and I have been looking at the BCD conversion problem. He had
some really good ideas that I haven't fully explored yet. Here's my
routine, which is probably a little faster, though by no means optimal:
cvBCD
; Converts a binary number (known to be less than 100) to packed BCD.
; Process: Trial-subtractions of 80, 40, 20, and 10 are done. If the
; number is greater than these, the corresponding bit in the high BCD
; digit is set. The remainder forms the low BCD digit.
; Input: Binary number in W.
; Output: Packed BCD number in bcd0
; RAM: tmp, tmp+1, bcd0 (stores result)
cvBCD
movwf tmp ;Store number being converted.
clrf bcd0 ;Clear result.
movlw .80 ; 80 decimal is 01010000.
movwf tmp+1
cvBCDl
movfw tmp+1 ;Get base (80, 40, 20, or 10)
subwf tmp,0 ;form number - current base.
skpnc ;If less, don't restore.
movwf tmp ;It was more. Store adjusted value.
rlf bcd0,1 ;Rotate result into bcd0 (brings 0 out C)
rrf tmp+1,1 ;Reduce base number by half.
btfss tmp+1,0 ;Is base number 5 yet?
goto cvBCDl ;No, do another bit in MS digit.
; Now we have the low 4 bits of BCD0 being the high digit, and the low 4
; bits of tmp being the low digit (known to be less than 10).
swapf bcd0,1 ;Put high digit in place.
movfw tmp ;Get the low digit.
iorwf bcd0,1 ;OR in the low digit.
This is untested as well, and is also about an order of magnitude below what
John sent me privately (I will await his permission before posting). But
it's something to think about. The really fast way (6 instruction cycles)
is of course a table of 100 entries. Not unfeasible if you don't need the
space for anything else.
>
>This piece of code always resulted in a skip, even if carry was set
> BTFSC STATUS,C
> but this worked
> BTFSC STATUS,0 I thought C was a predefined equate?
With MPALC (the only one I'm familar with), you need an include file with
the standard names of all the special-purpose stuff. (It is possible that
STATUS is not a predefined equate either) However, MPALC includes the
pre-defined psuedo-instructions SKPC (skip if C set), and SKPNC (skip if C
not set), which assemble to BTFSS 3,0 etc. Look at your .LST file and
decode what was actually assembled.
>
>
> in a single call jump/return
> RETLW TEMP W didn't contain the variable TEMP, I had to
> do a MOVF TEMP,W after the return.
This is a flawed concept. It is not possible to return a variable in W with
the 16C5x series, other than with multiple RETLWs. The RETLW loads a
constant from ROM (what you ended up with in your case was always the
*address* of TMP in W). Since this is the only way to return on the 5x, any
value left in W by the subroutine will be lost. One work-around if you have
only a few possible values to return is to end your subroutine with a table:
; return 0, 1, or 2 in W. Will crash if W>2. Must execute from first half of
; a program page.
addwf PC,1 ;Skip to apropriate location in table
retlw 0
retlw 1
retlw 2
The ADDWF will affect C, DC, and Z though. In most cases keeping the result
in RAM and loading it after return is the best way to do it.
>
> This statement didn't move the value TEMP to W
> MOVF TEMP but this did
> MOVF TEMP,W If the destination register is not given, I thought
> it would put the contents in W.
The default in MPALC is F. I always specify it explicitly either way to
avoid confusion. MPALC also has the psuedo-instruction MOVFW which makes it
clearer what is going on.
>
> Same thing with ADDWF, This didn't put the result into W
> ADDWF TEMP but this did
> ADDWF TEMP,0 could I have typed in ADDWF TEMP,W?
Same problem, same solution. The default is F. Generally I use 0 and 1
rather than W and F but I think most assemblers would be smart enough to
handle either.
The binary opcodes in the instruction table will help you figure out exactly
what your assembler is doing by examining the resultant opcode in the .LST file.
I am using PICserial programmer 1.0 beta, the orginally hardware by D. Tait and
a pentium 75 MHz PC. The problem is that I only success programming the chip
(16c84)
at random times, ie. something is quite unstable here. Is it the software or
the hardware which couses this ??
PS ! Are there/will there be any update to PICseral programmer.
In message <RemoveME9509231428.aa20222spamBeGonepunt-1.mail.demon.net> spamBeGonePICLIST@spam@spam_OUTmitvma.bitnet
writes:
> I am using PICserial programmer 1.0 beta, the orginally hardware by D. Tait
and
> a pentium 75 MHz PC. The problem is that I only success programming the chip
> (16c84)
> at random times, ie. something is quite unstable here. Is it the software or
> the hardware which couses this ??
>
> PS ! Are there/will there be any update to PICseral programmer.
Hi Tobias,
I've written software suitable for the Davit Tait board, it reads,
writes, and disassembles 16C84's. It's available for download from the
MICROCHIP BBS in the 3rdParty area as 84PGM.ZIP, it should also be on Don's
web page at 'http://rasi.lr.ttu.ee/~sis/mirror/don/'. If you have any problems
I could always E-Mail it to you, just ask!. It's also FREE!.
The software defaults to the Don McKenzie design board, but can be used with
either of the David Tait designs by the use of a config file. Documentation
is included in the ZIP file, along with sample CFG files for the different
boards.
One point which might be causing problems, how long is your cable from the
printer port to the programmer, I've noticed that once it starts getting too
long, you start to have problems. It seems to depend on your particular
printer port, I changed my IO card, and it wouldn't work at all, with my
existing length lead.
ABSTRACT: (for those too bored by long messages ;-)
student looking for information, sourcecodes, circuits, etc. concerning the
programming of Microchip PICs (esp. 16C5X, 16C7X, 17CXX, 84s ) for privat and
educational purpose only, emails encouraged (no spams please!)
Having spent my time with the 'more popular' microcontrollers by Intel
(8051-series), I'm now very interested in using the Microchip PIC-series
because they are so small and don't need expensive peripherals. The only
problem is that you need a special programer to burn those PICs and being
a student my buget is too small to buy a commercial programer. Beside the
price the commercial programers also seem to have the disadvantage of
'inflexibility' in adopting to newer PICs (or at least one has to pay a
'fair' amount for the updates).
So I set myself the aim to build a cheap and flexible (both because
selfmade) programer with all the information I could get and ordered the
"Microchip Data-Book" in order to optain needed information about the
programming of PICs. (Am I right that there IS information (algorithms,
voltage, etc.) concerning the programming of PICs in that book ?)
Although I waited for some time I still haven't got the book (my local
dealer seems to have difficulties with that order) and so I extended my
search to the internet (my only source since I don't own a modem). With
luck I stumbled over David Tait's 84-programer and all the variations.
(BTW I'm really grateful for the work you all have done. Special !!cheers!!
for David who really set the ball rolling.)
[For all those who don't know where to find those 84-programers:
ftp://rasi.lr.ttu.ee directories /pub/sis/msdos and /pub/sis/CAD
as far as I know... ]
So by now I *have built* a working 84 programer, but I still don't know
HOW to program those 84s. Since my aim is not to 'reinvent the wheel'
but to optain knowledge about programming PICs, I'm still looking for
information ...
Don McKenzie mentions a FAQ-file (by David Tait) in the files to his own
programmer. ("After reading through David Tait's FAQ file on PIC84
programming..." cited from !PIC.ME [DON001_2.ZIP]).
Could someone please tell me where I can find it (in the internet) or
even email it to me?
With the 84-programers I also stumbled over the PIP (in prerelease version,
Will the final also be publical available?). Is there a documented driver/
interface (since there are so many variations) or does anyone have sourcecode
for such a (PINAPI-) driver ?
Since I'm austrian and we are a bit at the backwater of the backwater I
still can't buy the newer serial chips at my local stores (everyone seems to
be talking about the ?16C61/62? now). So I'm still interested in programming
the 'older' PICs (16C5Xs), which are cheaper than the 84s and far more
available arround here. (I sort of gathered that one has to put the program
in parallel form to the equivalent pins of RB/RA and provide a strobe signal.
But what is the length of this strobe, exact voltage-level, needed (preceding)
preparations, Pinout in programming mode, etc. ?)
Therefore I'm VERY interested in information and sourcecodes (IMHO the
best way to learn something is to test out what exists; EXEs aren't really
*open* to the eye and besides I don't want to get sewed for reverse
engineering - I'm not Microsoft to come through merely unharmed :-).
So I would be VERY grateful if somebody could tell me where to find such
info/source or email them to me. (These would be used for privat/educational
purpose only!)
Since I'm a true friend of IBMs OS/2 (half 2 Nil the bugs of WIN95 :-)
I'm also interested in ports or porting a programer (HW/SW) to that system.
Many thanks in advance for your responses!
P.S.: I'm aware of the postings about a MIPP-project (= Machine Independent
Pic Programmer) a few days ago but don't know how far things have gone
so far. Is the MIPP finished? Will it be optainable free of charge?
How about sources?
****************************************************************************
* Roman VALEHRACH eMail-to: e8927070EraseMEstudent.tuwien.ac.at *
* (subject of change) *
* *
* EVERYBODY!.. furry creatures ->*
* "SHARE AND ENJOY, SHARE AND ENJOY... from alpha-centaur *
* (we tell you .. go stick your head in a pig)" (footprints) *
****************************************************************************
> Don McKenzie mentions a FAQ-file (by David Tait) in the files to his own
> programmer. ("After reading through David Tait's FAQ file on PIC84
> programming..." cited from !PIC.ME [DON001_2.ZIP]).
> Could someone please tell me where I can find it (in the internet) or
> even email it to me?
Hi Valehrach. The mention I made is of the file David uploaded to the
MicroChip BBS. I still keep telling users about this BBS. If you can ring
a Compuserve number at local call cost, then that's all you have to pay
for full access.
The file is also available on the Internet, I know David reads this
daily, so if someone doesn't come up with the Inet address, David will. I
have it somewhere but not at my finger tips at the moment.
>
> With the 84-programers I also stumbled over the PIP (in prerelease version,
> Will the final also be publical available?). Is there a documented driver/
> interface (since there are so many variations) or does anyone have sourcecode
> for such a (PINAPI-) driver ?
I doubt if you will get source but if you are after a cheap all round
programmer kit, contact Antti at Silicon Studios. He is about to release
a new PCB that will do just about everything. I even have one on order!!
> Since I'm austrian and we are a bit at the backwater of the backwater I
> still can't buy the newer serial chips at my local stores (everyone seems to
> be talking about the ?16C61/62? now). So I'm still interested in programming
> the 'older' PICs (16C5Xs), which are cheaper than the 84s and far more
> available arround here. (I sort of gathered that one has to put the program
Perhaps you should rethink the 5x cheaper philosophy!
My programmer now supports 61, 62, 63, 64, 64, 71, 84, 620, 621, and 622.
My hardware supports these, but I can't lay claim to the software. This
was done by Cybertech of Las Vegas US. I supply a shareware version with
my board.
>
> P.S.: I'm aware of the postings about a MIPP-project (= Machine Independent
> Pic Programmer) a few days ago but don't know how far things have gone
> so far. Is the MIPP finished? Will it be optainable free of charge?
> How about sources?
As above. Contact Silicon Studios, however I think you will get a few
responses to your message.
> I doubt if you will get source but if you are after a cheap all round
> programmer kit, contact Antti at Silicon Studios. He is about to release
> a new PCB that will do just about everything. I even have one on order!!
>
I built programmer following skematic from Silicon Studios. It works for
most of the computer, but somehow it does not work for my laptop
computer. I check the voltage on the com port, and it is normally -7 to
-8 volt not -12 volt. I am wondering is there any way to solve this
problems.
> On Wed, 4 Oct 1995, Don McKenzie wrote:
>
> > I doubt if you will get source but if you are after a cheap all round
> > programmer kit, contact Antti at Silicon Studios. He is about to release
> > a new PCB that will do just about everything. I even have one on order!!
> >
>
> I built programmer following skematic from Silicon Studios. It works for
> most of the computer, but somehow it does not work for my laptop
> computer. I check the voltage on the com port, and it is normally -7 to
> -8 volt not -12 volt. I am wondering is there any way to solve this
> problems.
>
> Shingo Uto
>
I think Don has answered most of your questions, but you say:
> So by now I *have built* a working 84 programer, but I still don't know
> HOW to program those 84s. Since my aim is not to 'reinvent the wheel'
> but to optain knowledge about programming PICs, I'm still looking for
> information ...
I can confirm that the Microchip databook will tell you how to program
PICs of all shapes and sizes so when your copy arrives you'll have all
the information you could possibly want. Steve Walz put together a
file which sketches some of the programming details for the 16C5X PICs and
I guess that he'll have a copy on his FTP site:
ftp://ftp.armory.com/pub/user/rstevew/
I can't remember the filename (picprog.txt perhaps). Anyway, while you're
visiting make sure you pick up the parallel port FAQ from there - I found
it very helpful as I knew (know?) nothing about PC internals.
> Don McKenzie mentions a FAQ-file (by David Tait) in the files to his own
> programmer.
I'm afraid the FAQ is not about 16C84 _programming_ but about my 16C84
_programmer_ - you won't learn about the 16C84 programming algorithm
from there. If you want to make sure the FAQ is as useless as I say then
you can pick up a copy from one of these sites:
as pic84faq.zip. The 16C84 programming spec from the 1995/96 databook
is available as datasheet DS30189D and you might be able to get a
copy from Elbatex GmBH, Eitnergasse 6, A-1230 Wien (Tel: 1-86642-0;
Fax: 1-86642-201) before your databook turns up.
> P.S.: I'm aware of the postings about a MIPP-project (= Machine Independent
> Pic Programmer) a few days ago but don't know how far things have gone
> so far. Is the MIPP finished? Will it be optainable free of charge?
> How about sources?
I, at least, haven't had any time to work on this. The main aim was to
make a PIC based PIC programmer that could be bootstrapped on any
computer with a serial port. Robin Abbott's ETI programmer could be
described as a MIPP. I think you can grab some information about
this project from the Silicon Studio site including a hex dump of the
PIC used in the programmer. Robin seems to have joined the PICLIST
so maybe he can give you more details.
The ETI programmer will program 5x,6x,7x etc. and future devices
using the serial port on a PC. It is cheap because it uses separate
sockets for 18,28 and 40 pin devices, and therefore has no
voltage switching on programming and supply pins.
If you want the code and circuit diagram drop me a line and I'll
send it to you. The circuit is unfortunately only available in
Designer 4.1 format, conversion to other formats seems to always
result in a fatal flaw like all components jet black!
I bought a Xeltek Rom Master because I heard it programms PIC
microcontrollers. It only does the 16c5x stuff but I want to program
the 16c84. Does anyone know if there are drivers available or enough
info that I could write one? Xeltek says that it won't program them
but I think the hardware is there and they don't want the $100 dollar
Rom Master to compete with the $500 dollar Super Pro too much.
The ETI programmer will program 5x,6x,7x etc. and future devices
using the serial port on a PC. It is cheap because it uses separate
sockets for 18,28 and 40 pin devices, and therefore has no
voltage switching on programming and supply pins.
If you want the code and circuit diagram drop me a line and I'll
send it to you. The circuit is unfortunately only available in
Designer 4.1 format, conversion to other formats seems to always
result in a fatal flaw like all components jet black!
>The ETI programmer will program 5x,6x,7x etc. and future devices
>
>If you want the code and circuit diagram drop me a line and I'll
>send it to you. The circuit is unfortunately only available in
Robin, I would be very interested in the above info and I have designer too..
> Uh, how about posting in a format that is useable?
I wasn't the poster, and I may be jumping in here without looking,
but base64 is "the" standard MIME encoding format. If you're using
Unix, then you owe it to yourself to get the latest version of elm,
with the metamail add-on to allow it to handle MIME. If using Windows,
just about any windows mail program will handle MIME (e.g. Pegasus Mail).
> Uh, how about posting in a format that is useable?
Base64 is emminently useable, portable, and standardized. The SMTP
protocol specifically limits itself to 7-bit ASCII data (see RFC 821).
Without prior negotiation and agreement, the transfer of 8-bit binary
data is prohibit. If forced, it will cause interoperability problems.
So 8-bit data must be converted to 7-bit for safe transport through
the email networks of the world. Uuencode doesn't qualify since it is
non-standard (multiple, incompatible implementations) & uses characters
that may not translate into non-ASCII (i.e. EBCDIC on big IBM hardware).
MIME (see RFC 1521) is the Internet standards-track way that SMTP has
been extended to handle the transport of multi-part and/or binary data
Base64 is a required part of MIME. It is well defined. Any modern
email user agent (UA) will transparently decode base64 as the message
is read. If you are unwilling or unable to upgrade your UA, there are
several stand-alone base64 decoders available (for PC, Unix, Mac, etc).
Lee
-------------------------------------------------------------------
Jones Computer Communications .....leeRemoveMEfrumble.claremont.edu
509 Black Hills Dr, Claremont, CA 91711 voice: 909-621-9008
-------------------------------------------------------------------
In response to the question about how the Basic Stamp measures
pot resistance:
The Basic stamp POT command actually measures discharge time for
an RC circuit rather than resistance per se. By using a constant
capacitance value (like .1 uf) in series with an unknown
resistance, the resistance can be measured by determining how
long the capacitor takes to discharge after it has been fully
charged and then connected to ground through the resistor. In
the Basic Stamp, a pin is taken high to charge the capacitor,
and then put in input mode to trigger when the capacitor
discharges to below the threshold voltage of the pin gate. This
setup can be made more accurate by including a separate resistor
of a known value on a different pin to calibrate the circuit for
temperature changes. See AN512 in the imbedded control handbook.
Anyone know of a vendor that makes a ZIF type socket for SOIC cased
PICs? I own a Parallax programmer and want to save some $$ and make my
own adaptor boards. I need 18 and 28 pin sockets.
Thanks
John P. Hollingshead, said he is
> ...looking for a programming language reference, for a PIC 16C84.
I think the Microchip Microcontroller Databook (rel. 95/96) and
the Embedded Control Handbook are still the best and most
comprehensive reference you can get.
You can either ask any local distributor or get them electronically
from microchip's bbs or now from their ftp-server in pdf-format
or have a look at the www-site for an index of available documents:
http://www.ultranet.com/biz/mchip
ftp://ftp.ultranet.com/biz/mchip
documents in subdirectory /lit, filename == microchip document number
>Can anyone send me a *COMPRESSED* (LHA or PKZIP) PDF (Acrobat format) file
>of the PIC16CXX Programming Specification Document?
>
>I cannot use the modem to connect to Microchip's BBS for company policy
>reason.
If you can use the modem to access the Internet, then you can get it through
the WWW. Just point your browser at http://www.ultranet.com/biz/mchip/
and you can get everything you need from there.
>Can anyone send me a *COMPRESSED* (LHA or PKZIP) PDF (Acrobat format) file
>of the PIC16CXX Programming Specification Document?
>
>I cannot use the modem to connect to Microchip's BBS for company policy
>reason.
If you can use the modem to access the Internet, then you can get it through
the WWW. Just point your browser at http://www.ultranet.com/biz/mchip/
and you can get everything you need from there.
>>Can anyone send me a *COMPRESSED* (LHA or PKZIP) PDF (Acrobat format) file
>>of the PIC16CXX Programming Specification Document?
>>
>>I cannot use the modem to connect to Microchip's BBS for company policy
>>reason.
>If you can use the modem to access the Internet, then you can get it through
>the WWW. Just point your browser at
>http://www.ultranet.com/biz/mchip/
>and you can get everything you need from there.
I'm getting to be really ashamed here.
You see, we pay in terms of the number of bytes transfered and our
internet accesses are limited to e-mail only--so I cannot use the web.
Anyway, thanks for the help. I know you are all busy.
On Tue, 21 Nov 1995 22:53:19 -0500 (EST) Joel Carvajal <spamBeGonejoelspam_OUTRemoveMEtds.pfi.net> wrote:
:
: I'm getting to be really ashamed here.
:
: You see, we pay in terms of the number of bytes transfered and our
: internet accesses are limited to e-mail only--so I cannot use the web.
:
: Anyway, thanks for the help. I know you are all busy.
:
: Joel C.
: .....joelRemoveMEtds.co.jp
:
Without putting to fine a point on it joel, if the technology company you
are working for is this restrictive about access to the worlds biggest
information repository (I speak of the web), then you should be looking
at joining another company!!;-)
Peter Westley .-_!\ Email: peterj@spam@hpato.aus.hp.com
Australian Telecom Operation / \ Phone: +61 3 9210 5548
Hewlett-Packard Australia Ltd \_.-._/ Fax: +61 3 9210 5550
RF: VK3DXD v GPS: 37 48'44"S 145 8'51"E
--
Views expressed are mine and do not reflect those of Hewlett Packard Co.
I know this is going beyond the interest of the PICLIST, but I felt the
following comment couldn't go without an answer:
>Without putting to fine a point on it joel, if the technology company you
>are working for is this restrictive about access to the worlds biggest
>information repository (I speak of the web), then you should be looking
>at joining another company!!;-)
The company I work for is very restrictive, i.e. we have only two terminals
for internet access for 2000 employees despite a site wide network. It is
a world wide known electronics manufacturer, but has good reasons for
restricting access:
1) We are continuously bidding for contracts worth from millions to (in some
cases) thousands of millions of dollars. You have to TRUST firewalls to
risk that kind of money, and secondly there is always the risk of
disgruntled (or bribed) employees posting design documentation out of
the company.
2) A separate division of the company allowed full internet access and
discovered some of its employees spending as much as 10% of their time
wondering the net - somewhat of a productivity drop !
>I just built an RS-232 powered 16C84 programmer (the one with 1
>diode, 1 cap, 1 78L05, and 3 resistors), but I'm having some problems
>with it. The 78L05 sucks the tx line (and thus MCLR) down to about 7
>volts, which is apparently not enough to kick it into programming
The 16C84 needs about 10.5 to 11V to switch to programming mode.
My original design uses a resistor and a Zener-diode, because I had the same
problem with the 78L05.
TxD ---*-----------------------------
(2) I I
--- ---
I I I I
I I 2k2 I I 10k
--- 1N4148 ---
I I\I I
*-------I-I-----*--------- I
I I/I I I I
----\ I + I I
/\ \ --- 14 I I 4
/ \ 5V6 --- --------------
---- 100u I I Vdd Vpp I
I I I I
I I 5 I I
GND ---*---------------*----I Vss I
(7) 22k I I
----- 12 I I
RTS ---------I I----------IRB6 (clock) I
(4) ----- I I
----- 13 I I
DTR ---------I I----*-----IRB7 (data) I
(20) ----- I I I
2k2 I I PIC 16C84 I
CTS ------------------I I------------I
(5)
This should work. If not, try to vary the resistor between DTR and CTS.
You wrote:
>
> * Patrick C Leger <blah+@ANDREW.CMU.EDU> wrote:
>
>
>>I just built an RS-232 powered 16C84 programmer (the one with 1
>>diode, 1 cap, 1 78L05, and 3 resistors), but I'm having some problems
>>with it. The 78L05 sucks the tx line (and thus MCLR) down to about 7
>>volts, which is apparently not enough to kick it into programming
>
>The 16C84 needs about 10.5 to 11V to switch to programming mode.
>My original design uses a resistor and a Zener-diode, because I had
the same {Quote hidden}
>problem with the 78L05.
>
>
> TxD ---*-----------------------------
> (2) I I
> --- ---
> I I I I
> I I 2k2 I I 10k
> --- 1N4148 ---
> I I\I I
> *-------I-I-----*--------- I
> I I/I I I I
> ----\ I + I I
> /\ \ --- 14 I I 4
> / \ 5V6 --- --------------
> ---- 100u I I Vdd Vpp I
> I I I I
> I I 5 I I
> GND ---*---------------*----I Vss I
> (7) 22k I I
> ----- 12 I I
> RTS ---------I I----------IRB6 (clock) I
> (4) ----- I I
> ----- 13 I I
> DTR ---------I I----*-----IRB7 (data) I
> (20) ----- I I I
> 2k2 I I PIC 16C84 I
> CTS ------------------I I------------I
> (5)
>
>
>
>This should work. If not, try to vary the resistor between DTR and
CTS.
>
> - Erik
>___ Terminate 1.51
>
Do you use a public domain programming package (sw) ?
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. (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.
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.
Nothing like diving in head first on your first PIC project at work, eh?
Thanks in advance,
Chris
----------------------------------------------------------------------------
|Check out my WWW page at http://www.access.digex.net/~cps/ for ham radio |
|software for the Mac; Free Radio, Shortwave Radio, and Spy Numbers Stations |
|information. |
|Finger me (EraseMEcpsRemoveMESTOPspamaccess.digex.net) for my PGP Public Key |
----------------------------------------------------------------------------
"Those who would gladly sacrifice liberty for security deserve neither."
-Ben Franklin
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"
> Programming speed isn't an issue. If it takes even a half an hour to
> program all 256 PICs, that's OK. (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.
The following suggestion may or may not work; I make no guarantees:
[1] Use eight drivers for D6, eight drivers for D7, and four for /MCLR.
Arrange the chips in an 8x8x4 matrix [256 total].
[2] To program an individual chip, raise its /MCLR line to 12 volts while
grounding the other three, and send out clock and data signals on its
clock and data pins while leaving the other ones alone.
[3] You can probably program several chips at once, and verify them using
a different pattern. I'd suggest programming four at once [raise all
for /MCLR's to 12 volts for programming, then use one D6/D7 pair at a
time to program the chips] and then verifying the chips either one at
a time or eight at a time [all the chips associated with a given /MCLR
/D6 pair simultaneously]. If your /MCLR +12 supplies are beefy enough
you may be able to program 32 at a time [use the same /D7 wire for all
32 and stagger the clocks to ensure they don't all switch on their VPP
supply simultaneously].
> 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.
Not a bad idea...
> Nothing like diving in head first on your first PIC project at work, eh?
I am searching for a good book on programming with the PIC. I have
looked through the Microchip manual and embedded controller handbook.
Code examples are somewhat hard to follow. I have an idea of what
the commands are but thats about it. I want to start programming
this thing. I finally have my software flowchart completed. It is
figuring out the code that is becoming a huge obstacle. I
would appreciate any info or advice.
>I am searching for a good book on programming with the PIC. I have
>looked through the Microchip manual and embedded controller handbook.
>Code examples are somewhat hard to follow. I have an idea of what
>the commands are but thats about it. I want to start programming
>this thing. I finally have my software flowchart completed. It is
>figuring out the code that is becoming a huge obstacle. I
>would appreciate any info or advice.
I would say that the instruction set is so small in the low-range series,
you can easily remember all instructions after a while.
How long is "a while"? It depends on how often you make programs and how
often you use every specific instruction.
I started reading the general specifications for every uC in the data book
and came to the conclusion that it was too little program memory (I also
write c/c++ programs under unix/dos and whatever you do, the executable will
soon reach 100kb or even 1Mb). Anyway, I chose the '54 because I could
always move up to the '84 or '58 in case of memory overflow. Then I read
about all special registers and later, all instructions to get a clue what
they were doing. It's easier than you might think to use these instructions.
> I am searching for a good book on programming with the PIC. I have
> looked through the Microchip manual and embedded controller handbook.
> Code examples are somewhat hard to follow. I have an idea of what
> the commands are but thats about it. I want to start programming
> this thing. I finally have my software flowchart completed. It is
> figuring out the code that is becoming a huge obstacle. I
> would appreciate any info or advice.
>
> Neil Gandler
>
I know this is going to sound strange, but if you have looked at the
code examples and the instruction set, just dive in and start writing
code. You will find code fragments in the manual that should let you
do most of the basic things you need to do. I know that it looked rather
daunting to me until I actually sat down and started dealing with the
assembly language. It really is pretty simple. The assembly is MUCH
simpler than doing 80x86 code.
Roger (I would be willing to help but remember I only have about 5 hours
experience programming at this time.)
First, I am terribly sorry of the rude accidental posting I did.
I was NOT aware of the fact that a reply to a message on the piclist would
arrive on the pic-list.
Hereby I want to apologise myself to anyone I have offended by my 'junk' mail.
Again, sorry. I wish I could turn back the clock.
Now to the topic...
I want to be able to do some in circuit serial (re)programming of a
circuit I have. In general, I want to experiment with the fact that a '84 can
be programmed whilst in the target circuit.
The circuit consists of a 16c84, vdd is directly connected to vpp.
Now my question is, is this possible? I personally don't think so
'coz vdd needs to be 5v and vpp needs to be 13.5v.
I think I will blow it up while trying to program this circuit.
But maybe not, I don't want to throw away my picstart 16b, nor the '84.
Is it possible with extra circuitery?
Should the circuit contain an extra resistor between vdd and vpp and if yes
what value?
How long can the programmer to '84 cable be in general?
I want to be able to use quite a long cable (1 meter), are there any things
I should be aware of?
I was also wondering, has the picstart16b1 the ability to do in circuit
serial programming or do I need a special programmer?
If yes, what kits are out there with this ability? (commercial and diy)
Many questions, I hope one of you specialists can help me.
Thanks in advance.
--
****************************************************************************
* -= Dennis Velthuis =- -= RemoveMEdenvKILLspamTakeThisOuThtsa.hva.nl =- *
* -= Raving His Way Into Tha Future ;) =- *
* -= http://htsa.htsa.hva.nl/~denv =-
* -= U Have The Right to Exchange Information, So Use This Right! =- *
****************************************************************************
>Now to the topic...
>
>I want to be able to do some in circuit serial (re)programming of a
>circuit I have. In general, I want to experiment with the fact that a '84 can
>be programmed whilst in the target circuit.
>The circuit consists of a 16c84, vdd is directly connected to vpp.
>
>Now my question is, is this possible? I personally don't think so
>'coz vdd needs to be 5v and vpp needs to be 13.5v.
>I think I will blow it up while trying to program this circuit.
>But maybe not, I don't want to throw away my picstart 16b, nor the '84.
>Is it possible with extra circuitery?
>Should the circuit contain an extra resistor between vdd and vpp and if yes
>what value?
Yes. The value can be 4K7-22K. 10K is good. Some people use a diode but a
resistor is better as it allow ESD to discharge. ESD on the Vpp pin CAN
scramble the memory!
>
>How long can the programmer to '84 cable be in general?
>I want to be able to use quite a long cable (1 meter), are there any things
>I should be aware of?
I meter long cable probably won't cause to many problems but this is a
matter I'm not expert on. There is nothing extra to consider just because
you are actually programming a chip. The usual data comms considerations
apply. I'm to uneducated to say much more.
>I was also wondering, has the picstart16b1 the ability to do in circuit
>serial programming or do I need a special programmer?
>If yes, what kits are out there with this ability? (commercial and diy)
The PICSTART 16B used the serial method of programming (I think!) BUT this
is not necessarily the same as ISP. Maybe you can experiment and get the
PICSTART to program in-system.
It should be possible. Just don't load RB6 and RB7 on the target.
I recommend you start with the 16C84 in a bare socket (and the Vdd-Vpp
resistor) and bring GND (5), Vdd (15), Vpp (4) RB6 (13) and RB7(14) across
to it. Get it working in the socket first to verify the use of the serial
program method and correct wiring THEN transpose to you target. This way you
can track where problem occur. Pin numbers in () are for the 16C84.
There are many kit programmers that will program the 16C84 in-system but I
feel you should be able get the PICSTART to do what you want.
>
>Many questions, I hope one of you specialists can help me.
Me, a "specialist?" A title at last?!
>
>Thanks in advance.
>
> >Should the circuit contain an extra resistor between vdd and vpp and if yes
> >what value?
>
> Yes. The value can be 4K7-22K. 10K is good. Some people use a diode but a
> resistor is better as it allow ESD to discharge. ESD on the Vpp pin CAN
> scramble the memory!
>
Hi,
While it will limit any current flow to a fairly harmless level, a
resistor alone will not prevent the Vpp voltage appearing on the 5 volt
Vdd supply line. I prefer to use a diode and resistor in series. The
programmer should hold Vpp to ground before applying the actual Vpp in
programming mode thus providing an ESD path.
>On Thu, 21 Mar 1996, Newfound Electronics wrote:
>
>> >Should the circuit contain an extra resistor between vdd and vpp and if yes
>> >what value?
>>
>> Yes. The value can be 4K7-22K. 10K is good. Some people use a diode but a
>> resistor is better as it allow ESD to discharge. ESD on the Vpp pin CAN
>> scramble the memory!
>>
>Hi,
>
>While it will limit any current flow to a fairly harmless level, a
>resistor alone will not prevent the Vpp voltage appearing on the 5 volt
>Vdd supply line. I prefer to use a diode and resistor in series. The
>programmer should hold Vpp to ground before applying the actual Vpp in
>programming mode thus providing an ESD path.
Dermot,
At no stage should there be Vpp applied without Vdd. It is the presence of
Vdd that stops Vpp appearing on the Vdd pin. I would be VERY concerned if
any programmer applied Vpp without Vdd.
Regarding ESD. While the programmer may hold Vpp at ground, what about when
it is not connected? This is when ESD "scrambling" can occur. I know it less
likely if the usual preventative measures are taken, BUT I know it has
happened and it appears to happen at ESD levels that ordinarily wouldn't
harm the rest of the componentry. IMHO the resistor method has no drawbacks
and does serve to prevent such occurences. I can see only positives for it
myself. However, many people do use the diode without to many problems.
BTW The "victim" in the case I know of had to reprogram 100 16C84 based
boards again. Ouch!
> At no stage should there be Vpp applied without Vdd. It is the presence of
> Vdd that stops Vpp appearing on the Vdd pin. I would be VERY concerned if
> any programmer applied Vpp without Vdd.
Hi Jim,
I think we may be at cross purposes here. The original inquiry (as I
understood it) was about a circuit that had Vpp hard-wired to Vdd,
presumably to hold MCLR* high in normal operation. Thus the Vpp voltage
level would appear on the Vdd line. However even with a large value
resistance between Vpp/MCLR* and Vdd, the programming voltage can still
appear on Vdd.
>
> Regarding ESD. While the programmer may hold Vpp at ground, what about when
> it is not connected? This is when ESD "scrambling" can occur. I know it less
> likely if the usual preventative measures are taken, BUT I know it has
> happened and it appears to happen at ESD levels that ordinarily wouldn't
> harm the rest of the componentry. IMHO the resistor method has no drawbacks
> and does serve to prevent such occurences. I can see only positives for it
> myself. However, many people do use the diode without to many problems.
Obviously if the resistor alone works well, it's a matter of choice, but
personally, I would be very wary of not using a diode/resistor combination,
with perhaps a
higher value resistor to Vss for additional ESD discharge purposes.
>
> BTW The "victim" in the case I know of had to reprogram 100 16C84 based
> boards again. Ouch!
>I want to be able to do some in circuit serial (re)programming of a
>circuit I have. In general, I want to experiment with the fact that a '84 can
>be programmed whilst in the target circuit.
While I can not answer your question, or because I can not
answer your question, I have an alternative for you.
The Basic Stamp does what you want. It is a pic programmed
with an interperter. The basic tokens are storred in serial
eeprom. To program a '84' for such a function may not be
practical because of development time and/or memory,
But the concept may be a good one to use.
The 64 bytes of eeprom data could hold I/O pin configuations
and/or data constants. Also the data eeprom could contain tokens
to control program flow. (a very high level interperter?)
So if you wish to have just a reconfiguable program or I/O, then
the only cost would be the serial interface program and its I/O pins.
I do not know for what purpose you wish to reprogram the PIC, but
the concept is interesting. I have written a program for the IBM PC
that is a platform for testing methods of solving mazes. The program
accepts commands such as "go right", "turn left", and "test foward".
The program returns a true if the command was excuited or a false if
there was an obstruction in the way. I then added a celluar automata
routine with a eight by eight matrix program to run the maze. This
became a self learning program for the "maze runner" and had good
results. Could this "self learning" feature be implimented on a PIC?
>>
>>I want to be able to do some in circuit serial (re)programming of a
>>circuit I have. In general, I want to experiment with the fact that a '84 can
>>be programmed whilst in the target circuit.
>>The circuit consists of a 16c84, vdd is directly connected to vpp.
>>
>>Now my question is, is this possible? I personally don't think so
>>'coz vdd needs to be 5v and vpp needs to be 13.5v.
>>I think I will blow it up while trying to program this circuit.
>>But maybe not, I don't want to throw away my picstart 16b, nor the '84.
>
>
>>Is it possible with extra circuitery?
>
>>Should the circuit contain an extra resistor between vdd and vpp and if yes
>>what value?
>
>Yes. The value can be 4K7-22K. 10K is good. Some people use a diode but a
>resistor is better as it allow ESD to discharge. ESD on the Vpp pin CAN
>scramble the memory!
When I tried this, I had problems getting the circuit to program correctly.
I added a jumper that connects the Vdd of the chip to the rest of the
circuit. When I need to program, I remove the jumper before attaching
the programmer. This has worked so far. I currently don't have anything
attached to the programming clock and data pins (RB6,RB7) in my circuit. I do
have the diode from circuit Vdd to the MCLR pin to protect the rest of the
circuit while programming. BTW I am using the ITU PIC-1 programmer but if
your programmer uses serial programming, the same should apply.
>
>>
>>How long can the programmer to '84 cable be in general?
>>I want to be able to use quite a long cable (1 meter), are there any things
>>I should be aware of?
The signal is serial but the voltage levels are not the same as
EIA-232 (AKA RS-232). The main concerns I would have is voltage drop for
a 1m run and cross talk from the clock and data signals. Cross talk can
be minimized by using sheilded twisted pair (STP) cable but you may not be
able to compensate for voltage drop. Try it and see.
>>I was also wondering, has the picstart16b1 the ability to do in circuit
>>serial programming or do I need a special programmer?
>>If yes, what kits are out there with this ability? (commercial and diy)
Don't know if PICSTART can do serial programming but the PIC-1 from ITU can.
If you can wirewrap the programmer, buy the plans and software package only
since the circuit is quite simple. I bought the full kit and am quite pleased
with it. ITU even responded to my sugesstions to improve the kit.
>
>I recommend you start with the 16C84 in a bare socket (and the Vdd-Vpp
>resistor) and bring GND (5), Vdd (15), Vpp (4) RB6 (13) and RB7(14) across
>to it. Get it working in the socket first to verify the use of the serial
>program method and correct wiring THEN transpose to you target. This way you
>can track where problem occur. Pin numbers in () are for the 16C84.
>
This is great advice. When my first attempts to program in circuit failed,
I had to go back and take things off until I found the problem. Would have
been much smarter to approach it this way.
BTW in circuit programming is the only way to go. I can program the chip, test
it find my bugs and reprogram it in a few mins.
>On Thu, 21 Mar 1996, Newfound Electronics wrote:
>
>> At no stage should there be Vpp applied without Vdd. It is the presence of
>> Vdd that stops Vpp appearing on the Vdd pin. I would be VERY concerned if
>> any programmer applied Vpp without Vdd.
>
>Hi Jim,
>
>I think we may be at cross purposes here. The original inquiry (as I
>understood it) was about a circuit that had Vpp hard-wired to Vdd,
Dermot,
Yes, that WAS the case but had been dealt with before we came to the diode V
resistor bit. It had to be otherwise ISP is not possible.
>presumably to hold MCLR* high in normal operation. Thus the Vpp voltage
>level would appear on the Vdd line. However even with a large value
>resistance between Vpp/MCLR* and Vdd, the programming voltage can still
>appear on Vdd.
I don't know what you mean Dermot. To my understanding we have a low
impedence source controling Vdd and a high impedence source from Vpp/MCLR.
The voltage difference is dropped across the resistor. What could I be
missing? At worst Vpp contributes a little extra current, Right??
>
>>
>> Regarding ESD. While the programmer may hold Vpp at ground, what about when
>> it is not connected? This is when ESD "scrambling" can occur. I know it less
>> likely if the usual preventative measures are taken, BUT I know it has
>> happened and it appears to happen at ESD levels that ordinarily wouldn't
>> harm the rest of the componentry. IMHO the resistor method has no drawbacks
>> and does serve to prevent such occurences. I can see only positives for it
>> myself. However, many people do use the diode without to many problems.
>
>Obviously if the resistor alone works well, it's a matter of choice, but
>personally, I would be very wary of not using a diode/resistor combination,
>with perhaps a
>higher value resistor to Vss for additional ESD discharge purposes.
I guess it is a matter of choice and just as you are wary, I too, am wary of
the diode. For 16C84 systems I tend to leave it out.
In the case I am refering to, the victim subjected his PCBs to a finishing
proceedure. Before he discovered my programmer he use to program within the
programmer and tranfer the chips. When he got my programmer with the ISP
option he modified his circuit and added the diode (I told him to). When he
used the same finishing proceedure this is when the 16C84 scrambled. (And I
coped an ear full!)
He is now using just a resistor with no further problems.
So maybe under normal circumstances, the diode is ok. But in my view the
resistor is safe and eliminates the possibility.
BTW. The ESD problem with the 16C84 occurs because it requires so little
current to enter the program mode. It doesn't tend to happen on the EPROM
based PICs which require more oumph (did I spell that right?) on the Vpp pin.
>>Yes. The value can be 4K7-22K. 10K is good. Some people use a diode but a
>>resistor is better as it allow ESD to discharge. ESD on the Vpp pin CAN
>>scramble the memory!
>
>When I tried this, I had problems getting the circuit to program correctly.
>I added a jumper that connects the Vdd of the chip to the rest of the
>circuit. When I need to program, I remove the jumper before attaching
>the programmer. This has worked so far. I currently don't have anything
>attached to the programming clock and data pins (RB6,RB7) in my circuit. I do
>have the diode from circuit Vdd to the MCLR pin to protect the rest of the
>circuit while programming. BTW I am using the ITU PIC-1 programmer but if
>your programmer uses serial programming, the same should apply.
Norm,
Have you tried reducing or eliminating the 100R resistor (R11 on my ITU
programmer) This might fix you problem and eliminate the need for the Vdd
jumper. This 100R resistor was discussed a month or two ago on the piclist.
>
>>>I was also wondering, has the picstart16b1 the ability to do in circuit
>>>serial programming or do I need a special programmer?
>>>If yes, what kits are out there with this ability? (commercial and diy)
>
>Don't know if PICSTART can do serial programming but the PIC-1 from ITU can.
>If you can wirewrap the programmer, buy the plans and software package only
>since the circuit is quite simple. I bought the full kit and am quite pleased
>with it. ITU even responded to my sugesstions to improve the kit.
Yes, the new PCB looks very impressive and the ITU programmer has been well
supported.
>>I recommend you start with the 16C84 in a bare socket (and the Vdd-Vpp
>>resistor) and bring GND (5), Vdd (15), Vpp (4) RB6 (13) and RB7(14) across
>>to it. Get it working in the socket first to verify the use of the serial
>>program method and correct wiring THEN transpose to you target. This way you
>>can track where problem occur. Pin numbers in () are for the 16C84.
>>
>
>This is great advice. When my first attempts to program in circuit failed,
>I had to go back and take things off until I found the problem. Would have
>been much smarter to approach it this way.
>
>
>Norm
>RemoveMEcramerspam_OUTdseg.ti.com
>
>>
>>When I tried this, I had problems getting the circuit to program correctly.
>>I added a jumper that connects the Vdd of the chip to the rest of the
>>circuit. When I need to program, I remove the jumper before attaching
>>the programmer. This has worked so far. I currently don't have anything
>>attached to the programming clock and data pins (RB6,RB7) in my circuit. I do
>>have the diode from circuit Vdd to the MCLR pin to protect the rest of the
>>circuit while programming. BTW I am using the ITU PIC-1 programmer but if
>>your programmer uses serial programming, the same should apply.
>
>Norm,
>
>Have you tried reducing or eliminating the 100R resistor (R11 on my ITU
>programmer) This might fix you problem and eliminate the need for the Vdd
>jumper. This 100R resistor was discussed a month or two ago on the piclist.
I'll check, I remember that I did not install one of the resistors but don't
remember wich one. I'll see if it was R11. Thanks for the tip.
> >How long can the programmer to '84 cable be in general?
> >I want to be able to use quite a long cable (1 meter), are there any things
> >I should be aware of?
>
> I meter long cable probably won't cause to many problems but this is a
> matter I'm not expert on. There is nothing extra to consider just because
> you are actually programming a chip. The usual data comms considerations
> apply. I'm to uneducated to say much more.
The cable length is limitted primarily by:
[1] What speed do you send the data; the lower the speed the longer the cable
can be.
[2] If you want to RUN the processor with the ISP cable hooked up [often very
handy during development], what sort of protection is there on /MCLR to
prevent spontaneous glitches?
> Hello.
>
> First, I am terribly sorry of the rude accidental posting I did.
> I was NOT aware of the fact that a reply to a message on the piclist would
> arrive on the pic-list.
> Hereby I want to apologise myself to anyone I have offended by my 'junk' mail.
> Again, sorry. I wish I could turn back the clock.
I'm sure the list understands now what really took place Dennis. Yes put
it behind you. Take Andy's advice and ignore/delete all SPAMS and they will
stop.
>
> Now to the topic...
>
> I want to be able to do some in circuit serial (re)programming of a
> circuit I have. In general, I want to experiment with the fact that a '84 can
> be programmed whilst in the target circuit.
> The circuit consists of a 16c84, vdd is directly connected to vpp.
>
> Now my question is, is this possible? I personally don't think so
> 'coz vdd needs to be 5v and vpp needs to be 13.5v.
> I think I will blow it up while trying to program this circuit.
> But maybe not, I don't want to throw away my picstart 16b, nor the '84.
>
> Is it possible with extra circuitery?
> Should the circuit contain an extra resistor between vdd and vpp and if yes
> what value?
My 84 programmer uses a bulldozer approach for this task. It hardware
switches everthing. It may not suit your setup but the circuit can be
examined at http://www.labyrinth.net.au/~donmck
This may give you some ideas.
I have often thought of getting one of those cheap DB-25 two way switch
boxes and wiring it up as follows:
Connect an 18 pin socket to a DB-25 plug so it can accept the 84 device
and plug this into the common leg of the switch.
Crimp two flat ribbon cables with DIP headers one end and DB-25's the
other. One cable connects to your target, the other to your Picstart or
any programmer. You now have a load/run switch.
Cables, I keep them as short as possible. For me that means 6 inches.
With a few well place diodes you should not have any trouble with
doing an in circuit programming. You may want to make sure that
your oscillator is off while programming. I had trouble with
it incrementing the program locations. So instead of starting a
0x0000, the program would load randomly from 0x0001 to 0x0010.
Once I disabled the oscillator, everything worked great. I think
that you should still be able to use your picstart. If you can't,
you could always build David Taite's programmer.
> I don't know what you mean Dermot. To my understanding we have a low
> impedence source controling Vdd and a high impedence source from Vpp/MCLR.
> The voltage difference is dropped across the resistor. What could I be
> missing? At worst Vpp contributes a little extra current, Right??
Hi Jim,
Yes, It's my logic that's a little fuzzy. I'm thinking in terms of the
circuit I'm currently working on where the programming voltage is derived
from a different source to the PIC Vdd supply line which itself contains a
blocking diode. Your description relates to the PIC deriving Vpp and Vdd
from the programmer, clearly a better arrangement.
I'll bear this, and the potential 16C84 ESD problem, in mind in any future
designs.
I have sent this question to Microchip some weeks ago, but they choose not to
respond. Likewise, the local Microchip rep also chose to ignore me, so I hope
someone on this list can help.
I am using MPASM with a 16B1 PICSTART kit to program a 16C84. I want to program
the
E^2 data memory using the 16B1. I know that it can be done by first running a
small program
which dumps the data into the E^2 data memory and then erasing the program
memory and
programming it with the final code. I don't want to use this method since I can
not see
why the 16B1 kit should not be able to program the E^2 data directly. Looking
at the
programming spec for the 84 leads me to belive that there is nothing difficult
about programming the data space in the 84. Is it possible to program the E^2
data directly using the 16B1?
After looking through the MPASM.HLP file which comes with MPLAB, I found a
command,
"DE" which is used to define EEQ^2 data from within MPSAM. I don't have an 84
to try
this on right now. Has anyone tried to use this command? Does the 16B1
software
recognise the embedded E^2 data? Does it program the E^2 data in thew 84
accordingly?
MPASM can generate the information for the EEPROM data memory like so:
ORG 0x2100
DE "Here's my data", 0
DE 1, 2, 3
However, PICSTART does not support programming of the data memory.
You can either use PRO MATE or wait until after May 15 for the new
PICSTART Plus, which works under MPLAB and will support programming of
the EEPROM data memory.
Kim Cooper
Microchip Technology
______________________________ Reply Separator _________________________________
Subject: Programming the PIC16C84 data memory with the PICSTART 16B1
Author: Russell Politzky <RemoveMEpolitzkyKILLspam@spam@ICON.CO.ZA> at Internet_Exchange
Date: 4/25/96 7:41 PM
I have sent this question to Microchip some weeks ago, but they choose not to
respond. Likewise, the local Microchip rep also chose to ignore me, so I hope
someone on this list can help.
I am using MPASM with a 16B1 PICSTART kit to program a 16C84. I want to program
the
E^2 data memory using the 16B1. I know that it can be done by first running a
small program
which dumps the data into the E^2 data memory and then erasing the program
memory and
programming it with the final code. I don't want to use this method since I can
not see
why the 16B1 kit should not be able to program the E^2 data directly. Looking
at the
programming spec for the 84 leads me to belive that there is nothing difficult
about programming the data space in the 84. Is it possible to program the E^2
data directly using the 16B1?
After looking through the MPASM.HLP file which comes with MPLAB, I found a
command,
"DE" which is used to define EEQ^2 data from within MPSAM. I don't have an 84
to try
this on right now. Has anyone tried to use this command? Does the 16B1
software
recognise the embedded E^2 data? Does it program the E^2 data in thew 84
accordingly?
We are looking for an automated chip handler/programmer for programming
>>10K pics (5x/6x/8x and probably others, DIP & SOIC). New or used. While we
have looked into QTP & masked rom, we want to program in-house. Does anyone
have any references/experience? XTRON (sp?) has been mentioned to me. Does
anyone have their address? Tnx for any help (email me or post to list).
-----------------------------------------------------------------
Al Johnson
Norsat International Inc.
Compuserve: 74503,1014
Internet: KILLspamajohnson.....norsat.com
-----------------------------------------------------------------
So, why didn't they include the various programmers, or at least
MPstart ? I will admit its nice to edit and assemble within the same
window now, but I still have to min the window and jump into the DOS
window to run the programmer - unless I'm missing something here.
BTW, I have yet to see any crashes running it on 3 different machines
(all 486 jobs).
> So, why didn't they include the various programmers, or at least
> MPstart ? I will admit its nice to edit and assemble within the same
> window now, but I still have to min the window and jump into the DOS
> window to run the programmer - unless I'm missing something here.
> BTW, I have yet to see any crashes running it on 3 different machines
> (all 486 jobs).
>
Someone asked if they planned to support the PICSTART and they said
no.
**********************************************************
*Mike DeMetz SYSCON International *
*spam_OUTmikedKILLspamsyscon-intl.com South Bend, IN USA *
*aka RemoveME73165.1230RemoveMEEraseMEcompuserve.com using Pegasus Mail *
**********************************************************
Harrison Cooper wrote:
>
> So, why didn't they include the various programmers, or at least
> MPstart ? I will admit its nice to edit and assemble within the same
> window now, but I still have to min the window and jump into the DOS
> window to run the programmer - unless I'm missing something here.
> BTW, I have yet to see any crashes running it on 3 different machines
> (all 486 jobs).
The Mpstart is included. Just run it from the Icon in the same
directory.
> > So, why didn't they include the various programmers, or at least
> > MPstart ? I will admit its nice to edit and assemble within the
> > same window now, but I still have to min the window and jump into
> > the DOS window to run the programmer - unless I'm missing
> > something here. BTW, I have yet to see any crashes running it on 3
> > different machines (all 486 jobs).
>
> Someone asked if they planned to support the PICSTART and they said
> no.
Guys:
MPLAB supports the Picstart Plus now, and soon will support the PRO
MATE and PRO MATE II.
I recently purchased ITU technologies PIC-1 programmer that claims
in their web page and also by phone that it supports in circuit programming.
After receiving the programmer, I have no idea how they expect it to work
that way. Just curious if anyone has a clue.
I have been trying, without much success, to program the data
memory in a 16C84 using the new Picstart Plus programmer under
MPLAB.
EEPROM data programming is supported by the Picstart Plus, at
least according to the menus. What I have seen is that the
data that gets written is always 'FF', regardless of the data
in the source file.
Verifying the data in the EEPROM always passes with an un-
initialized device (FF data), and fails with an open socket or
a device programmed with any other data.
A source file with EEPROM data definitions seems to assemble the
expected data, and the EEPROM window shows that data after a
build. However, the data written to the device is still all
'FF'.
Here is a simple test case which I used (after more complex
cases failed):
----<TEST.ASM>----------------------------------------------
;
; This is a test to generate EEPROM Data
;
PROCESSOR 16c84
include P16C84.inc
__CONFIG _CP_OFF & _PWRTE_ON & _WDT_OFF & _HS_OSC
org 2100
de "NEW STUFF\r\n"
de 0,0,0,0
END
-----------------------------------------------------------
Here are the steps that I followed with this test case:
1. Open a new project and add TEST.ASM to the project list.
2. Build all files
3. Open an EEPROM window
- The "NEW STUFF.." string was shown in the window.
3. Enable the Picstart Plus and program the EEPROM data only.
- this completed and was successful.
4. Use ITU PIC-1 programmer to read the data area and write a
HEX file.
- the HEX file shows all 'FF' data.
I also took a different PIC that had other (non 'FF') data and
programmed it. The ITU verified that the data was "Hello World"
before programming, and all 'FF' after.
Previous experiments showed that I could write the correct data
to the PIC with the ITU programmer, and that the ITU reads the
data back correctly to the HEX file.
Has anyone else used the Picstart Plus to write data memory with
success? Am I missing something obvious?
> I recently purchased ITU technologies PIC-1 programmer that claims
> in their web page and also by phone that it supports in circuit programming.
> After receiving the programmer, I have no idea how they expect it to work
> that way. Just curious if anyone has a clue.
The PIC-1 supports in-circuit programming to the extent that most any
programmer for the 16Cxx chips do: the serial protocol uses only a few
pins,a nd with some care in the design of the circuit you can drive those
pins from the ITU-1 without pulling the chip from the board.
It's not described in any detail because, I suppose, they assume that
anyone who can design the circuit so that it will work with in-circuit
programming will have no problem figuring out how to connect the circuit
to the header (or the on-board DIP socket if they've dropped the header
in the 1a revision of the board). I think there are some hints in the
device's programming spec from Microchip. Basically, you have to design
so that the programmer can provide power, the programming voltage to
MCLR, and drive RB6 and RB7 (for the 16C7x parts) without either damaging
the surrounding circuit nor being excessivley loaded down by it.
Hi to all,
Is serial programming algorithm identical to all PIC16Cx/7x devices?
I have a home build programmer and software to program PIC16C84.
Right now I need to program 16C74. It seems to me that the core
software should be the same. I am I right?
regards
janusz.
>Hi to all,
>Is serial programming algorithm identical to all PIC16Cx/7x devices?
>I have a home build programmer and software to program PIC16C84.
>Right now I need to program 16C74. It seems to me that the core
>software should be the same. I am I right?
>regards
>janusz.
>
Janusz,
Yes you are right, the "CORE" algorithm is identical for the
16C6x/7x/62x/55x/PIC14000 and likely to be the same for the
PIC12000 despite this having a 5x core. (Note the 16C55x have
a 16Cxx core and are actually the same as the 16C62x devices
with the comparators and brownout removed.)
There are, however, several differences in the configuration
word programming so research this well.
The 16C5x/16C8x and 17C4x all have major differences but you
knew this of course!
I have a very fin programmer the Pocket Pic ( EPIC?) from M.E.L.
I would like to run my code thru MPLAB first and use Microchip style
opcodes but its software at the moment has a problem with the HEX file
produced by MPASM.
If there is a FTP'able programmer software source that is MPASM hex file
compatable that will work with this unit could someone point me to it please?
I think they will fix it some time and I would likely use their software
then but I really like MPASM more than the other style. For one think
the data book examples are all in MPASM.
Also anyone have any luck with the CESSIM simulator for demo for the 16c84?
I have not had much time to try it but I feed it two files the assembled with
out errors elsewhere and it generated a buch of error messages on the source
code.
David E. Queen wrote:
>
> I have a very fin programmer the Pocket Pic ( EPIC?) from M.E.L.
>
> I would like to run my code thru MPLAB first and use Microchip style
> opcodes but its software at the moment has a problem with the HEX file
> produced by MPASM.
>
> If there is a FTP'able programmer software source that is MPASM hex file
> compatable that will work with this unit could someone point me to it please?
>
> I think they will fix it some time and I would likely use their software
> then but I really like MPASM more than the other style. For one think
> the data book examples are all in MPASM.
>
> Also anyone have any luck with the CESSIM simulator for demo for the 16c84?
>
> I have not had much time to try it but I feed it two files the assembled with
> out errors elsewhere and it generated a buch of error messages on the source
> code.
I have a programmer that works in Windows and is compatible with Mplab, it's in
my homepage but if you don't have access to www I can send you via e-mail,
just let me know.
currently i'm entering the wonderful world of PIC. For the beginning,
i just want to start with a simple '84 programmer and a proto-board.
Now ZIF sockets for 18 pins are very difficult to get and they are very
expensive. So i want to use a in circuit programmer using the serial
mode. From the archive i got some advices, to disable the oscillator (in
my case a 4Mhz crystal) and to set a resitor between Vdd and Vpp.
Now to the difficult part: To aviod an additional power supply i want to
use the design of a RS232-attached programmer. Has someone experience
with this design and in circuit programming?
Thanks in advance.
Gerrit
--
Dipl.-Ing. Gerrit Gehnen KILLspamgehnenspamBeGonehni.uni-paderborn.de
Heinz Nixdorf Institut
Rechnerintegrierte Produktion
Uni-GH Paderborn
Tel. +49/5251/60-6262 Fax. +49/5251/60-6268 ...und das war's auch
schon
>I have a programmer that works in Windows and is compatible with Mplab, it's in
>my homepage but if you don't have access to www I can send you via e-mail,
>just let me know.
>
>Octavio
>--
>
Octavio,
Are you saying your programmer is compatible with MPLAB in the sense that
you can install it instead of the PICSTART plus or PROMATE?
Or did you mean to say it is compatible with MPASM and not MPLAB?
>Hello friends,
>
>currently i'm entering the wonderful world of PIC. For the beginning,
>i just want to start with a simple '84 programmer and a proto-board.
>Now ZIF sockets for 18 pins are very difficult to get and they are very
>expensive. So i want to use a in circuit programmer using the serial
>mode. From the archive i got some advices, to disable the oscillator (in
>my case a 4Mhz crystal) and to set a resitor between Vdd and Vpp.
Gerrit,
I beleive I was the person responsible for both the above recommendations.
You only need to "kill" the oscillator if there is a big >10mS delay from
the time Vdd rises to the time Vpp rises. The resistor between Vpp and Vdd
instead of a diode is only to allow for ESD that can (and has) built up on
the Vpp pin and caused the chip to scramble the EEPROM. Most people still
use the diode with good results. ESD is not allows big problem but if you
process the PCB further with spray-on lacquers and stuff, this is when
problems occur.
>
>Now to the difficult part: To aviod an additional power supply i want to
>use the design of a RS232-attached programmer. Has someone experience
>with this design and in circuit programming?
Hmmm. I have never seen a design where doing this has resulted in the 84
being programmed within the specs. No one I know of has shown how to get
both the Vpp voltage (13V) and the Vdd current (50mA) for the serial port at
the same time. Still, these programmers supposedly work even way out of
spec. But this is one thing I wont recommend.
Jim
P.S have a look at TELtronik. I thing they have a low cost '84 programmer.
P> Now to the difficult part: To aviod an additional power supply i want
P> to use the design of a RS232-attached programmer. Has someone
P> experience with this design and in circuit programming?
This is RS232-attached programmer without additional power supply, program
all serial PIC's and I2C NVRAM's (16C6X/7X/8X/14XXX/24CXX) and have
in-circuit programming capability.
There has been such an interest in 16C84 programming lately that readers may
like to know I have just issued a kit - Kit 81 - with ALL components
(including a 16C84-10/P) & software to start programming.
The 16C84 has fast become the entry point for beginners & hobbyists into uC
programming. Charles Manning published a design in Electronics Australia,
April 1996. It plugs into the parallel port of a PC.
Features:
- software is only for the 16C84.
- software can verify, load & read
- EEPROM space, program space & config fuses can be treated separately
- separate device Erase command
- Test command to test programmer hardware
- Vpp under software control
- 9V battery powered
- 16C8x Data Sheets on floppy disk
- INHX8M file format support
Full schematic, manual & instructions for beginners supplied. Components to
write your first program (flash an LED) also included. So you can build the
programmer & test it all in the one session. (You will just need a
breadboard & battery.)
As a one-time offer to readers here (until the kit gets to my distributors)
I offer the Kit at $US20 + postage. This is about half the normal price.
-----------------------------------------------------------------------------
Peter J. Crowcroft
PO Box 88458, Sham Shui Po, Hong Kong
Voice: 852-2720 0255. Fax: 852-2725 0610 Email: spamBeGonediykithk.super.net
Web: http://www.hk.super.net/~diykit
-----------------------------------------------------------------------------
> Octavio,
>
> Are you saying your programmer is compatible with MPLAB in the sense that
> you can install it instead of the PICSTART plus or PROMATE?
>
> Or did you mean to say it is compatible with MPASM and not MPLAB?
>
> Jim
Well, when I say it's compatible with MPLAB I mean it runs under windows,
so you don't need to go to Dos just to run the programmer. It doen't
appear on MPLAB menus, not yet.
I am new to the PIC world but have a lot of experience with Motorola
6800 and 68hc11. Don't think I will have much trouble getting into the
PIC. I would like one of your kits with software. How can I get the
money to you.
>Newfound Electronics wrote:
>
>> Octavio,
>>
>> Are you saying your programmer is compatible with MPLAB in the sense that
>> you can install it instead of the PICSTART plus or PROMATE?
>>
>> Or did you mean to say it is compatible with MPASM and not MPLAB?
>>
>> Jim
>
>Well, when I say it's compatible with MPLAB I mean it runs under windows,
>so you don't need to go to Dos just to run the programmer. It doen't
>appear on MPLAB menus, not yet.
>
>Octavio
>--
Octavio,
Thanks for the claification. That is what I thought you meant but wasn't
absolutely sure.
At 07:59 AM 7/9/96 PST, you wrote:
>Peter,
>
> I am new to the PIC world but have a lot of experience with Motorola
>6800 and 68hc11. Don't think I will have much trouble getting into the
>PIC. I would like one of your kits with software. How can I get the
>money to you.
>
>Jim McVay
>Yellowstone Nat'l Park, WY, USA
>TakeThisOuTkobwnspamRemoveMEjuno.com
>
Would you mind keeping private e-mail out of the list. Thanks
>There has been such an interest in 16C84 programming lately that readers may
>like to know I have just issued a kit - Kit 81 - with ALL components
>(including a 16C84-10/P) & software to start programming.
>
>
>As a one-time offer to readers here (until the kit gets to my distributors)
>I offer the Kit at $US20 + postage. This is about half the normal price.
>
OK, I'll try one. How do I arrange a credit card sale?
.....................Reg Neale.....................
"Ignorance is a renewable resource" P.J. O'Rourke
HI i have just downloaded the pip-02 programmer details i like the look
and feel of the software but although the program claims to support
othere devices there is only drivers and diagrams for the pic 16c84.
What i want to know is what hardware or drivers do i need to program
other devices ?????
PAUL B wrote:
>
> HI i have just downloaded the pip-02 programmer details i like the look
> and feel of the software but although the program claims to support
> othere devices there is only drivers and diagrams for the pic 16c84.
> What i want to know is what hardware or drivers do i need to program
> other devices ?????
>
> --
> PAUL B
Paul, the site you have come across is operated by Antti Lukats of Silicon
Studios
in Estonia. He can't come to the phone right now coz he is in the US for about 2
weeks.
May I suggest you re-post your message at a later date. The site is overdue for
a
bit of major construction, but Antti is peddling as fast as he can. :)
Or direct it to Antti in private Email at sisRemoveMEonline.ee
Don't use the address quoted on his home page. I doubt if he will get it.
EASY PIC'n Beginners Guide to using PIC 16/17 MicroChip products.
Picosaurus(tm) 40 pin PICBasic with 8 channels of A-D, and real Uart.
PIC Basic Compiler. Programmers from 15 USD. Pic-Axe(tm) A New Tool.
Ismael Ripoll wrote:
>
> I'm trying to adapt the 16c84 programmer (described in
> the Microchip's application note AN589) to program the 16c73,
> but it doesn't work.
The required algoritm to program the 16C84 and 16C73 are diferent,
the 84 need a 100ms programming pulse and the 73 need a serie of
short pulses.
Why don't you just pick my programmer in my home page?
Just a note to let the PICLIST know about a couple of new items on my
PIC archive:
o Updated software for my printer port PIC16C84 programmer.
The new C program (V-0.4) is still DOS command-line based
but is significantly better than the original.
o TOPIC: a combined development board and programmer for
the PIC16C84. The TOPIC project is aimed at people just
starting out with PICs and comes with PCB artwork.
Hello there
I have a Picstart 16C programmer board, and an application for
which I would like to use a 16C84 PIC. It seems from the documentation
that I have that the programmer will not normally do this.
I'm trying to get this little project up & running with little (/no!)
cost. From looking at the data sheets, it seems like the serial programming
modes of the 16C7xx and the 16C84, at least, are pretty similar.
My query: does anyone have information as to whether I could hack
the Picstart programmer, and/or write my own software to drive it,
in order to program the 16C84? I'm very comfortable with C etc., and capable
of doing the work, but don't want to try to work out the serial protocol
of the programmer if I find out that it's not possible for some reason.
If making some sort of HW adapter board for the PIC is needed, that's
no problem either.
>
>My query: does anyone have information as to whether I could hack
>the Picstart programmer, and/or write my own software to drive it,
>in order to program the 16C84? I'm very comfortable with C etc., and capable
>of doing the work, but don't want to try to work out the serial protocol
>of the programmer if I find out that it's not possible for some reason.
>If making some sort of HW adapter board for the PIC is needed, that's
>no problem either.
>
> thanks for any info
> regards
> jon Nicoll
>
Jon,
You under-estimate how different the 16C84 is programming wise to the other
16Cxx parts. It is extremely doubtful the PS 16C can be used to program a 16C84
regardless of what new driver you write for it. This is because the timing and
required command set are generated by the onboard firmware, not the software
driver. It is doubtful the 16C84 algorithm is present in the PS 16C.
There are however, many low cost solutions for programming the 16C84 and no
doubt
you will receive further pointers on this.
I am currently working on a project to upgrade the PS 16B to do all the devices
not currently covered by it. This includes the 40-pin and 28-pin 16Cxx
parts, the
PIC14000 and the PIC12Cxxx parts, but, unfortunately for you, this is no help.
Hi Jim
thanks for replying to my query. I am/was actually in the middle
of building a board to program the 16C84 when a friend came up with the
16C programmer. From what you and others say, it seems I am right to keep
on building...
Does your upgrading of the 16B programmer include upgrading the on-board
firmware? Do you happen to know if Microchip allow reading of the firmware on
the
16B/C programmer boards.
At 03:16 PM 9/11/96 BST, you wrote:
>Hi Jim
> thanks for replying to my query. I am/was actually in the middle
>of building a board to program the 16C84 when a friend came up with the
>16C programmer. From what you and others say, it seems I am right to keep
>on building...
>
>Does your upgrading of the 16B programmer include upgrading the on-board
>firmware? Do you happen to know if Microchip allow reading of the firmware on
> the
>16B/C programmer boards.
>
(?)
>
> Best regards
> jon N
>
Jon,
Yes, keep on building.
My upgrade for the PS 16B does involve new firmware call "phoenix." New firmware
is required to properly manage all the features of all the devices. This is
especially true with the PIC14000 and the PIC12Cxxx devices.
I have need actually tried to read the old firmware myself so I don't know if it
is code protected.
Hang on a second, I'll try it now......
Bummer! it is code protected so I guess the answer is no. For V1.7 at least.
Oh well, good luck with the 16C84 programmer anyway.
Hi Jim
out of interest (mainly), do you know the H/W differences between
the 16B and the 16C PicStart programmers? Microchip do seem to have a
confusing range of programming devices. Since the PicStart 16C kit includes
an EPROM 16C<can't remember>, I was toying with the idea of working out the
cct, blowing a new PIC, and using that. Partly as an exercise, and partly
because the PicStart is a nicer bit of H/W than the cheap & cheerful
thing I'm knocking up at the moment...
At 09:43 AM 9/12/96 BST, you wrote:
>Hi Jim
> out of interest (mainly), do you know the H/W differences between
>the 16B and the 16C PicStart programmers? Microchip do seem to have a
>confusing range of programming devices. Since the PicStart 16C kit includes
>an EPROM 16C<can't remember>, I was toying with the idea of working out the
>cct, blowing a new PIC, and using that. Partly as an exercise, and partly
>because the PicStart is a nicer bit of H/W than the cheap & cheerful
>thing I'm knocking up at the moment...
>
> cheers
> jon N
>
Jon,
The picstart 16s both use a 17C42 chip for the firmware so there goes your
idea of "rolling your own."
The main difference between the 16B and 16C is the ZIF socket size and wiring.
The 16C is a much simpler programmer as it doesn't require multipling or
widely different algorithms for the 16C84 and 16C5x parts.
I understand one can order pre-programmed PICs. I have a couple of
questions regarding this.
1. Is there a pre-programmed version of 16C61?
2. How many do I have to order?
3. How does the price compare to regular OTP parts?
A related issue: are the 16C62x parts plug-compatible with 16c61? I
understand they have extra comparators, but if I just program a 16c620
with object built for the 16C61, will it work the same?
> A related issue: are the 16C62x parts plug-compatible with 16c61? I
> understand they have extra comparators, but if I just program a 16c620
> with object built for the 16C61, will it work the same?
The 16C62x and 16C61 have slightly different memory maps; in addition, you
must explicitly enable PORTA digital inputs if you intend to use them for
anything. Converting your source file to be 16C62x compatible should be
very easy, but loading object code directly will not work.
This is an interesting programming problem that I have come across a
few times, and it is a real pain to fix.
I use DOS's Edit program to develop PIC code and 99.9999% of the time
it works fine. A few times though, the code just stops working as it
is being developed. Of course I think my fingers misinterpreted my
brains wishes and hit the wrong keu, &*^%$# sorry, key.
Anyway this was not the case at all. I traced and tracked and looked
and hacked, until I finally found a line of code that should have
worked but didn't. It even looked ok on screen. I deleted the line of
code from the source file and retyped it exactly as it was and bingo
the code then worked.
Very odd and frustrating. I wonder what little gremlins hide in the
humble Edit progrzm &^%$#(, - flamin' brain.
Tony
Just when I thought I knew it all,
I learned that I didn't.
>I use DOS's Edit program to develop PIC code and 99.9999% of the time
>it works fine. A few times though, the code just stops working as it
>Anyway this was not the case at all. I traced and tracked and looked
>and hacked, until I finally found a line of code that should have
>worked but didn't. It even looked ok on screen. I deleted the line of
>code from the source file and retyped it exactly as it was and bingo
>the code then worked.
I've had this happen to me as well (using other editors like Norton Editor).
I suspect that an errant character gets inserted (possibly due to EMI from
those arc welders next door) into the file. The editor won't display it, but
it gets compiled, causing problems.
Next time save a copy of the file, fix the problem, and then perform a
binary file comparison to see what the offending character is.
>This is an interesting programming problem that I have come across a
>few times, and it is a real pain to fix.
>
>I use DOS's Edit program to develop PIC code and 99.9999% of the time
>it works fine. A few times though, the code just stops working as it
>is being developed. Of course I think my fingers misinterpreted my
>brains wishes and hit the wrong keu, &*^%$# sorry, key.
>
Tony,
DOS "Edit" is a cut down version of the IBM Internal Use Only Editor "E3"
which is notorious for this problem.
Usually the problem can be tracked to a backspace (0x08) character on the
line. You will need a file display utility to actually find the problem.
Before I moved over to MPLAB, I had this problem a few times. The only way
to fix it is to retype the whole line (if you copy the line, the wrong
character and the backspace, which deletes it (and makes it invisible when
you type out the line or look at it in another editor) - which is the error
MPASM is telling you about.
I could go on and explain why this is a problem (MPASM must use FCB file
handling), but that isn't important.
To eliminate the problem you can:
1. Use an Editor other than Edit (or E3).
2. After creating your code, load the file into another Editor and then
save it again (usually the other editor will be able to load the bad
char/backspace and ignore it - like MPASM should). (Big pain in the ass,
it's easier to just retype the line.)
3. Migrate over to MPLAB. (Probably the optimal solution.)
I personally *love* E3/Edit, I have been using it and their predecessors for
literally 15 years. The full version E3 allows you to write Rexx macros
which can be tailored to developing code for different languages and allow
you to directly invoke compilers. I really think it's the best programmer's
development tool available.
But, you will have problems with using it with MPASM. This is why I even
tried MPLAB (because I had a pretty good E3 based development "system"
integrating the E3, MPASM, MPSIM, and MPSTART). The guy who wrote E3 left
IBM a number of years ago (I think about seven) and it hasn't been supported
since then - this problem shows up in very few applications (actually I
consider a bigger one to be the ctrl-Z (0x01A) character put at the end of
each file which shows up as a box in any Windows based
editors/applications). A good question is why IBM/Microsoft ship a program
that they can't support or fix a known bug - I wish I knew the answer to it.
Sorry I can't give you any more help. And sorry for the long missive -
maybe it will help somebody.
Please don't ask for copies of E3 or my "development system", I can't give
them out.
Myke
Do you ever feel like an XT Clone caught in the Pentium Pro Zone?
According to TONY NIXON 54964:
>
> This is an interesting programming problem that I have come across a
> few times, and it is a real pain to fix.
>
> I use DOS's Edit program to develop PIC code and 99.9999% of the time
> it works fine. A few times though, the code just stops working as it
> is being developed. Of course I think my fingers misinterpreted my
> brains wishes and hit the wrong keu, &*^%$# sorry, key.
>
> Very odd and frustrating. I wonder what little gremlins hide in the
> humble Edit progrzm &^%$#(, - flamin' brain.
>
> Tony
Tony:
Probly no gremlins in edit but somewhere between your brain and finger tips.
The best thing to do is a hex dump of the source and look for funny control
chars (beside cr and lf). It is easy to put these things in the file and
they may or maynot be displayable. If you can identify to the line usually
just pressing the arrow keys will expose the char (Its where you have to press
the arrow twice before the cursor moves).
--
Les Troyer
Sr. Analyst
Siemens Power Corp
2101 Horn Rapids Rd.
Richland, Wa. 99352-0130
>... I traced and tracked and looked
>and hacked, until I finally found a line of code that should have
>worked but didn't. It even looked ok on screen. I deleted the line of
>code from the source file and retyped it exactly as it was and bingo
>the code then worked.
>
>Very odd and frustrating. I wonder what little gremlins hide in the
>humble Edit progrzm &^%$#(, - flamin' brain.
Would strongly suspect you managed to embed a control
code into your text. 'Edit' allows you to do this in
a number of ways, and legitimately so.
The problem would then be the behaviour of 'MPASM' on
seeing this code.
> >Very odd and frustrating. I wonder what little gremlins hide in the
> >humble Edit progrzm &^%$#(, - flamin' brain.
>
> Would strongly suspect you managed to embed a control
> code into your text. 'Edit' allows you to do this in
> a number of ways, and legitimately so.
>
> The problem would then be the behaviour of 'MPASM' on
> seeing this code.
Any decent programmer's editor should allow you to embed control characters
in your file, but should make them clearly visible so that you won't leave
them in by mistake. For example, a line with some backspaces would show up
in VI as:
Bill Gates is a monster^H^H^H^H^H^H^Hgenius.
The only tricky issues on PC's are codes zero, 255, and 9 (tab); at least
one betaware assembler I played with would choke on tab characters, so
be aware of them.
In message <D74B0411C8spam_OUT@spam@eng2.eng.monash.edu.au>, TONY NIXON 54964 writes:
>This is an interesting programming problem that I have come across a
>few times, and it is a real pain to fix.
I have had the same thing happen when writing source code and I
think that control codes get typed in by mistake such that they don't change
the appearance of the screen, but do destroy the syntax of the line since
the assembler, C preprocessor, or whatever sees that control code like a red
light and either tries to act upon it or simply gets confused as to what
is supposed to happen. If a copy of the bad source code exists, run
DOS's debug program on it and dump it to the screen, looking for the command
that caused all the trouble. I bet there will be an odd byte or two somewhere
in that line that isn't an ASCII character or also isn't the 0D 0A which
should terminate each line in a DOS text file.
Martin McCormick WB5AGZ Stillwater, OK 36.7N97.4W
OSU Center for Computing and Information Services Data Communications Group
I have a 16C84 that is to be programmed in-circuit as part of our customers'
system configuration. Ideally, this would run under Windows NT. However,
it appears that the parallel-port programming model (as seen in Messrs.
Tait and Goodwin, and the Microchip ECH) wants direct port-level communication
with the parallel port, and from what little I know of NT, this is not
allowed.
Has anyone else tried to integrate a parallel-port programmer under NT?
Can someone perhaps point me to "model" printer driver code, so I can figure
out how to include what I need?
Karen L. Black wrote:
>
> I have a 16C84 that is to be programmed in-circuit as part of our customers'
> system configuration. Ideally, this would run under Windows NT. However,
> it appears that the parallel-port programming model (as seen in Messrs.
> Tait and Goodwin, and the Microchip ECH) wants direct port-level communication
> with the parallel port, and from what little I know of NT, this is not
> allowed.
>
> Has anyone else tried to integrate a parallel-port programmer under NT?
> Can someone perhaps point me to "model" printer driver code, so I can figure
> out how to include what I need?
>
> Thanks,
> Karen Black
> Blodgett, OR
Having tried to write a printer driver for NT, and having a lot of
difficulty it was much easier and almost as good, we went to Windows 95
instead.
Your simplest solution is to NOT use NT. Writing a 'printer driver' for
NT, to put it simply....is HELL. If you dont really need to use NT for
in-circuit programming dont!!! Just use a DOS boot disk and do it that
way. If you have the NT DDK (Device Driver Kit) from Microsoft there is
a sample UNIDRIVER for NT included. Supposedly you can just write a
diver script that will do what you need, and It MAY write directly to
the port. Also under NT nearly all IO is done via a file interface from
the NT API, But I'm not sure about the printer ports.
I hope this kind of helps, but for my money I would not bother with NT..
--
Alan Nickerson
---------
It seems to me that the best new ideas come from
people who don't know that they "can't". -- Paul Mathews, .....optoengspam.....WHIDBEY.COM
Take a look at issue 74 (September 1996) of Circuit Cellar Ink. There is
an article about writing a VxD for Windows 95 that allows access to the
printer port. Although VxD's don't currently work in NT, Microsoft may put
support in for them soon.
> I have a 16C84 that is to be programmed in-circuit as part of our customers'
> system configuration. Ideally, this would run under Windows NT. However,
> it appears that the parallel-port programming model (as seen in Messrs.
> Tait and Goodwin, and the Microchip ECH) wants direct port-level communication
> with the parallel port, and from what little I know of NT, this is not
> allowed.
>
> Has anyone else tried to integrate a parallel-port programmer under NT?
> Can someone perhaps point me to "model" printer driver code, so I can figure
> out how to include what I need?
>
> Thanks,
> Karen Black
> Blodgett, OR
>
Folks,
I have just started getting my hands into the PIC line of microcontrollers.
I thought that the best way would be with the 16c84 since it is EEPROM and
can easily be reprogrammed. Unfortunately I own a macintosh an cannot use
the widely available PC Serial line programmers. So I went about designing
my own using a HC11 as a controller to program the PIC. I compiled Tim
Rossi's assembler <http://www.jyu.fi/~trossi/pic/> on my computer and used
his example as my first project. His first example was a simple LED
flaser. It seemed to work fine, and I was even able to reprogram the PIC
to do a different flashing sequence, so I was sure that everything was set
on the programming side. I then went on to my next project (which was
probably too big a leap). I am trying to compile AN591 (Apple Desktop Bus
project) for the 16c84. After some modifications I was able to compile it
fine. I tried programming my PIC, but unfortunately my project did not
work on the first try (when does it ever?) But then I went back to my LED
flasher program. I programmed it and inserted it into the circuit, and it
didn't work. Figuring that maybe my ADB circuit had blown the PIC, I tried
a new one. Programmed it to the LED flasser program, plugged it into the
circuit and it worked just fine. Changed the LED flasher program, retried
it and it worked fine. Programmed the PIC to the ADB program, then
*without* inserting it into and circuit, I programmed it back to the LED
flasher program. PLugged it into the circuit and it didn't work ;-( I
tried again and again with both PIC's to program them to a known good
program (the LED flasher) but without any luck. They would not work. So to
get down to the bottom of things, could something that I programmed (in the
ADB HEX file), ruined my PICs? Maybe it is the way I am sending it? Is
there any wierd sequence that would kill my PIC?
Any suggestions on how to bring back to life my PICs?
I know it is hard to figure out what is *REALLY* going on just based on my
description, but does anyone have any idea what is going on? I can supply
HEX files for both of the PIC programs that I have been using.
Thanks,
-Dave Negro
P.S. I should have mentioned that my programmer does not have a verify
mode. At least it didn't. I rewrote it to verify, but it isn't working.
HOwever, I am not sure if it is the PIC that isn't working, or my verify
code on the HC11 that isn't working.
> Changed the LED flasher program, retried
> it and it worked fine. Programmed the PIC to the ADB program, then
> *without* inserting it into and circuit, I programmed it back to the LED
> flasher program. PLugged it into the circuit and it didn't work ;-( I
> tried again and again with both PIC's to program them to a known good
> program (the LED flasher) but without any luck. They would not work. So to
> get down to the bottom of things, could something that I programmed (in the
> ADB HEX file), ruined my PICs? Maybe it is the way I am sending it? Is
> there any wierd sequence that would kill my PIC?
My conjecture would be that your programmer does not have a fast enough
rise on the VPP/MClr pin. If this pin rises too slowly, the PIC will
start to execute code before going into programming mode and programming
will start just past the last instruction executed rather than address
zero as you'd expect.
If this was going on, your LED flasher program might still seem to work, even
though it was loaded in the wrong place and all the gotos weren't going to
the right parts of the code. Your ADB program, however, probably has a more
complicated structure; once it's been loaded into the PIC, it may cause the
code to get hung up in a bizarre spot right on power-up (which will then be
where programming will start). The only way out of this situation is to fix
the VPP/MClr circuitry to ensure a fast enough rise time.
>
> At 11:29 AM 10/6/96 -0400, you wrote:
> >Folks,
> > Unfortunately I own a macintosh an cannot use
> >the widely available PC Serial line programmers.
>
> Buy a IBM.
That isn't very productive. Even with the inexpensive cost of PC hardware
why should someone have to change platforms simply to do development.
While I understand why Microchip has standardized on a single platform
I fail to understand why someone doesn't realize that there's a niche
here and attempt to fill it.
I'm a fervent believer that hardware, OS, and applications need not be
mated at the hip together. One should be able to development on the
hardware they like, running the OS they like, using the applications they
like.
Fact of the matter is that with the release of the interface specifications
for any of the PC serial programmers, it would not be too hard to generate
a MAC interface for them.
But those specs are difficult if not impossible to obtain.
Cross platform development is a good thing. We should encourage it instead
of telling folks to stagnate on a single platform.
> > Buy a IBM.
>
> That isn't very productive. Even with the inexpensive cost of PC hardware
> why should someone have to change platforms simply to do development.
Historical note: it's not so long ago that the only advice available
would have been "pay through the nose for the vendor's proprietary
hardware and software". In comparison, "buy a PClone" is pretty nearly
painless, and vastly much less expensive.
> While I understand why Microchip has standardized on a single platform
> I fail to understand why someone doesn't realize that there's a niche
> here and attempt to fill it.
Perhaps because they believe the niche is too small to be profitable?
Frankly, I don't know anyone who uses a Mac for software development,
though I know a good number of developers who prefer to use a Mac for
doing documentation, artwork, & all that DTP-ish side of the job.
> I'm a fervent believer that hardware, OS, and applications need not be
> mated at the hip together. One should be able to development on the
> hardware they like, running the OS they like, using the applications they
> like.
It's a lovely sentiment, but it has never been so, and probably never
will be so. The problem is that most interesting programs have target
system dependencies, and in the general case require significant effort
to port from one traget to another - and someone has to pay for that.
> > >Folks,
> > > Unfortunately I own a macintosh an cannot use
> > >the widely available PC Serial line programmers.
> >
> > Buy a IBM.
Another option would be for Microchip to write their development code
in the LabVIEW language by National Instruments (NI). This is a
graphical
language (there is a GUI but the language it'self is graphical). The
code, once written can be run on PC, MAC, Sun, and HP-PA risc machines
with NO changes. True cross paltform portability.
I am biased on this one since I am a member of the NI ALLIANCE program
and am a CERTIFIED INSTRUMENT DRIVER DEVELOPER. I have written a lot of
code on my PC and taken it to customers who use Macs with direct and
total
portability.
I thought the problem was that the Mac doesn't have a standard serial
port/parallel port. Writing in LabVIEW isn't going to solve this problem
if the hardware configuration doesn't change. Unless you want
MicroChip/Parallax to have GPIB only programmers and have everyone buy
$200+ GPIB cards. I've seen 286 clones around here for less than $100.
Dave
> Another option would be for Microchip to write their development code
> in the LabVIEW language by National Instruments (NI). This is a
> graphical
> language (there is a GUI but the language it'self is graphical). The
> code, once written can be run on PC, MAC, Sun, and HP-PA risc machines
> with NO changes. True cross paltform portability.
>
> I am biased on this one since I am a member of the NI ALLIANCE program
> and am a CERTIFIED INSTRUMENT DRIVER DEVELOPER. I have written a lot of
> code on my PC and taken it to customers who use Macs with direct and
> total
> portability.
>
> Brooke Clarke
> Rack and Stack Systems
>
Unfortunately "Buy a PC" is kind of like "Buy an Oscilloscope" these
days. I finally bought a 386 to act as a tool holder for some software.
I do no programming on it, and run no other applications, it cost me
$300. (which was roughly a third what my oscilloscope cost, and
half what the signal generator cost)
--Chuck
----------
From: Byron A Jeff[SMTP:EraseMEbyron@spam@@spam@CC.GATECH.EDU]
Sent: Monday, October 07, 1996 7:26 AM
To: Multiple recipients of list PICLIST
Subject: Re: PIC16c84 programming problems
>
> At 11:29 AM 10/6/96 -0400, you wrote:
> >Folks,
> > Unfortunately I own a macintosh an cannot use
> >the widely available PC Serial line programmers.
>
> Buy a IBM.
That isn't very productive. Even with the inexpensive cost of PC hardware
why should someone have to change platforms simply to do development.
While I understand why Microchip has standardized on a single platform
I fail to understand why someone doesn't realize that there's a niche
here and attempt to fill it.
I'm a fervent believer that hardware, OS, and applications need not be
mated at the hip together. One should be able to development on the
hardware they like, running the OS they like, using the applications they
like.
Fact of the matter is that with the release of the interface specifications
for any of the PC serial programmers, it would not be too hard to generate
a MAC interface for them.
But those specs are difficult if not impossible to obtain.
Cross platform development is a good thing. We should encourage it instead
of telling folks to stagnate on a single platform.
This may fall into the "for what its worth category" but here goes.....
I use both Macs and DOS boxes. I prefer the Mac for both development and
"writing manuals" and other graphics intensive tasks. I use a windows
based machine because there some apps out there that are only written for
that platform.
On the Mac side Crossbow from peripheral issues (I can dig up their URL if
you wish) seems quite capable and for other processors such as the Motorola
line development tools are readily available for both platforms.
There is no single "best" machine. Publishing the interface specifications
for the programmers that are out there would seem like a sensible thing to
do even if there were only one platform.
>
> Unfortunately "Buy a PC" is kind of like "Buy an Oscilloscope" these
> days. I finally bought a 386 to act as a tool holder for some software.
> I do no programming on it, and run no other applications, it cost me
> $300. (which was roughly a third what my oscilloscope cost, and
> half what the signal generator cost)
Understood. However the problem remains that it requires additional equipment,
more space, power, and a change in mindset to use. The computer the
gentleman already had (the Mac) is perfectly capable of doing the job. The
only issue is software and mindset.
Other than the fact the tools don't exist what's wrong with using a Mac,
Linux, Amiga, NeXT, or other box for development?
I've done development for 10 years without an oscilloscope. That's why
I like microcomputers - all you need is software and a logic probe.
At 10:26 AM 10/7/96 -0400, you wrote:
>>
>> At 11:29 AM 10/6/96 -0400, you wrote:
>> >Folks,
>> > Unfortunately I own a macintosh an cannot use
>> >the widely available PC Serial line programmers.
>>
>> Buy a IBM.
>
>That isn't very productive. Even with the inexpensive cost of PC hardware
>why should someone have to change platforms simply to do development.
>
No, what's not very productive is spending thousands of dollars and hours
trying to develop some halfway-working MAC programmer when you can buy an
IBM for a mere $600 that will run anything you want (Except some high-end
games!). And if you think THAT was hard, try getting an emulator to work
properly with the thing.
Why not change platforms? He who fears change, fears progress.
Besides I'm sure whatever you got for the IBM would be much easier to use
than anything you could write yourself, and it would be updated by the
companies without you haveing to constantly re-write it.
The Mac/LabVIEW can output standard RS232 (and LabVIEW drivers have been
written for a number of different busses/hardware platforms), so that
wouldn't be an issue.
The basic issues with LabVIEW is the price ($1,500 for the basic license,
$3,000 for the "Developer's Kit" CD) and the compatibility across
platforms/OS's.
The price would put it out of the reach of the hobbyist/"What if/Let's try"
business that MPLAB really nails. And the differences between Operating
Systems that LabVIEW doesn't account for means that Common
Compilers/Assemblers/Simulators could probably not be written. I think
LabVIEW could be used for the Programmer and maybe an ICE across platforms,
but that would be it.
LabVIEW is an excellent tool for the failure analysis
laborator/manufacturing line (which is what we use it for). But, it really
isn't appropriate for this type of application especially considering the
cost. As Dave pointed out, you can get a 486 Windows based PC with 8 Meg
RAM *new* here in Toronto for under $300 Canadian. A used colour VGA tube
would probably set you back $100.
>I thought the problem was that the Mac doesn't have a standard serial
>port/parallel port. Writing in LabVIEW isn't going to solve this problem
>if the hardware configuration doesn't change. Unless you want
>MicroChip/Parallax to have GPIB only programmers and have everyone buy
>$200+ GPIB cards. I've seen 286 clones around here for less than $100.
>Dave
>
>
>On Mon, 7 Oct 1996, brooke wrote:
>> Another option would be for Microchip to write their development code
>> in the LabVIEW language by National Instruments (NI). This is a
>> graphical
>> language (there is a GUI but the language it'self is graphical). The
>> code, once written can be run on PC, MAC, Sun, and HP-PA risc machines
>> with NO changes. True cross paltform portability.
>>
>> I am biased on this one since I am a member of the NI ALLIANCE program
>> and am a CERTIFIED INSTRUMENT DRIVER DEVELOPER. I have written a lot of
>> code on my PC and taken it to customers who use Macs with direct and
>> total
>> portability.
>>
>> Brooke Clarke
>> Rack and Stack Systems
>>
>
>
Do you ever feel like an XT Clone caught in the Pentium Pro Zone?
> I use both Macs and DOS boxes. I prefer the Mac for both development and
> "writing manuals" and other graphics intensive tasks. I use a windows
> based machine because there some apps out there that are only written for
> that platform.
Yeah, that description was moderately provocative, wasn't it? <grin>
However, it did accurately represent my own first-hand experiences.
FWIW, the Macs were most often used for graphics and animation, and I
don't think any of these folks that I know actively prefer to move from
another platform to the Mac just to document the work they've done. But
I didn't want to leave that without alluding to the set of apps that
carved out the Mac's original niche - a solid base that still helps
anchor the Mac in the marketplace.
> There is no single "best" machine. Publishing the interface specifications
> for the programmers that are out there would seem like a sensible thing to
> do even if there were only one platform.
Yeah, but the vendors still tend to consider such things proprietary -
and there's some justification for protecting the work they've done
developing such hardware in many cases. It does seem that it would be
entirely to Microchip's benefit to reveal such things, since they're not
really in that business except as it supports the sales of their
microcontrollers - at least, there would be a strong argument in favor of
being open on their part.
>That isn't very productive. Even with the inexpensive cost of PC hardware
>why should someone have to change platforms simply to do development.
>
No, what's not very productive is spending thousands of dollars and hours
trying to develop some halfway-working MAC programmer when you can buy an
IBM for a mere $600 that will run anything you want.
Agree completely.
Look, as long as the low-end tools we're talking about are DOS based, you
can probably get a used IBM clone for under $100. That means you can get
a complete programmer for PICs for well under $200. If it makes you feel
better, don't think of it as a kludgey computer running an evil operating
system, just think of it as a stand-alone programming box. You don't have
to learn much about msdos to use it, either...
myke predko wrote:
>
> Dave,
>
.........
>
> The basic issues with LabVIEW is the price ($1,500 for the basic license,
> $3,000 for the "Developer's Kit" CD) and the compatibility across
> platforms/OS's.
Once a developer that has LabVIEW buys the APPLICATION BUILDER his cost
for
each application sold is $20 ($0 if the customer is using any NI
hardware).
> > Unfortunately "Buy a PC" is kind of like "Buy an Oscilloscope" these
> > days. I finally bought a 386 to act as a tool holder for some software.
> > I do no programming on it, and run no other applications, it cost me
> > $300. (which was roughly a third what my oscilloscope cost, and
> > half what the signal generator cost)
>
> Understood. However the problem remains that it requires additional equipment,
> more space, power, and a change in mindset to use. The computer the
> gentleman already had (the Mac) is perfectly capable of doing the job. The
> only issue is software and mindset.
>
> Other than the fact the tools don't exist what's wrong with using a Mac,
> Linux, Amiga, NeXT, or other box for development?
Well the Amiga should be no problem, it has a nice bi-directional parallel
port - far better than the usual IBM port. What about the MAC, does that
have a nice port you can 'wiggle' pins up and down?. Assuming it has, it
should be pretty easy to convert David Tait's Basic or C source code to
implement a 16C84 programmer.
At 9:18 AM 10/8/96, Martin J. Maney wrote:
>Yeah, but the vendors still tend to consider such things proprietary -
>and there's some justification for protecting the work they've done
>developing such hardware in many cases. It does seem that it would be
>entirely to Microchip's benefit to reveal such things, since they're not
>really in that business except as it supports the sales of their
>microcontrollers - at least, there would be a strong argument in favor of
>being open on their part.
Companies don't develop such things, people do. If someone out "sells"
Microchip on the idea then they may pay for it. However in this case I
think a Mac version of PIC development tools is probably not going to sell.
craig
ps. I've always had a Mac and will always have a Mac for code development.
For me, nothing else even comes close (I use DOS, 3.1, 95, NT, and Linux
all day long).
First off, who really cares whether writing Mac development tools is
"worth doing?" If someone is willing to write them, then to that
person, it must be worth it. It is unimportant whether the rest of the
community recognizes the need.
I've been kicking around the idea of writing some programming software
for the Smac for a few months. As far as I can see, these are the
salient points:
Without programmer specs from someone's programmer, I need to create my
own. I have not researched the availability of programmer specs, nor
the possibility of using a 'scope/logic probe to reverse engineer them.
However, reading Microchip's specs for programmers and creating my own
shouldn't be too tough. But, if I do that, any Mac developer is
obviously stuck with my programmer. 'Twould be much cooler to use a
pre-existing one.
Writing the software is pretty trivial. For those that aren't familiar
with Mac development, I'd only need to write a Communications Toolbox
module. This is simply a description of a communications protocol.
Technically, that'd be it, but I guess it would also be cool to write an
application to handle selecting which hex file to use, doing blank
checks, verifies, etc. In both cases, the software is pretty trivial.
Mac software is *really* easy to write, cause the OS does most of the
work.
However, without at least a compiler and an emulator, the whole thing
is kind of pointless. This is why I haven't done it. It would be sort
of silly to have to rely on SoftWindows for this, and sillier yet to do
my compiling and testing on a pc, then port the hex file over to the
Smac. I've considered writing a compiler and an emulator for the Mac,
and I guess it could be done, but it would be lots more work, and it
would need to be constantly maintained.
So, to sum up, as I see it, the problem is not writing a driver to
program parts, but writing the software tools to make having a driver
worthwhile.
BTW, for those who are interested, I use an ibm clone for all my PIC
stuff and a Smac for everything else. I don't really have any
complaints with either OS; I just think it would be interesting to do
the Smac development. Wow, I sound defensive, guess I've been watching
the newsgroup IBM vs. Smac threads too long:->
I'm no Mac Expert, but I do know you can get a Mac Card that has
a 486 processor on it along with Parallel and Serial ports. If someone
wanted to stick with their Mac and avoid buying a new monitor, this may
be the way to go. It also would no take up any extra desk space.
> >That isn't very productive. Even with the inexpensive cost of PC hardware
> >why should someone have to change platforms simply to do development.
> >
> No, what's not very productive is spending thousands of dollars and hours
> trying to develop some halfway-working MAC programmer when you can buy an
> IBM for a mere $600 that will run anything you want.
>
> Agree completely.
>
> Look, as long as the low-end tools we're talking about are DOS based, you
> can probably get a used IBM clone for under $100. That means you can get
> a complete programmer for PICs for well under $200. If it makes you feel
> better, don't think of it as a kludgey computer running an evil operating
> system, just think of it as a stand-alone programming box. You don't have
> to learn much about msdos to use it, either...
>
> BillW
>
In message <spamBeGoneCMM.0.90.2.844795538.billwKILLspamTakeThisOuTpuli.cisco.com>, William Chops Westfield
writes:
>If it makes you feel
>better, don't think of it as a kludgey computer running an evil operating
>system, just think of it as a stand-alone programming box. You don't have
>to learn much about msdos to use it, either...
Great point. An article I once read in the business section of
either "Newsweek" or "U.S. News" suggested that a good business stragegy
was to think of a desirable business application and then buy the hardware
that would best run it. While this was aimed at the legger and spread-sheet
croud, it applies to us also. No one platform is perfect for every
application so it isn't totally far-fetched to spend your biggest bucks
on the system that you like best and then shop around for a good deal on
another system that might not be your first choice but will really scream
through some particular application.
Martin McCormick WB5AGZ Stillwater, OK 36.7N97.4W
OSU Center for Computing and Information Services Data Communications Group
> An article I once read in the business section of
> either "Newsweek" or "U.S. News" suggested that a good business strategy
> was to think of a desirable business application and then buy the hardware
> that would best run it.
There's an old 'Mythical Man Month' saying that's applicable
to this thread:
"The language and operating system that's best to
use is the language and operating system that your
best programmer knows best."
> I've been kicking around the idea of writing some programming software
> for the Smac for a few months. As far as I can see, these are the
> salient points:
>
> Without programmer specs from someone's programmer, I need to create
my
> own. I have not researched the availability of programmer specs, nor
evidently not. There are many PC programmers for the pic, with source
code. Just pick one, and adapt the code.
> However, without at least a compiler and an emulator, the whole thing
> is kind of pointless. This is why I haven't done it. It would be sort
There are many assemblers and at least two emulators, in source
format. All the stuff that I use (programmer; assembler; emulator)
is available from my home page in source format, although there
might be other sources.
Luigi
====================================================================
Luigi Rizzo Dip. di Ingegneria dell'Informazione
email: EraseMEluigi.....KILLspamiet.unipi.it Universita' di Pisa
tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522 http://www.iet.unipi.it/~luigi/
====================================================================
Just a quick question - I'm designing a small board that will
plug into an ISA slot on a PC. It's a simple enough project except
for one minor detail - I want to be able to program the PIC while
it's in the slot...
Should be easy enough - the interfacing is trivial, but the problem
is Vpp. This has to be 12-14 volts, right? But when you use the
12V available from the ISA bus you get a problem - there will
be at least one diode drop or transistor drop (or in my design, both!)
in the circuit in order to switch the Vpp in and at the same time
not blow your 5V line. This brings the 12V below the required Vpp.
It's a pain to use an external power supply and you have to be a
lot more careful about gating...
Has anyone encountered this problem or have a simple solution to it?
Conor O'Rourke wrote:
>
> Should be easy enough - the interfacing is trivial, but the problem
> is Vpp. This has to be 12-14 volts, right? But when you use the
> 12V available from the ISA bus you get a problem - there will
> be at least one diode drop or transistor drop (or in my design, both!)
Hi Conor,
I'm not sure how much current is needed for Vpp (I think you use a
16C84?),
but perhaps you can connect the 12 V of the PC with a sufficiently large
resistor
to the Vpp line. No current - no drop.
Hope it helps a bit,
Wolfram
PS: Why don't you use MOSFETs to switch? No voltage drop.
>Why not change platforms? He who fears change, fears progress.
>Besides I'm sure whatever you got for the IBM would be much easier to use
>than anything you could write yourself, and it would be updated by the
>companies without you haveing to constantly re-write it.
>
>So:
>Buy a IBM.
First off I would like to apologize for having started all this, although
it was not my intention.
Secondly, I am familiar with many operating systems including MacOS,Un*x,
Linux, OpenWin, MS Windows, DOS, and have even had a chance to play with
the new up and coming BeOS (Way COOL!!) The problem here is not the
disinterest in changing systems, but rather the resources. I am a college
student, on a college budget. Not only do I not want to buy another
computer at this point, but I do not want to transport it in the few moves
that I have left.
Thirdly, I don't do projects because they are easy. I do projects because
they interest me and I think that I will learn something from them. Yes it
would be easier to go out an buy a PC and a programmer, but what have I
gained in terms of knowledge from it? Nothing really. I would then be
limited to that platform and that programmer. By doing it myself, I get a
better understanding of the PIC programming process as well as a better
understanding of PICs in general. If I had a project for PICs already
lined up, and I was in a time crunch, and I had the resources (cash), I
would have no difficulty in changing systems. As is, making a programmer
is a project of it's own, keeps me busy and keeps the noodle working.
So if you want to go the easy way, follow OTHER people's footsteps, then be
my guest. Personally, when the resources are not available, I like to fill
in the gaps myself. You can't always rely on other people and need to be
able to do things for yourself!
Lastly, Thank you to the people that did respond to my main question about
the programming problem. I have not had time to look into the problem
further, but will get to that shortly. Thanks.
P.S. - Also remember that I using a Motorola 68HC11 microcontroller as the
base for my programmer. When I work out the last of my bugs, anyone with a
rs232 terminal will be able to use my programming setup. People should
not be stuck to any one computer because I will have to agree that each
computer has its advantages and disadvantages.
>Just a quick question - I'm designing a small board that will
>plug into an ISA slot on a PC. It's a simple enough project except
>for one minor detail - I want to be able to program the PIC while
>it's in the slot...
>Should be easy enough - the interfacing is trivial, but the problem
>is Vpp. This has to be 12-14 volts, right? But when you use the
>12V available from the ISA bus you get a problem - there will
>be at least one diode drop or transistor drop (or in my design, both!)
>in the circuit in order to switch the Vpp in and at the same time
>not blow your 5V line. This brings the 12V below the required Vpp.
>It's a pain to use an external power supply and you have to be a
>lot more careful about gating...
>Has anyone encountered this problem or have a simple solution to it?
Some time ago I made an EPROM programmer for PC and I see this problem, you
can:
1) Use an external power supply attached to your board.
2) Use an step-up converter (DC-DC), for example a 78S40 switching chip.
3) Use a simple voltage doubler with 2 diodes and 2 capacitors, this solution
is the simplest but you'll be loosing the 70% of the power, that's isn't a
problem in a PC where the 12V supply can drain 8 A (Not to one slot!!).
bye SET.
********************************************************************************
Salvador Eduardo Tropea (SET) - salvadorSTOPspamKILLspaminti.edu.ar
Work: INTI (National Institute of Industrial Technology) Sector: ICE
(Electronic Control & Instrumentation)
Post (Home): Curapaligue 2124 - Caseros (1678)- Buenos Aires - Argentina
Conor O'Rourke wrote:
>
> Should be easy enough - the interfacing is trivial, but the problem
> is Vpp. This has to be 12-14 volts, right? But when you use the
> 12V available from the ISA bus you get a problem - there will
> be at least one diode drop or transistor drop (or in my design, both!)
You could try a dc-dc converter. Even a ~+5V to +12V one will get you
the margin you need. Just use the ISA +5V as the ground on the converter,
and the ISA +12V as the input voltage. You'll get +17V relative to ground.
There are lots of those things running around at surplus places, and on old
network cards. You might also try using a MAX232 if you can't find a cheap
converter.
In-Reply-To: <spam01IAG1GW2WLC8WWUQX..........ccvax.ucd.ie>
> Just a quick question - I'm designing a small board that will
> plug into an ISA slot on a PC. It's a simple enough project except
> for one minor detail - I want to be able to program the PIC while
> it's in the slot...
> Should be easy enough - the interfacing is trivial, but the problem
Conor,
Could I follow on from your question and ask you how you are interfacing
the PIC to the ISA bus. I have a need to pass a number of bytes of data
to and from a PIC over the ISA bus and am struggling about how to start
the design.
I am quite happy about buffering the bus and address decoding to the
ubiquitous 0x300 etc but am not certain how to arrange for an I/O write
to pass data to the PIC and an I/O read vice versa. Can you give me any
pointers?
At 03:04 PM 10/09/96 +0300, you wrote:
>Hi Conor, here SET:
>Some time ago I made an EPROM programmer for PC and I see this problem, you
>can:
>1) Use an external power supply attached to your board.
>2) Use an step-up converter (DC-DC), for example a 78S40 switching chip.
>3) Use a simple voltage doubler with 2 diodes and 2 capacitors, this solution
>is the simplest but you'll be loosing the 70% of the power, that's isn't a
>problem in a PC where the 12V supply can drain 8 A (Not to one slot!!).
>
>bye SET.
>
Option #3 is not an option... A voltage doubler like this works on AC, not DC!
...
Robert
>
>Has anyone encountered this problem or have a simple solution to it?
>
Wild guess. I haven't tried this.
How about using (p-channel?) FETs for switching between +12 and +5?
The 'on' resistance might be low enough. The 'on' resistance of a
4066 CMOS switch might even be ok.
Anybody care to beat this idea down?
73 de Jason
P.S. I've been using the CCS PIC C compiler for 16C74 work for the
past few days. I like it. It works. It lets me concentrate on the
task at hand without distractions from PIC assembler trivia.
The code generated looks pretty reasonable, but a bit non-obvious
a first glance of the .LST file. It compiles my C versions faster
than MPASM assembles the equivalent ASM versions. Go figure.
--
Jason F. Penn N9RPT | KILLspampennspam_OUTmailbag.com
Whenever I want to find something, it's always in the last place I look.
> How about using (p-channel?) FETs for switching between +12 and +5?
> The 'on' resistance might be low enough. The 'on' resistance of a
> 4066 CMOS switch might even be ok.
>
> Anybody care to beat this idea down?
I have seen 4066 switches used in similar applications; unfortunately, I
am not aware of anyone making a 74HCT4066--that would be a really useful
part [for those uninitiated, a 4066 or 74HC4066 is a digital switch which
may be used to switch any signal or voltage between its Vss (ground) and
VDD (supply) rails. Since the supply rail may be up to +15v, the device
may be used to conveniently switch programming voltage and other such
signals. Unfortunately, the switching threshhold for "standard" CMOS or
74HC parts is VDD/2; if VDD is 12 volts this means the switching thresh-
hold is at least 6 volts--not something a normal port can deal with. The
74HCT series of parts switches at around two volts independent of supply
and would be ideal in this application.]
Actually, this gets back to a question I was asking before: what is the
maximum allowable voltage on the RA4 pin (16C84 etc.)? The documentation
says there's no diode to VDD, but it doesn't grand permission to go above
VDD even so.
In message <spam_OUT01IAG1GW2WLC8WWUQXTakeThisOuTccvax.ucd.ie> .....PICLIST.....RemoveMEMITVMA.MIT.EDU writes:
> Hi guys [ok,ok and gals, and plas :-) ],
>
> Just a quick question - I'm designing a small board that will
> plug into an ISA slot on a PC. It's a simple enough project except
> for one minor detail - I want to be able to program the PIC while
> it's in the slot...
> Should be easy enough - the interfacing is trivial, but the problem
> is Vpp. This has to be 12-14 volts, right? But when you use the
> 12V available from the ISA bus you get a problem - there will
> be at least one diode drop or transistor drop (or in my design, both!)
> in the circuit in order to switch the Vpp in and at the same time
> not blow your 5V line. This brings the 12V below the required Vpp.
> It's a pain to use an external power supply and you have to be a
> lot more careful about gating...
>
Conor,
From experience, the PCs 12V rail is not very useful. The PC to PC
variation is too high.
I a previous job designing PCMCIA FLASH card readers for we derived
Vpp from the Vcc using a switcher IC. Both Maxim and LT both do
chips specific to programming flash memory which would work well
in your application.
>I'm designing a small board that will
>plug into an ISA slot on a PC. ... I want to be able to program the
>PIC while
>it's in the slot.
>Should be easy enough - the interfacing is trivial, but the problem
>is Vpp. This has to be 12-14 volts ... But ... there will
>be at least one diode drop or transistor drop (or in my design, both!)
> ... This brings the 12V below the required Vpp.
Hi Conor,
the solution is to experiment. Firstly I assume that this design is not
for a commercial device (if it is then of course you must be sure to
adhere rigidly to the spec's, and you can ignore the rest of this
message). It is important to note that the Vpp voltage is not actually
used to power the programming process, it is simply the presence of a
voltage at this level that sets the '84 into program mode. The actual
programming voltage for the EEPROM is internally generated.
Bearing this is mind just what voltage will trigger the device into
program mode? Is 11.4V enough, or is your PC's 12V line actually 12.6V?
Try it and see.
I know this thread is now two days old, and so is ancient history as far
as the original problem is concerned. However, if you like I will have
a go back at home, and try programming an '84 with different voltage
levels on the ^MCLR pin, and let you know how I get on.
As I said above however, if this is a commercial design you will want to
ensure that you meet the specifications exactly, and you must also be
able to vary Vdd to perform verification to Microchip's specification.
Andy (the other one)
--
---------------------------------------------------------------------
Andrew M Errington Tel: +44 1524 593678
Microcomputer Consultant Fax: +44 1524 844011
The Computer Centre Mobile (Orange): 0976 243931
Lancaster University spam_OUTa.erringtonTakeThisOuTEraseMElancaster.ac.uk
Lancaster LA1 4YW www.lancs.ac.uk/people/cpaame/cpaame.htm
---------------------------------------------------------------------
"A dog is not just for Christmas, there may be some left for
sandwiches on Boxing Day" - Vladimir Illich Ulyanov 1920
part 0 1150 bytes >I have seen 4066 switches used in similar applications; unfortunately, I
am not aware of anyone making a 74HCT4066--that would be a really useful
part [for those uninitiated, a 4066 or 74HC4066 is a digital switch which
may be used to switch any signal or voltage between its Vss (ground) and
VDD (supply) rails. Since the supply rail may be up to +15v, the device
may be used to conveniently switch programming voltage and other such
signals. Unfortunately, the switching threshhold for "standard" CMOS or
74HC parts is VDD/2; if VDD is 12 volts this means the switching thresh-
hold is at least 6 volts--not something a normal port can deal with. The
74HCT series of parts switches at around two volts independent of supply
and would be ideal in this application.]
>Actually, this gets back to a question I was asking before: what is the
maximum allowable voltage on the RA4 pin (16C84 etc.)? The documentation
says there's no diode to VDD, but it doesn't grand permission to go above
VDD even so.
As I wrote in another reply, the 'absolute maximum ratings' state 14V on RA4,
but as you write there's no 'design ratings'.
>>Hi Conor, here SET:
>>Some time ago I made an EPROM programmer for PC and I see this problem, you
>>can:
>>1) Use an external power supply attached to your board.
>>2) Use an step-up converter (DC-DC), for example a 78S40 switching chip.
>>3) Use a simple voltage doubler with 2 diodes and 2 capacitors, this solution
>>is the simplest but you'll be loosing the 70% of the power, that's isn't a
>>problem in a PC where the 12V supply can drain 8 A (Not to one slot!!).
>>
>>bye SET.
>>
>Option #3 is not an option... A voltage doubler like this works on AC, not
DC!
>...
>Robert
Robert, you don't need AC you only need an square wave, you can generate the
square wave with the PIC and amplify it with a transistor, you can generate the
square wave with 2 transistors or a 555 or a 4093 or any thing that you want.
I used this trick to handle a MOSFET in a car, for this task I needed at
least 8 V over the battery voltage, I solved this with an output of the PIC at
5KHz driving a transistor with 120mA of Ic (when satured) and 2 electrolitic
capacitor plus 2 diodes, the output is just the double of the battery and drops
4 V if you charge it with 40mA.
That's all, is cheap but ineficient in terms of transfered energy, but who
cares with a 12 V 8 A power source?
bye SET
********************************************************************************
Salvador Eduardo Tropea (SET) - EraseMEsalvadorspamBeGoneKILLspaminti.edu.ar
Work: INTI (National Institute of Industrial Technology) Sector: ICE
(Electronic Control & Instrumentation)
Post (Home): Curapaligue 2124 - Caseros (1678)- Buenos Aires - Argentina
Just a quick summary of replies and thanks for all those suggestions!
I forgot to mention that the PIC is a 'C84 but everyone was aware of
this...
There were lots of replies indicating that I should use a Mosfet or
relay instead of a transistor to switch in Vpp. The Mosfet is good as
it has very little voltage drop but a relay is a bit messy really.
Also suggestions that I use a DC-DC converter which is a good idea and
one that dawned on me just as I posted...Aaron Sliwinski suggested
looking on network cards or using MAX232s as cheap converters which
is really interesting!
I was originally thinking about using the ISA 12V rail but Mike Watson
said that "From experience, the PCs 12V rail is not very useful. The
PC to PC variation is too high." So the best thing to do is use
a switcher IC like those used for programming flash memory - at
least here you _know_ that you're getting enough voltage for Vpp.
Also Andy Errington said:
"It is important to note that the Vpp voltage is not actually
used to power the programming process, it is simply the presence of a
voltage at this level that sets the '84 into program mode. The actual
programming voltage for the EEPROM is internally generated."
This I wasn't aware of and I was assuming that the process was similar
to EPROM. It means that a) I don't have to supply much power for Vpp and
b) that I should go back and read the data sheet more closely :-)
You can get switcher ICs capable of a couple of milliamps for a pound
or two.
Thanks again - this seems to be a really active mailing list. 70 messages
this morning!
Nice Thread :^) Ah the world is full of nay sayers. You may have a nice
niche product here. The MAC and NT users may have a solution. Good Luck!
What platform BeOS designed for and what are its attributes?
- -Mark
>>> David Negro <RemoveMEdln2spamBeGonespamCORNELL.EDU> 9 October 1996 1:33 pm >>>
>Why not change platforms? He who fears change, fears progress.
>Besides I'm sure whatever you got for the IBM would be much easier to use
>than anything you could write yourself, and it would be updated by the
>companies without you haveing to constantly re-write it.
>
>So:
>Buy a IBM.
First off I would like to apologize for having started all this, although
it was not my intention.
Secondly, I am familiar with many operating systems including MacOS,Un*x,
Linux, OpenWin, MS Windows, DOS, and have even had a chance to play with
the new up and coming BeOS (Way COOL!!) The problem here is not the
disinterest in changing systems, but rather the resources. I am a college
student, on a college budget. Not only do I not want to buy another
computer at this point, but I do not want to transport it in the few moves
that I have left.
Thirdly, I don't do projects because they are easy. I do projects because
they interest me and I think that I will learn something from them. Yes it
would be easier to go out an buy a PC and a programmer, but what have I
gained in terms of knowledge from it? Nothing really. I would then be
limited to that platform and that programmer. By doing it myself, I get a
better understanding of the PIC programming process as well as a better
understanding of PICs in general. If I had a project for PICs already
lined up, and I was in a time crunch, and I had the resources (cash), I
would have no difficulty in changing systems. As is, making a programmer
is a project of it's own, keeps me busy and keeps the noodle working.
So if you want to go the easy way, follow OTHER people's footsteps, then be
my guest. Personally, when the resources are not available, I like to fill
in the gaps myself. You can't always rely on other people and need to be
able to do things for yourself!
Lastly, Thank you to the people that did respond to my main question about
the programming problem. I have not had time to look into the problem
further, but will get to that shortly. Thanks.
P.S. - Also remember that I using a Motorola 68HC11 microcontroller as the
base for my programmer. When I work out the last of my bugs, anyone with a
rs232 terminal will be able to use my programming setup. People should
not be stuck to any one computer because I will have to agree that each
computer has its advantages and disadvantages.
Since the supply rail may be up to +15v, the device may be used to
conveniently switch programming voltage and other such signals.
Unfortunately, the switching threshhold for "standard" CMOS or 74HC
parts is VDD/2; if VDD is 12 volts this means the switching thresh-
hold is at least 6 volts--not something a normal port can deal with.
Um, 6 to 12 volts is well within the range of an "open collector" driver
like the 7407, or have those ceased to exist?
>
> [...]
> >I have seen 4066 switches used in similar applications; unfortunately, I
> am not aware of anyone making a 74HCT4066--that would be a really useful
> part [for those uninitiated, a 4066 or 74HC4066 is a digital switch which
> may be used to switch any signal or voltage between its Vss (ground) and
> VDD (supply) rails. Since the supply rail may be up to +15v, the device
> may be used to conveniently switch programming voltage and other such
> signals. Unfortunately, the switching threshhold for "standard" CMOS or
> 74HC parts is VDD/2; if VDD is 12 volts this means the switching thresh-
> hold is at least 6 volts--not something a normal port can deal with. The
> 74HCT series of parts switches at around two volts independent of supply
> and would be ideal in this application.]
> [...]
If I remeber right than be aware of the allowed supply voltage of the
74HC(T/U) parts, because the maximum value is just 6V !
(74HC(U): 2 - 6V / 74HCT: 4.5-5.5V + TTL-compatible input levels)
So if you want to switch above 6V (like 12V) use a 40xx part. The
(absolut) maximum ratings for the 40xx are 18V (To be sure, look into a
datasheet because, as far as I know, it differs a little bit from
producer to producer ).
Can anyone tell me if the 16C74 or 16C73 can be programmed on the fly
(in-circuit).
If so what is the best way of doing it?
If not can it be programmed down it's serial port?
>
> Can anyone tell me if the 16C74 or 16C73 can be programmed on the fly
> (in-circuit).
You are aware that since these parts are EPROM based and not EEPROM based
that they can only be programmed once. Unless you do the somewhat odd
practice of bathing the entire board with UV light.
> If so what is the best way of doing it?
All the 16CXX parts can be programmed serially AFAIK. You need clock and
data to RB6 and RB7, 13V to MCLR, and GND.
> If not can it be programmed down it's serial port?
Nope.
Can you give some detail as to what your trying to do?
>
>Also Andy Errington said:
>
>"It is important to note that the Vpp voltage is not actually
>used to power the programming process, it is simply the presence of a
>voltage at this level that sets the '84 into program mode. The actual
>programming voltage for the EEPROM is internally generated."
>
>This I wasn't aware of and I was assuming that the process was similar
>to EPROM. It means that a) I don't have to supply much power for Vpp and
>b) that I should go back and read the data sheet more closely :-)
>You can get switcher ICs capable of a couple of milliamps for a pound
>or two.
Yes, I was wrong when I said 25mA. For the EEPROM devices, programming
current is drawn from Vdd and current not Vpp. Sorry for my misinformation.
-Jim
>Thanks again - this seems to be a really active mailing list. 70 messages
>this morning!
>
>Conor O'Rourke
>Dublin, Ireland
>
>
Here is my problem:
A little background first.
I have a 16C84 in-curcuit and need to re-program it. I have a PicStart
Plus with the latest software with firmware V1.01.
The hardware design is proven and does work, if the programming takes
hold. In the circuit is an LED and a piezo speaker, this willbe become
important later.
When programming the PIC, it always fails, unless I connect the battery
or if I connect the ground lead of my osciliscope to the negative
battery lead. Then the Picstart says success, but the program does not
work. If I program a PIC out of circuit, the program works fine,
however, it is almost impossible wo remove the SOIC version of the PIC
from the production units.
Anyway, When programming the PIC without the batter connected and my
test programing that will click the speaker and flash the LED programmed
with the battery connected, the speaker clicks and the LED flashed as it
would if the program is running.
In another unit of the same circuit, I dont have any problems, the
circuits are identical.
What is going on here, and what can I do to make this work reliably?
Is it the PicStart?
Any suggestions or help would be greatly appreciated.
--
Alan Nickerson
---------
It seems to me that the best new ideas come from
people who don't know that they "can't". -- Paul Mathews, .....optoengRemoveMEWHIDBEY.COM
I've programmed several PIC16C64 40pin devices that are UV erasable. I then
bought 2 PIC16C64-20/L OTP 44pin PLCC devices. I built a 44pin PLCC to 40pin
DIP adapter (triple checked the pinout).
First I tried using PICStart Plus's CheckBlankOTP option and it said the device
was not blank. It also said the code-protect fuse was on and the clock was set
to RC. I tried programming the device anyway and it seemed to take forever.
It finally stopped about halfway so I cancelled it. When I read the device
again
the code-protect fuse was off and the clock was still RC (even though I was
programming it for HS). The ROM data was something like 390A (hex) everywhere,
not my code.
Any ideas? Did I get two bad PICs from DigiKey? (I doubt it). What did I do
wrong?
This may sound like a silly question but....
I've been reading the PIC data sheets and I understand the PIC
pretty well and how it's programmed but I'm puzzled by one thing
- the clock source.
The data sheet indicates that you need a clock source to program
the PIC (I'm using the PIC16C84 here), but it doesn't specify
what happens when you set the Config fuses such that the clock
source is changed. For example if you are using RC and you set
the fuses for XT does the system stop?? Personally, I would think
that fuse setting would not take effect until next MCLR# but
you never know! Also, my impression is that the PIC as supplied
would be set as RC (EEPROM all 1s) and so what would happen if
you used a crystal while the fuses were set as RC or
vice versa. Will damage result? Looking at the input circuit it
is very hard to know.
Hmm, I think I might just give up and spend the cash on the PicStart
Plus - it might be worth it :-)
>
> Hi!,
>
> This may sound like a silly question but....
> I've been reading the PIC data sheets and I understand the PIC
> pretty well and how it's programmed but I'm puzzled by one thing
> - the clock source.
> The data sheet indicates that you need a clock source to program
> the PIC (I'm using the PIC16C84 here),
This is an incorrect assertion. The clock isn't involved in programming.
> but it doesn't specify
> what happens when you set the Config fuses such that the clock
> source is changed. For example if you are using RC and you set
> the fuses for XT does the system stop?? Personally, I would think
> that fuse setting would not take effect until next MCLR# but
> you never know! Also, my impression is that the PIC as supplied
> would be set as RC (EEPROM all 1s) and so what would happen if
> you used a crystal while the fuses were set as RC or
> vice versa. Will damage result? Looking at the input circuit it
> is very hard to know.
The data sheet makes it very clear that a crystal shouldn't be hooked up
when the chip is in RC mode.
The issues you raise are important for in system programming. But if you're
building your own programmer, there should be no oscillator of any type
hooked up to the PIC.
> Hmm, I think I might just give up and spend the cash on the PicStart
> Plus - it might be worth it :-)
Maybe. But check out the Web for the myriad of 16C84 programming
circuits that are out there if you're interested in the cheap solution.
When programming a PIC, you're supplying a clock signal externally, so
that the configured clock doesn't really apply.
______________________________ Reply Separator _________________________________
Subject: PIC programming
Author: KILLspamCOROURKETakeThisOuTCCVAX.UCD.IE at internet
Date: 11/5/96 2:55 PM
Hi!,
This may sound like a silly question but....
I've been reading the PIC data sheets and I understand the PIC
pretty well and how it's programmed but I'm puzzled by one thing
- the clock source.
<snip>
>Hi!,
>
>This may sound like a silly question but....
>I've been reading the PIC data sheets and I understand the PIC
>pretty well and how it's programmed but I'm puzzled by one thing
>- the clock source.
>The data sheet indicates that you need a clock source to program
>the PIC (I'm using the PIC16C84 here), but it doesn't specify
>what happens when you set the Config fuses such that the clock
>source is changed. For example if you are using RC and you set
>the fuses for XT does the system stop?? Personally, I would think
>that fuse setting would not take effect until next MCLR# but
>you never know! Also, my impression is that the PIC as supplied
>would be set as RC (EEPROM all 1s) and so what would happen if
>you used a crystal while the fuses were set as RC or
>vice versa. Will damage result? Looking at the input circuit it
>is very hard to know.
>Hmm, I think I might just give up and spend the cash on the PicStart
>Plus - it might be worth it :-)
>
>Thanks,
>
> Conor O'Rourke.
Conor,
You are misreading the 16C programming specs. The only "Clock source" required
is the synchronous "CLK" signal on RB6, NOT the parts "OSC" clock.
In fact, if you really read the (later) programming specs closely, you will
see
that the external "OSCillator" should be disabled.
Take it from me, the OSCillator clock is not required for programming and
indeed
can be a nuisance in the case of ISP.
As the part does NOT use the external OSCillator, the state of the OSC
fuses is completely irrelevant.
However, for the 17Cxx series, it is a different matter. These devices are
self-programming or "Bootstrap programmed" (like the 68705s) and DO require
the
on board OSCillator to be driven. NOW the state of the OSC fuses do make a
difference!
If you read the 17Cxx programming specs, you will see that an external clock
is required with sufficient swing and drive to OVERPOWER whatever OSC type is
selected. In other words, for the 17Cxx parts the "brute force method" is
used.
> You are misreading the 16C programming specs. The only "Clock source" required
> is the synchronous "CLK" signal on RB6, NOT the parts "OSC" clock.
> In fact, if you really read the (later) programming specs closely, you will
> see
> that the external "OSCillator" should be disabled.
Ahhh. That explains it. I think I was misreading the programming specs.
I don't have them with me at the moment. When I get home I'll look at them
again. I think I was thrown by the specs that said clock between 4-10MHz
in the programming section...I assumed therefore that the clock had to
be present.
As someone else commented the data sheet _does_ say that operation with
a crystal while on RC mode will cause damage. Funny the way data sheets
don't tell you what'll happen generally. They say "operation in this
mode is not recommended" or similar, not "do this and smoke will appear"
:-0
>
> Take it from me, the OSCillator clock is not required for programming and
> indeed
> can be a nuisance in the case of ISP.
It's going to be a nuisance then :-). I think I'll gate Vpp to disable
the external clock (from an ISA bus) when I'm programming the device in
circuit. Either that or make sure I get the program right first time...
nah...it's a pain ripping an ISA card in and out of circuit.
>
> As the part does NOT use the external OSCillator, the state of the OSC
> fuses is completely irrelevant.
>
> If you read the 17Cxx programming specs, you will see that an external clock
> is required with sufficient swing and drive to OVERPOWER whatever OSC type is
> selected. In other words, for the 17Cxx parts the "brute force method" is
> used.
>
> Jim
Jim, please elaborate on how the clock can cause problems with
programming, particularly with an in-circuit programming setup. If this
is indeed the case (so far I've had no problems, but I've only played
around a little bit), suggestions for disabling the clock during
programming, in an in-ciruit environment?
Larry
>----------
>From: Jim Robertson[SMTP:TakeThisOuTnewfoundspam_OUTNE.COM.AU]
>Sent: Wednesday, November 06, 1996 1:58 PM
>To: Multiple recipients of list PICLIST
>Subject: Re: PIC programming
(snip)
>Take it from me, the OSCillator clock is not required for programming and
>indeed
>can be a nuisance in the case of ISP.
>
>(Snip)
> Jim, please elaborate on how the clock can cause problems with
> programming, particularly with an in-circuit programming setup. If this
> is indeed the case (so far I've had no problems, but I've only played
> around a little bit), suggestions for disabling the clock during
> programming, in an in-ciruit environment?
From my experience, it appears the same counter is used for the ISP address
as is used for the "program counter". Normally, holding /MClr low before
entering ISP mode will ensure that this register is zero at the start of
programming. If, however, /MClr rises too slowly the PIC may start executing
code before entering ISP mode. If this happens, then programming will start
wherever code was executing, rather than at address zero. Disabling the
clock will avoid this phenomenon.
At 11:11 PM 11/6/96 -0600, you wrote:
>> Jim, please elaborate on how the clock can cause problems with
>> programming, particularly with an in-circuit programming setup. If this
>> is indeed the case (so far I've had no problems, but I've only played
>> around a little bit), suggestions for disabling the clock during
>> programming, in an in-ciruit environment?
>
>>From my experience, it appears the same counter is used for the ISP address
>as is used for the "program counter". Normally, holding /MClr low before
>entering ISP mode will ensure that this register is zero at the start of
>programming. If, however, /MClr rises too slowly the PIC may start executing
>code before entering ISP mode. If this happens, then programming will start
>wherever code was executing, rather than at address zero. Disabling the
>clock will avoid this phenomenon.
Yer, that is what I was refering to. When I was developing my programer's ISP
port, I had this problem. Amazingly as the same thing happened for both the
programming and verify cycles with the program counter ending up at the same
address. Therefore the problem was not evident until you actually tried to
use
the chip.
This one took a bit of head scratching before the penny dropped. The remedy
is to have only a very short delay between Vdd rise and Vpp rise. This is now
stated in the programming specs but back then it wasn't. We did it hard in the
early days!
PHOENIX Shareware Picstart 16B upgrade coming.
For more details, send email to .....newfoundEraseMEne.com.au with
"subscribe phoenix mail list" in the BODY of the message.
--------------------------------------------------------
> > You are misreading the 16C programming specs. The only "Clock source"
required
> > is the synchronous "CLK" signal on RB6, NOT the parts "OSC" clock.
> > In fact, if you really read the (later) programming specs closely, you will
> > see
> > that the external "OSCillator" should be disabled.
>
> Ahhh. That explains it. I think I was misreading the programming specs.
> I don't have them with me at the moment. When I get home I'll look at them
> again. I think I was thrown by the specs that said clock between 4-10MHz
> in the programming section...I assumed therefore that the clock had to
> be present.
I had a look and I know where I went wrong. I was looking for info about
CLKIN in programming mode and I couldn't find it. What I _did_ do was
open the data book at the wrong page - the 17CXX ac/dc specifications
where I saw "CLKIN 4 - 10MHZ" and click, I seized on that. Serves me
right for reading data sheets at 1 in the morning. :-)
BTW, someone else was asking about disable in the click in an in circuit
environment. Well, if you can gate MCLR so that 13V is applied it should
be no problem to use the same sequence to disable the clock.
>
>I had a look and I know where I went wrong. I was looking for info about
>CLKIN in programming mode and I couldn't find it. What I _did_ do was
>open the data book at the wrong page - the 17CXX ac/dc specifications
>where I saw "CLKIN 4 - 10MHZ" and click, I seized on that. Serves me
>right for reading data sheets at 1 in the morning. :-)
Well, fer cryin' out lound, when else WOULD you read them? Surely you
wouldn't want to be up at the godawful hour of ten in the morning, would
you? ;-)
-Matt
"DOS Computers manufactured by companies such as IBM, Compaq, Tandy, and
millions of others are by far the most popular, with about 70 million
machines in use wordwide. Macintosh fans, on the other hand, may note that
cockroaches are far more numerous than humans, and that numbers alone do
not denote a higher life form."
In a project that I am quoting for, my client wants to
program the PIC serially in-circuit from the main processor
on the board. (The PIC is a small part of the whole project).
In the programming specs, Microchip recommend that Vpp and
Vcc be varied during the programming procedure for
production programming.
Are these production programming techniques necessary when
programming in-circuit? What experiences do you guys on the
list have with this?
> I am currently using pic 16C84-04 but find this part is now only
> supplied as a FLASH ROM device (pic 16F84-04) instead of EEprom.
>
> Do you know if modifications are required to the parallel port
> programmer as per Tait, Manning (NZ) etc to use the FLASH pic 84?
Andrew:
The "Flash ROM" change is ONLY a name change; there is NO
memory-architecture difference between what used to be called the
EEPROM 16C84A and what is now called the Flash 16F84.
Microchip is under the (mistaken, I think) impression that "Flash" is
a generic term for "electrically-erasable".
Microchip is under the (mistaken, I think) impression that "Flash" is
a generic term for "electrically-erasable".
Nonsense. Microchip is under the impression that "flash" is a more
marketable buzzword than EEPROM, and that they can get away with calling
their chips "flash microcontrollers" to compete with the likes of Atmel, TI,
and Motarola; regardless of the details of the underlying electronics.
I think they're probably right.
It would be an interesting case of poetic justice if Intel's lawyers showed
up on their doorstep claiming infringement of the flash patents...
> > Microchip is under the (mistaken, I think) impression that
> > "Flash" is a generic term for "electrically-erasable".
>
> Nonsense. Microchip is under the impression that "flash" is a more
> marketable buzzword than EEPROM
Bill:
I agree with your analysis, but I was enunciating Microchip's
OFFICIAL position on the matter, not my interpretation of it.
In a telephone converstaion with the factory, I was told in so many
words that "'Flash' has become a generic term for 'electrically-
erasable non-volatile memory'."
Later, on the PICLIST, Brian Boles at Microchip said:
"As far as we know, the Atmel "Flash" parts use the same basic
technology as we do. If it looks like ...., and smells like
...., it must be ...."
As usual I have this problem ... I haven't seen anything written about
serial in-circuit programming of the 16LC84, aside from the little bit in
the data book on page 52. I hadn't paid much attention to it until
recently; that is, now that I know I have to use an SOIC package device in
the final product design.
I see in-circuit programming to be very advantageous, since it will allow us
to load a routine for hardware verification during manufacturing test, and
then re-program the 16LC84 with the operating code ... all without
disturbing the hardware.
Trouble is I can't find anything in my MPLAB or Picstart PLus manuals (or
the Microchip CD) about considerations for in-circuit programming: neither
how one should size the isolating resistors shown on page 52, nor the
availablilty of a commercial serial programmer. Is it one of those things
that's "left as an exercise for the reader", or is there a product already
available to do the job?
Because of time constraints, I'd rather buy than build one, but building is
still do-able. Perhaps it's nothing more than building a driver/buffer
stage between my Picstart and the application circuit? Does anyone out
there have any good pointers for in-cicuit programming?
At 04:10 AM 12/10/96 -0500, you wrote:
>Dear PIC'ers
>
>As usual I have this problem ... I haven't seen anything written about
>serial in-circuit programming of the 16LC84, aside from the little bit in
>the data book on page 52. I hadn't paid much attention to it until
>recently; that is, now that I know I have to use an SOIC package device in
>the final product design.
>Trouble is I can't find anything in my MPLAB or Picstart PLus manuals (or
>the Microchip CD) about considerations for in-circuit programming: neither
>how one should size the isolating resistors shown on page 52, nor the
>availablilty of a commercial serial programmer. Is it one of those things
>that's "left as an exercise for the reader", or is there a product already
>available to do the job?
>
>Many thanks,
>... Gregg
>
Gregg,
It is starting to be a little dated now, but you can download the
documentation for my PP1 programmer. It has a chapter on ISP and what I
know about it back then. You may find the knowledge contained of value,
then again you might not....
It is in the FTP section of my web grossly neglected web site at.
Recently I bought a Parallax PIC16Cxx programmer to program a PIC16C622.
With this package came the software (of course), including the PSIM
simulator. Unfortunately it doesn't support the 16C622. Does anybody know
if I can get a software-update. And where? Any suggestions are highly
appreciated.
Just because Intel and the Japanese suppliers were dumping commodity
Flash Memories at prices below commodity EPROM devices, now everyone
thinks that Flash on a micro is cheaper than EPROM.
As for "Flash" = "electrically eraseable"; don't blame us. Until the
industry press like EDN decide to be more precise in their technical
details or at least review press releases before they are printed, the
marketing folks at our competitors will be able to put a "spin" on
technology. Everyone else will have to follow along or be left behind
the noise.
Rgds, Brian.
______________________________ Reply Separator _________________________________
Subject: Re: Query - Programming the FLASH PIC16F84-04 ?
Author: William Chops Westfield <RemoveMEbillwRemoveMERemoveMECISCO.COM> at Internet_Exchange
Date: 12/9/96 10:08 PM
Microchip is under the (mistaken, I think) impression that "Flash" is
a generic term for "electrically-erasable".
Nonsense. Microchip is under the impression that "flash" is a more
marketable buzzword than EEPROM, and that they can get away with calling
their chips "flash microcontrollers" to compete with the likes of Atmel, TI,
and Motarola; regardless of the details of the underlying electronics.
I think they're probably right.
It would be an interesting case of poetic justice if Intel's lawyers showed
up on their doorstep claiming infringement of the flash patents...
> As usual I have this problem ... I haven't seen anything written about
> serial in-circuit programming of the 16LC84, aside from the little bit in
> the data book on page 52. I hadn't paid much attention to it until
> recently; that is, now that I know I have to use an SOIC package device in
> the final product design.
In-circuit programming is wonderful, if you are aware of its constraints.
> I see in-circuit programming to be very advantageous, since it will allow us
> to load a routine for hardware verification during manufacturing test, and
> then re-program the 16LC84 with the operating code ... all without
> disturbing the hardware.
Great for debugging (before and after production) too...
> Trouble is I can't find anything in my MPLAB or Picstart PLus manuals (or
> the Microchip CD) about considerations for in-circuit programming: neither
> how one should size the isolating resistors shown on page 52, nor the
> availablilty of a commercial serial programmer. Is it one of those things
> that's "left as an exercise for the reader", or is there a product already
> available to do the job?
I don't know about commercial serial programmers; I know I've built two of
my own, and incorporated circuitry directly onto the boards for a couple
other products. As for software, I'm afraid I don't know; my good stuff I
developed for work, and I don't know if I can give it away.
As for the isolation resistors, that really depends upon your application;
if you are using RB6 and RB7 for output only, you can skip the resistors
entirely (though you need to ensure that whatever they control won't "mind"
if these mins have signals on them during programming). If they are inputs
only, the resistors can be large, subject only to the constraint that large
values may slow down the response of the port. The final caveat to consider
is that if the PC is to be left connected you may want to have it wired so
as to be able to "tri-state" itself from those two pins or else use a relay
on your programmer to disconnect those pins entirely.
> Because of time constraints, I'd rather buy than build one, but building is
> still do-able. Perhaps it's nothing more than building a driver/buffer
> stage between my Picstart and the application circuit? Does anyone out
> there have any good pointers for in-cicuit programming?
I wouldn't be surprised if the PicStart could handle ISP'ing easily; I've
never done it. One concern I'd have regarding your application, however,
is that I'd suggest if possible using RB6 and RB7 for outputs only (or else
for nothing at all) and putting moderately large (e.g. 47K) resistors in
series with the RB6 and RB7 wires. Since you're using the LC part, it sounds
as if your voltage won't always be at a nice even +5; when programming, you
should have VDD at +5, but you should also verify your part at whatever volt-
age it will be running in the "real world".
>Because of time constraints, I'd rather buy than build one, but building is
>still do-able. Perhaps it's nothing more than building a driver/buffer
>stage between my Picstart and the application circuit? Does anyone out
>there have any good pointers for in-cicuit programming?
>
>Many thanks,
>... Gregg
I'm currently developing a serial programmer. The following will be some
of its features:
* Still the power from the computer. (No damm adaptor needed).
* Connects to the serial port.
* Smallest desing posible. I'm trying to fit it into the D-sub case.
* Modularity. Have the posibility of connecting a 5 pin cable or
adaptors with ZIF sockets.
* Production quality. Verify the PIC for all ranges of voltages (this is
just a wish which probably won't be able to do, at least on the size
that I want).
* RS232 comm capabilities? I was planning on using a MAX232 chip to
handle serial communications using pins B6 and B7 (since most of my
applications use the computer for communications). This might be
implemented in a module due to size constraints.
* Free??? My design will probably be free. I will plan on selling the
kits to put it together or just sell the board (this depends on whether
there is enough interest to send it to a production place).
Anyway, the desing should be complited by mid Jan or Feb. Let me know if
you guys are interested since that would make me do it faster and also
how many of you would like to purchase at least the board (so that I
send it to a production place).
> Just because Intel and the Japanese suppliers were dumping commodity
> Flash Memories at prices below commodity EPROM devices, now everyone
> thinks that Flash on a micro is cheaper than EPROM.
Hey, call up Digi-Key and ask for pricing on the 16C84 and 16F84...
> s.carleton.ca writes:
> >Dear PIC'ers
> >
>
> [Deleted stuff]
>
> >Because of time constraints, I'd rather buy than build one, but building is
> >still do-able. Perhaps it's nothing more than building a driver/buffer
> >stage between my Picstart and the application circuit? Does anyone out
> >there have any good pointers for in-cicuit programming?
> >
> >Many thanks,
> >... Gregg
>
> I'm currently developing a serial programmer. The following will be some
> of its features:
>
> * Still the power from the computer. (No damm adaptor needed).
> * Connects to the serial port.
> * Smallest desing posible. I'm trying to fit it into the D-sub case.
> * Modularity. Have the posibility of connecting a 5 pin cable or
> adaptors with ZIF sockets.
> * Production quality. Verify the PIC for all ranges of voltages (this is
> just a wish which probably won't be able to do, at least on the size
> that I want).
> * RS232 comm capabilities? I was planning on using a MAX232 chip to
> handle serial communications using pins B6 and B7 (since most of my
> applications use the computer for communications). This might be
> implemented in a module due to size constraints.
> * Free??? My design will probably be free. I will plan on selling the
> kits to put it together or just sell the board (this depends on whether
> there is enough interest to send it to a production place).
>
> Anyway, the desing should be complited by mid Jan or Feb. Let me know if
> you guys are interested since that would make me do it faster and also
> how many of you would like to purchase at least the board (so that I
> send it to a production place).
>
> Cheers,
>
> Alberto
>
> Dear PIC'ers
>
> As usual I have this problem ... I haven't seen anything written about
> serial in-circuit programming of the 16LC84, aside from the little bit in
> the data book on page 52. I hadn't paid much attention to it until
> recently; that is, now that I know I have to use an SOIC package device in
> the final product design.
>
> I see in-circuit programming to be very advantageous, since it will allow us
> to load a routine for hardware verification during manufacturing test, and
> then re-program the 16LC84 with the operating code ... all without
> disturbing the hardware.
>
> Trouble is I can't find anything in my MPLAB or Picstart PLus manuals (or
> the Microchip CD) about considerations for in-circuit programming: neither
> how one should size the isolating resistors shown on page 52, nor the
> availablilty of a commercial serial programmer. Is it one of those things
> that's "left as an exercise for the reader", or is there a product already
> available to do the job?
>
> Because of time constraints, I'd rather buy than build one, but building is
> still do-able. Perhaps it's nothing more than building a driver/buffer
> stage between my Picstart and the application circuit? Does anyone out
> there have any good pointers for in-cicuit programming?
>
> Many thanks,
> ... Gregg
Recently I bought a Parallax PIC16Cxx programmer to program a PIC16C622.
With this package came the software (of course), including the PSIM
simulator. Unfortunately it doesn't support the 16C622. Does anybody know
if I can get a software-update? And where? Any suggestions are highly
appreciated.
Thanks in advance,
Henk
Date and time sent: 12/17/96 9:29 AM
By:
Henk Renting
University of Twente
EL/TN, division LDG
Mullerplein
Enschede,
The Netherlands
e-mail: TakeThisOuTh.h.rentingspam_OUTel.utwente.nl
This sounds to me like it is both impossible and stupid trying it but I have
heard that the plastic cases on prom PICs are only opaque to uv and the
devices can still be erased with longer erase times. I don't believe it but
if it were true it would save a lot of development costs buying windowed
ceramic devices.
>This sounds to me like it is both impossible and stupid trying it but I have
>heard that the plastic cases on prom PICs are only opaque to uv and the
>devices can still be erased with longer erase times. I don't believe it but
>if it were true it would save a lot of development costs buying windowed
>ceramic devices.
>
>Comments on this would be nice
> Tim
I hear that low level X-rays can erase these devices, period of times unknown
and resulting reliability unknown. I understand there is a company in USA
that does this with the 68HC705C8 ? - Any body comment here ?
I suppose it wouldn't be too difficult to set up a verify program to
repetitively read back the EPROM whilst it was under 'radiation' - the
important thing would be to do it safely - if at all !
I wonder if an old monitor, with the EHT turned up might do it ?
Rgds
Mike
There is no a'priori reason that the ultimate truth will be interesting
or even useful, those moments of frustration during philosophical debate
would be replaced by the sheer terror which accompanies true knowledge.
At 16:09 31.12.96 +0800, you wrote:
>I suppose it wouldn't be too difficult to set up a verify program to
>repetitively read back the EPROM whilst it was under 'radiation' - the
>important thing would be to do it safely - if at all !
I would not power the PIC while radiated with x-rays, because the radiation
will also have influence on the digital logic. So you you could have
latch-up or something worse.
I am helping a friend build Francis Decks PIC programmer. The only source
for the LM10 opamp is Farnell (in Britian) and the prrice is over £8
excluding vat. Can anyone supply a transistor circuit for this purpose (5V
>from pic when on giving 14V programming circuit and 0V when off). The
emitter follower circuit can't be used due to the effect giving only approx
5v out so a dual transistor circuit must be used. Does anyone know a
circuit that would work?
Too right. It would erase the PIC in my programmer too. And where would I
get my hands on an xray source at school with all the safety regulations?
Thanks for the replies.
Tim
>I would not power the PIC while radiated with x-rays, because the radiation
>will also have influence on the digital logic. So you you could have
>latch-up or something worse.
>
>Wolfram
>
>At 16:09 31.12.96 +0800, you wrote:
>>I suppose it wouldn't be too difficult to set up a verify program to
>>repetitively read back the EPROM whilst it was under 'radiation' - the
>>important thing would be to do it safely - if at all !
>
>I would not power the PIC while radiated with x-rays, because the radiation
>will also have influence on the digital logic. So you you could have
>latch-up or something worse.
Would depend on the frequency of the X-ray source and its intensity...
Anyway you could always power the PIC through a current limited supply
and force power removal and re-application should an over current be
detected - with the outputs open you could over-current test at say 10mA ?
You would only have to power up the unit for long enouigh to do a blank
check - and say every 10 seconds or so whilst under the X-ray source ?
Rgds
Mike
Socrates once gave the advice to "by all means get married... If you
get a good wife you will become happy, if you get a bad one you will
become a philosopher."
Become an Engineer and avoid making this problematic decision.
I don't know the requirments of the circuit. If you can give them to me.
I'll see what I can do. In exchange, how about a copy ( schematic ) and
some info on the programmer.
About the circuit, it provides the programming voltage on MCLR and normally
keeps the pic in reset. The opamp is a ridiculous price so some other
circuit must be available
Thanks
Tim
At 23:23 07/01/97 -0800, you wrote:
>Hello!
>
>I don't know the requirments of the circuit. If you can give them to me.
>I'll see what I can do. In exchange, how about a copy ( schematic ) and
>some info on the programmer.
>
>Thanks,
>David
>
Further to my question on the 74 programmer, I've read a bit more of
the new data sheet and it would appear that if the 'old' programmer
were to program the 74A version then it would be a sheer fluke.
According to the data sheet the config word has more valid bits
available. For code protection to work, bits 13 to 8 need to be set
010101 or 101010. Also the Brown out feature will be enabled or
disabled depending on how the programmer is set up as this bit was
unavailable on the 74.
In light of this it would seem I need either a new programmer or some
sort of upgrade.
Such is progress.
Thanks for the help so far
Tony
Just when I thought I knew it all,
I learned that I didn't.
Mike wrote:
>
> Hi gals and guys,
>
> Dorry if this has been covered before - I've missed so many emails :{
>
> I need a real small (portable) and economical programmer for the 12C50X
> series, can I use the David Tait's unit ?
>
> The hardware looks as if its capable ?
>
> But do I have to write my own downloading software or has someone done it
> already ?
>
> Rgds
>
> Mike
> spam_OUTerazmusRemoveME.....wantree.com.au
Try: http://www.sistudio.com/
for SiStudios PIP02 software. Support is there for 508 and 509's using
David Tait's programmer, however it may not be fully tested.
Perhaps someone on the list knows more about this.
SLI, the serial LCD that auto detects baud rates from 30 to 125K bps.
SimmStick(tm) A PIC proto PCB the size of a 30 pin Simm Memory Module.
EASY PIC'n Beginners Guide to using PIC 16/17 MicroChip products.
> I need a real small (portable) and economical programmer for the 12C50X
> series, can I use the David Tait's unit ?
>
> The hardware looks as if its capable ?
> Rgds
>
> Mike
Try the ProPic avaible in my homepage.
Octavio
========================================================
Octavio Nogueira
e-mail: spamnogueiraspam_OUTmandic.com.br
homepage: www.geocities.com/SiliconValley/Pines/6902
voice/fax: +55 11 240-6474
"ProPic" The first Production PIC Programmer running in
Windows and under US$ 20.00.
========================================================
> I need a real small (portable) and economical programmer for the 12C50X
> series, can I use the David Tait's unit ?
>
> The hardware looks as if its capable ?
> Rgds
>
> Mike
Try the ProPic avaible in my homepage.
Octavio
========================================================
Octavio Nogueira
e-mail: spam_OUTnogueiraspamBeGonemandic.com.br
homepage: www.geocities.com/SiliconValley/Pines/6902
voice/fax: +55 11 240-6474
"ProPic" The first Production PIC Programmer running in
Windows and under US$ 20.00.
========================================================
>> Hi gals and guys,
>
>> I need a real small (portable) and economical programmer for the 12C50X
>> series, can I use the David Tait's unit ?
>>
>> The hardware looks as if its capable ?
>
>> Rgds
>>
>> Mike
>
>Try the ProPic avaible in my homepage.
>
>Octavio
>========================================================
>Octavio Nogueira
>e-mail: EraseMEnogueiraKILLspammandic.com.br
>homepage: www.geocities.com/SiliconValley/Pines/6902
>voice/fax: +55 11 240-6474
>"ProPic" The first Production PIC Programmer running in
>Windows and under US$ 20.00.
>========================================================
>
>
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/ _/
_/ N A F Electronic _/
_/ M e x i c o _/
_/ _/
_/ e-mail: EraseMEnafpocRemoveMEmail.giga.com _/
_/ http://www.giga.com/~nafpoc _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
At 12:23 AM 1/23/97 -0600, you wrote:
>Does someone know where i can get 12C509/JW parts in USA?, i have try
>DigiKey, Future Dom. and some others and any of them have it in Stock.
Pablo,
I cannot find any of the 508/509 JW parts either. The only source I found
to get them was to sample them directly from Microchip. Suppliers had stock
for a while, then everything seems to have dried up.
I need to translate my ProPic PCB from Protel Advanced PCB 2.8 to Easytrax,
so anyone can use it. How can I do that?
Thanks,
Octavio
========================================================
Octavio Nogueira
e-mail: @spam@nogueiraEraseMEspammandic.com.br
homepage: www.geocities.com/SiliconValley/Pines/6902
voice/fax: +55 11 240-6474
"ProPic" The first Production PIC Programmer running in
Windows and under US$ 20.00.
========================================================
I need to translate my ProPic PCB from Protel Advanced PCB 2.8 to Easytrax,
so anyone can use it. How can I do that?
Thanks,
Octavio
========================================================
Octavio Nogueira
e-mail: nogueiraTakeThisOuTKILLspammandic.com.br
homepage: www.geocities.com/SiliconValley/Pines/6902
voice/fax: +55 11 240-6474
"ProPic" The first Production PIC Programmer running in
Windows and under US$ 20.00.
========================================================
I'd distribute the the Gerber and NCD files, Octavio. That would allow
builders to have a prototype PCB company make it or use GCPREVUE to print
it on a laser printer for etching and drilling at home.
-----------------------------------------------------------------------
Lynn Richardson | RemoveMElrichTakeThisOuTqni.com |Progress Instrument, Inc.
Design Engineer | wa0znl.ampr.org |807 NW Commerce Drive
Circuit Design DC to 1GHz| [44.46.176.3] |Lee's Summit, MO 64086
Asm 6805, Z8, 8051, PIC | |Phone: (816) 524-4442
C | |Fax: (816) 246-4556
> Hi,
>
> I need to translate my ProPic PCB from Protel Advanced PCB 2.8 to Easytrax,
> so anyone can use it. How can I do that?
>
> Thanks,
>
> Octavio
> ========================================================
> Octavio Nogueira
> e-mail: @spam@nogueiraSTOPspammandic.com.br
> homepage: www.geocities.com/SiliconValley/Pines/6902
> voice/fax: +55 11 240-6474
> "ProPic" The first Production PIC Programmer running in
> Windows and under US$ 20.00.
> ========================================================
>
I'd distribute the the Gerber and NCD files, Octavio. That would allow
builders to have a prototype PCB company make it or use GCPREVUE to print
it on a laser printer for etching and drilling at home.
-----------------------------------------------------------------------
Lynn Richardson | TakeThisOuTlrichTakeThisOuTRemoveMEqni.com |Progress Instrument, Inc.
Design Engineer | wa0znl.ampr.org |807 NW Commerce Drive
Circuit Design DC to 1GHz| [44.46.176.3] |Lee's Summit, MO 64086
Asm 6805, Z8, 8051, PIC | |Phone: (816) 524-4442
C | |Fax: (816) 246-4556
> Hi,
>
> I need to translate my ProPic PCB from Protel Advanced PCB 2.8 to Easytrax,
> so anyone can use it. How can I do that?
>
> Thanks,
>
> Octavio
> ========================================================
> Octavio Nogueira
> e-mail: spam_OUTnogueiraspam.....mandic.com.br
> homepage: www.geocities.com/SiliconValley/Pines/6902
> voice/fax: +55 11 240-6474
> "ProPic" The first Production PIC Programmer running in
> Windows and under US$ 20.00.
> ========================================================
>
my programmer (HiLo ALL-07) has - without hardware update - no
possibility to program a 12C5xx. But it supports all other types
of 16C5xx and 16Cxx. Can I hand-wire an adapter 18pin --> 8pin to
program a 12C5xx? What PIC type should I select to get the 12C5xx
programmed correctly?
I tried to compare the programming algorithms of 16C55x and 12C5xx
and they seem to be identical.
> my programmer (HiLo ALL-07) has - without hardware update - no
> possibility to program a 12C5xx. But it supports all other types
> of 16C5xx and 16Cxx. Can I hand-wire an adapter 18pin --> 8pin to
> program a 12C5xx? What PIC type should I select to get the 12C5xx
> programmed correctly?
>
> I tried to compare the programming algorithms of 16C55x and 12C5xx
> and they seem to be identical.
The programming algorithms are similar but not identical. The two biggest
areas of change:
[1] Top two bits of each 14 bit word read back as zero, even on a blank device.
[2] On power-up, PC is at $1FF instead of at $000. BEWARE--This one gave me
the hardest time before I figured it out...
At 01:35 PM 2/7/97 +0100, you wrote:
>Hi,
>
>my programmer (HiLo ALL-07) has - without hardware update - no
>possibility to program a 12C5xx. But it supports all other types
>of 16C5xx and 16Cxx. Can I hand-wire an adapter 18pin --> 8pin to
>program a 12C5xx? What PIC type should I select to get the 12C5xx
>programmed correctly?
>
>I tried to compare the programming algorithms of 16C55x and 12C5xx
>and they seem to be identical.
>
>Does anybody have an idea to that?
Our generic PIC programming software PIP02 is able to program 12C50x
on the Hi-Lo (Tribal) ALL and FLEX series programmers.
That is good news :)
Bad news is that the last public release of PIP02 does not do that :(
To be able to program 12C50x on generic PIC Programmers (like D. Tait,
AN589, TATO, etc) ver 1.17 is required that is current version available
for SiClub members
And for 12C50x and ALL-07 (or FLEX or ALL-03 or MOD-EMUP) version 1.18
is required. It will be uploaded to our site tonight.
WARNING!
An attempt to program 12C50x with old release of PIP02 and
UPT driver may damage your programmer!
UPT (Universal Programmer and Tester) Driver is very experimental,
and may not work for LPT connected programmers. We are testing it
with MOD-EMUP, functionally it is same as ALL-07 however the interface
is different. We have tested the UPT driver in ALL-07 mode with emulated
ALL-07 hardware, it seems to work, but hence no garantees.
At this time PIP02 ver 1.18 with UPT driver does program 12C50x
devices without adapters on MOD-EMUP Programmer.
And as what goes making an adapter for 12C50x to be used with hi-lo
software, it aint so simple.
Well if you make it and read like 16C558 then you are able to read
the device, with one word shifted data.
If you are able to make a 'word shifted' hexfile then it should be
possible to use 16C55x algorithms to program 12C50x devices.
For those are interested to have access to latest releases of PIP02
and to other software from Silicon Studio please contact some of
our distributors for conditions how to become SiClub member.
Other software offered free for members includes:
* BS/4 Editor and firmware: A 1/4th of stamp implemented in a single 16C84
(Interpreter, 64 bytes, COM port program download)
* BASCO a multi target Basic Compiler (PIC, AT89C2051, AVR, 68HC11,...)
* PICSI programs a 16C84 with stamp code (PIC programmer required)
* SIM2051 AT89C2051 simulator
* More to be announced.
Sorry folks if this was too long mail, I have been silent for long time :)
I previously posted "Can In-Circuit verify PIC16C73A but can't Program".
I have done some more research and found that the real situation is that
I have to remove the crystal before in-circuit programming will work.
Previously, with the crystal in, I was actually "reading", not
"verifying",
and the result of that read turned out to not quite match the desired
program. At first glance, using a pre-programmed dip processor plugged
into a circuit and then read via in-circuit programming techniques, the
program read back out appeared to be shifted from the correct program...
as if some bytes were omitted or some address increments occured twice,
or something else just slightly off like that.
Having poked around some more, I have discovered that if I simply remove
the crystal from the circuit, I can program, verify, and I believe
everything
else works too.
Unfortunately, I don't WANT to have to remove the crystal in order to
in-circuit program. This just increases the labor cost whenever I want
to do it, and I'm considering doing it in a quantity of thousands.
Please note that I am using a Pro Mate II with firmware version
03.21.01.
I have made an adapter plug to go from the programmers ZIF socket to a
header on my own board. I did a bit of research first to make sure this
concept worked, and it does by using merely the 5 documented in-circuit
programming pins (GND, VDD, MCLR, RB6, RB7). Note that this does NOT
include the two crystal pins, so my difficulties in-circuit programming
with the crystal inserted must be related to the crystal's being
connected
to the processor while trying to program the processor, as opposed to
being related to some direct interaction between the crystal and the
Pro Mate II programmer.
Does anyone have any suggestion as to why I find I must remove the
crystal?
Does anyone have any suggestions as to what I might do in order to be
able
to simply "plug and program", without removing the crystal or performing
any other
board mods before attempting in-circuit programming?
>
> I previously posted "Can In-Circuit verify PIC16C73A but can't Program".
>
> I have done some more research and found that the real situation is that
> I have to remove the crystal before in-circuit programming will work.
> Previously, with the crystal in, I was actually "reading", not
> "verifying",
> and the result of that read turned out to not quite match the desired
> program. At first glance, using a pre-programmed dip processor plugged
> into a circuit and then read via in-circuit programming techniques, the
> program read back out appeared to be shifted from the correct program...
> as if some bytes were omitted or some address increments occured twice,
> or something else just slightly off like that.
>
> Having poked around some more, I have discovered that if I simply remove
> the crystal from the circuit, I can program, verify, and I believe
> everything
> else works too.
>
> Unfortunately, I don't WANT to have to remove the crystal in order to
> in-circuit program. This just increases the labor cost whenever I want
> to do it, and I'm considering doing it in a quantity of thousands.
>
The pic uses one of the programing pins for the clock during programing
>
> Does anyone have any suggestion as to why I find I must remove the
> crystal?
>
> Does anyone have any suggestions as to what I might do in order to be
> able
> to simply "plug and program", without removing the crystal or performing
> any other
> board mods before attempting in-circuit programming?
Just a single dip switch in series with osc. in crystal lead
should do
Or a small (4K7) resistor in series with the osc.in and short the
crystal
side of the resistor to ground, with a link on the programing plug
if you want to make it fully automatic
Either method should stop the clock for programing
--
Peter Cousens
email: EraseMEpeter.....cousens.her.forthnet.gr
snailmail: Peter Cousens, karteros, Heraklion, Crete, 75100, Greece,
phone: + 3081 380534, +3081 324450 voice/fax
After Bill Gates announced to the world that he was Microsoft,
his wife was asked to comment. She said that as his wife, she
had been the first to notice this problem
> program read back out appeared to be shifted from the correct program...
> as if some bytes were omitted or some address increments occured twice,
> or something else just slightly off like that.
>
> Having poked around some more, I have discovered that if I simply remove
> the crystal from the circuit, I can program, verify, and I believe
This sounds like something I've heard but not <knock wood> seen. The
problem is likely that MCLR doesn't rise quickly enough, and the PIC runs
an instruction or two - which increments the PC, which does double duty as
the programming mode address register, of course. As I recall, there was
a report of this where the effect was so repeatable that the chips
appeared to program and verify correctly because the offset was always the
same, but of course the program didn't work since it was in the wrong
location.
You need either to make the programming hardware pull MCLR up within spec
- a very small number of microseconds - or to disable the oscillator
during programming, perhaps by shorting the input pin to ground?
What was (I think) a good idea has lead me into the realms of Pic
programming. Thing is, the last time I did any serious programming was
many years ago in the days of the 4000 series PET (6502 assembly). UK
available, whats the best book to start the learning process with ?
I've got the book form MPS "A Beginners Guide" but it does seem to leave
as many questions unanswered as it answers.
Next, the reason for this return to programming. What I have decided to
do is to use an LCD display, 2 * 16 or such like, to display a message
that would not exceed the number of characters on the display. However,
dependant upon an input line from another source it would display either
message A or B. I have seen several lumps of code that would be capable
of displaying one fixed message but not for changing over to a different
one.
Has anyone played with the LCD kit supplied by Magenta Electronics ?
Of course the real problem is that I am beginning to see the potential
for a number of projects that would benefit from the Pic type
technology. Hope my MD feels the same way :-)
Philip Martin wrote:
>
> Hi All,
>
> What was (I think) a good idea has lead me into the realms of Pic
> programming. Thing is, the last time I did any serious programming was
> many years ago in the days of the 4000 series PET (6502 assembly). UK
> available, whats the best book to start the learning process with ?
> I've got the book form MPS "A Beginners Guide" but it does seem to leave
> as many questions unanswered as it answers.
I tried to get a PET in 1978 but had to settle for a TRS-80 as it was
all they would ship me to OZ in the early days. Try http://www.dontronics.com/easy.html for the Easy PIC'n Beginners guide.
> Next, the reason for this return to programming. What I have decided to
> do is to use an LCD display, 2 * 16 or such like, to display a message
> that would not exceed the number of characters on the display. However,
> dependant upon an input line from another source it would display either
> message A or B. I have seen several lumps of code that would be capable
> of displaying one fixed message but not for changing over to a different
> one.
http://www.dontronics.com/sli.html will give you info on a ready made
display that will auto baud on 100bps to 125K bps. You mean to sense a
pin and display a different message depending on the result? Does the
text of the two messages change?
> Has anyone played with the LCD kit supplied by Magenta Electronics ?
>
> Of course the real problem is that I am beginning to see the potential
> for a number of projects that would benefit from the Pic type
> technology. Hope my MD feels the same way :-)
>
> Philip Martin email philipspamTakeThisOuTphilmart.demon.co.uk
> Royal Quays, North Shields
SLI, the serial LCD that auto detects baud rates from 100 to 125K bps.
SimmStick(tm) A PIC proto PCB the size of a 30 pin Simm Memory Module.
Covers all versions of the PIC16cxx family plus the Atmel AT89C2051.
I seem to be having a problem blowing some 16c84 chips. I've tried it
on 2 programmers Ive got, one from MPS and one from Magenta. Both have
been used with their own software.
Each time I try to programme the chip I get a verification error,
normally $0000: $3FFF : <> $2810.
I know the last bit means the expected code does not match, and having
used the windows software with the Magenta s/w the memory map of the
chip shows the section $3FFF where the problem seems to occur.
Has anyone got any idea whats either gone wrong or what I'm doing wrong.
At 07:33 PM 15/2/97 +0000, you wrote:
>HI All,
>
>I seem to be having a problem blowing some 16c84 chips. I've tried it
>on 2 programmers Ive got, one from MPS and one from Magenta. Both have
>been used with their own software.
>
>Each time I try to programme the chip I get a verification error,
>normally $0000: $3FFF : <> $2810.
this indicates that
at address 0000 readbackis 3FFF instead of required 2810
so your programmer is not working or the PIC is faulty,
same results would you get with a working programmer and
no chip inserted.
you must check the usual, hardware cables power supply, etc.
this error report does not indicate whats wrong, just
simply 'no programming at all'
Hi
You are two right about the beginners guide. I learnt on the engineering
education scheme with school at a residential stay at napier university in
Edinburgh. The two of us learning were given some simple examples and
learnt looking at the comments. I have used magenta but not with their lcd
stuff. If you read everyday practical electronics then they are doing some
pic - lcd stuff at the moment.
>Hi All,
>
>What was (I think) a good idea has lead me into the realms of Pic
>programming. Thing is, the last time I did any serious programming was
>many years ago in the days of the 4000 series PET (6502 assembly). UK
>available, whats the best book to start the learning process with ?
>I've got the book form MPS "A Beginners Guide" but it does seem to leave
>as many questions unanswered as it answers.
>
>Next, the reason for this return to programming. What I have decided to
>do is to use an LCD display, 2 * 16 or such like, to display a message
>that would not exceed the number of characters on the display. However,
>dependant upon an input line from another source it would display either
>message A or B. I have seen several lumps of code that would be capable
>of displaying one fixed message but not for changing over to a different
>one.
>
>Has anyone played with the LCD kit supplied by Magenta Electronics ?
>
>Of course the real problem is that I am beginning to see the potential
>for a number of projects that would benefit from the Pic type
>technology. Hope my MD feels the same way :-)
>
>TIA,
>
>--
>Philip Martin email TakeThisOuTphilipspamphilmart.demon.co.uk
>Royal Quays, North Shields
>
------------------------------------------------------------------
If you can read this, it is the end of the message!
My web pages are at http://web.ukonline.co.uk/members/tim.kerby/
My PIC site is at web.ukonline.co.uk/members/tim.kerby/pic/
It needs your projects!
------------------------------------------------------------------
The problem is that easiest PICs to get was 16F84 and I made COM84 to
program them. Programming don't write anything to the chips, but reading
seems to be OK. (code: 3fff 3fff.... eeprom: ff ff ff ff, I guess that
these are right for new PIC) Is the COM84 unable to program them or is my
COM84 just buggy?
At 06:01 PM 25/2/97 +0200, you wrote:
>Hi!
>
>Is it possible to program PIC16F84 chips with COM84-programmer and PIP
>software(http://sistudio.com/sistudio/download.html)? PIP 1.14 claims that
>it can program 16F84.
>
>The problem is that easiest PICs to get was 16F84 and I made COM84 to
>program them. Programming don't write anything to the chips, but reading
>seems to be OK. (code: 3fff 3fff.... eeprom: ff ff ff ff, I guess that
>these are right for new PIC) Is the COM84 unable to program them or is my
>COM84 just buggy?
no the driver is same, but you should select C84 as device I believe
let me know if it still does not work.
thee 3FFF FF reading does not indicate OK, it just indicates no data
it may be balnk chip or no chip.
Be carefull though. V1.14 has some bugs. One is that the configuration bits
are not picked up from your hex file correctly and the other is you cannot
compile in MPLAB (Under windows) if you have PIP02 V1.14 open in another
window. PIP02 doesn't close the hex file so MPLAB cannot access it. This
wasn't the case with the older version.
Your problem must be your programmer.
Good luck
Dennis
____________________________________________________
FROST - Electronic Design, Manufacture & Consulting.
Dennis Frost
Tel: +27 331 965125
Cel: +83 2275216
Email: KILLspamdennis.frostKILLspamspamBeGonepixie.co.za
Pietermaritzburg, South Africa
Products: Medical Motivational equipment
Timers for food processing
Random number generator
Temperature controllers
____________________________________________________
PS Anyone looking for someone in the hardware/software development fields,
I am available. I intend leaving South Africa for the West coast of the US
early this year.
----------
> From: Tapani T. Salmi <spamBeGonetaiskaKILLspamTUUG.ORG>
> To: PICLIST@spam@KILLspamMITVMA.MIT.EDU
> Subject: PIC16F84 COM84 programming?
> Date: 25 February 1997 06:01
>
> Hi!
>
> Is it possible to program PIC16F84 chips with COM84-programmer and PIP
> software(http://sistudio.com/sistudio/download.html)? PIP 1.14 claims
that
> it can program 16F84.
>
> The problem is that easiest PICs to get was 16F84 and I made COM84 to
> program them. Programming don't write anything to the chips, but reading
> seems to be OK. (code: 3fff 3fff.... eeprom: ff ff ff ff, I guess that
> these are right for new PIC) Is the COM84 unable to program them or is my
> COM84 just buggy?
>
> /Taiska
> From: Antti Lukats <EraseMEanttiRemoveME@spam@SISTUDIO.COM>
>
> no the driver is same, but you should select C84 as device I believe
> let me know if it still does not work.
>
> thee 3FFF FF reading does not indicate OK, it just indicates no data
> it may be balnk chip or no chip.
>
> antti
>
>
> -- Silicon Studio Ltd.
> -- http://www.sistudio.com
I use a PIC16C84 , a 2 x 20 character display (LM032XMBL with LSI HD44780
Controller) for my circuit with the JDM84 PIC programmer:
<http://www.gbar.dtu.dk/~c888600/newpic.htm> with in Circuit Programming.
The PINAPI Driver of my programmer gives "Programmer not found at COM1" when i
use it with a Display data bus pin connected to RB7 = DATA for programming.
Without this connection, but with all other: no problem! (Connect: RB1: RS, RB2:
E,
RB3: R/W, RB4: DB4, RB5: DB5, RB6: DB6, RB7: DB7. The RB4 to RB7 are in
addition to momentary switches connected, which are usually open circuit.)
Does someone know WHY? Has someone got this problen, too and solved it?
And what i can DO easily (resistor?) to make this work? Has the display
INTERNAL pull ups or pull downs?
Is this triple usage dangerous for the display? (if no data transfer happens, E
= Low
then RB4 to RB7 will be used with PIC internal pull ups as function keys which
are pulled down at keypress with Interrupt on change).
All sorts of suggestions are much appreciated
Bernd
Sorry if this is a repost but I got an 'Undeliverable' message with the
first one.
I am using the same combination of hardware & software.
I choose 16F84 as the device and it programs perfectly every time.
Be carefull though. V1.14 has some bugs. One is that the configuration bits
are not picked up from your hex file correctly and the other is you cannot
compile in MPLAB (Under windows) if you have PIP02 V1.14 open in another
window. PIP02 doesn't close the hex file so MPLAB cannot access it. This
wasn't the case with the older version.
Your problem must be your programmer.
Good luck
Dennis
____________________________________________________
FROST - Electronic Design, Manufacture & Consulting.
Dennis Frost
Tel: +27 331 965125
Cel: +83 2275216
Email: RemoveMEdennis.frostspamEraseMEpixie.co.za
Pietermaritzburg, South Africa
Products: Medical Motivational equipment
Timers for food processing
Random number generator
Temperature controllers
____________________________________________________
PS Anyone looking for someone in the hardware/software development fields,
I am available. I intend leaving South Africa for the West coast of the US
early this year.
----------
> From: Tapani T. Salmi <STOPspamtaiska.....TUUG.ORG>
> To: spamBeGonePICLISTRemoveMERemoveMEMITVMA.MIT.EDU
> Subject: PIC16F84 COM84 programming?
> Date: 25 February 1997 06:01
>
> Hi!
>
> Is it possible to program PIC16F84 chips with COM84-programmer and PIP
> software(http://sistudio.com/sistudio/download.html)? PIP 1.14 claims
that
> it can program 16F84.
>
> The problem is that easiest PICs to get was 16F84 and I made COM84 to
> program them. Programming don't write anything to the chips, but reading
> seems to be OK. (code: 3fff 3fff.... eeprom: ff ff ff ff, I guess that
> these are right for new PIC) Is the COM84 unable to program them or is my
> COM84 just buggy?
>
> /Taiska
Does someone know the common problems & solutions for the COM84
programmer? My attempts to program PIC16F84 with COM84 has been
very unsuccesful.
I build my COM84 with instructions found from http://hobbes.king.ac.uk/matt/pic/prog.html. Is that circuit ok? When I
write something with pip02 program (I use com84.exe driver, does it work
with 16F84) I get programming error. Reading the chip always tells me 3f
ff stuff.
Even that the circuit is very simple, I tried it again: I asked my friend
to make the COM84, we used a fresh PIC and his computer. Nada, same
symptoms.
But I think that there is something strange going on, because while
programming, my multimeter shows only about 5-6V as the voltage of MCLR.
As far as I know, it can't be right? It should be higher? Is the problem
too low voltage, possibly caused by lame serial ports? (but if it's so,
lame RS ports are very common; I have tried two different mother board
integrated and one separate adapter card) Or is MCLR switched on/off
during write procedure?
At 01:37 AM 26/2/97 +0200, you wrote:
>Does someone know the common problems & solutions for the COM84
>programmer? My attempts to program PIC16F84 with COM84 has been
>very unsuccesful.
>
>I build my COM84 with instructions found from
>http://hobbes.king.ac.uk/matt/pic/prog.html. Is that circuit ok? When I
>write something with pip02 program (I use com84.exe driver, does it work
>with 16F84) I get programming error. Reading the chip always tells me 3f
>ff stuff.
>
>Even that the circuit is very simple, I tried it again: I asked my friend
>to make the COM84, we used a fresh PIC and his computer. Nada, same
>symptoms.
>
>But I think that there is something strange going on, because while
>programming, my multimeter shows only about 5-6V as the voltage of MCLR.
this is the problem, unless the voltage is >= 10.5 the programmer will not
program or read any chips.
I suggest you make a simple LPT programmer. PIP02 now supports NOPPP
almost simpliest LPT programmer.
>As far as I know, it can't be right? It should be higher? Is the problem
>too low voltage, possibly caused by lame serial ports? (but if it's so,
>lame RS ports are very common; I have tried two different mother board
>integrated and one separate adapter card) Or is MCLR switched on/off
>during write procedure?
>
>Please, can you tell me what is going wrong?
maybe you use 7805 on your programmer? it takes too much current
78L05 or zener can be used.
antti
The COM84 hardware or whatever a-like is not our design, we only wrote
a driver for our programming software.
> >But I think that there is something strange going on, because while
> >programming, my multimeter shows only about 5-6V as the voltage of MCLR.
>
> this is the problem, unless the voltage is >= 10.5 the programmer will not
> program or read any chips.
Yeah, so I guessed it. Thanks.
> maybe you use 7805 on your programmer? it takes too much current
> 78L05 or zener can be used.
Regulator says LM78L05ACZ, so it is ok? Anyway, LPT programmers sounds
good idea. Maybe I can get it working...
Here is a diagram of the changes I made to the Com84 programmer. I have
been using it for a year on a 120 Meg Pentium without problems. (If you
can't make out the circuit then cut it out & paste it into notebook)
I like this programmer because I usually have other things plugged into my
parallel ports.
Don't give up hope. I started in Pics trying to use a Parallel programmer
and had all sorts of problems. That's why I now use a serial programmer.
How can you get simpler than 3 resistors?
PIP02 works very well but be careful. V1.14 has some bugs. One is that the
configuration bits
are not picked up from your hex file correctly and the other is you cannot
compile in MPLAB (Under windows) if you have PIP02 V1.14 open in another
window. PIP02 doesn't close the hex file so MPLAB cannot access it. This
wasn't the case with the older version.
> From: Tapani T. Salmi <@spam@taiskaspamBeGoneTUUG.ORG>
> To: spam_OUTPICLISTspamMITVMA.MIT.EDU
> Subject: PIC16F84 COM84 programming again...
> Date: 26 February 1997 01:37
>
> Does someone know the common problems & solutions for the COM84
> programmer? My attempts to program PIC16F84 with COM84 has been
> very unsuccesful.
>
> I build my COM84 with instructions found from
> http://hobbes.king.ac.uk/matt/pic/prog.html. Is that circuit ok? When I
> write something with pip02 program (I use com84.exe driver, does it work
> with 16F84) I get programming error. Reading the chip always tells me 3f
> ff stuff.
>
> Even that the circuit is very simple, I tried it again: I asked my friend
> to make the COM84, we used a fresh PIC and his computer. Nada, same
> symptoms.
>
> But I think that there is something strange going on, because while
> programming, my multimeter shows only about 5-6V as the voltage of MCLR.
> As far as I know, it can't be right? It should be higher? Is the problem
> too low voltage, possibly caused by lame serial ports? (but if it's so,
> lame RS ports are very common; I have tried two different mother board
> integrated and one separate adapter card) Or is MCLR switched on/off
> during write procedure?
>
> Please, can you tell me what is going wrong?
>
> /Taiska (novadays known as Desperado :(
>Does someone know the common problems & solutions for the COM84
>programmer? My attempts to program PIC16F84 with COM84 has been
>very unsuccesful.
>
>I build my COM84 with instructions found from
>http://hobbes.king.ac.uk/matt/pic/prog.html. Is that circuit ok? When I
>write something with pip02 program (I use com84.exe driver, does it work
>with 16F84) I get programming error. Reading the chip always tells me 3f
>ff stuff.
>
>Even that the circuit is very simple, I tried it again: I asked my friend
>to make the COM84, we used a fresh PIC and his computer. Nada, same
>symptoms.
>
>But I think that there is something strange going on, because while
>programming, my multimeter shows only about 5-6V as the voltage of MCLR.
>As far as I know, it can't be right? It should be higher? Is the problem
>too low voltage, possibly caused by lame serial ports? (but if it's so,
>lame RS ports are very common; I have tried two different mother board
>integrated and one separate adapter card) Or is MCLR switched on/off
>during write procedure?
Serial ports do seem to vary a lot. I have the same problem with my new
P133+ system with the I/O on the M/B, whereas my old 486 system with a
simple I/O card works fine, as does my 486 system at work. I'd try
adding the 555 voltage doubler circuit. I'll be trying this myself.
i've just started programming the pic - i've got the led's lit up
etc etc now moving on to bigger & better things..
a couple of questions regarding common practice :
- i started off assigning my own registers just using
CTR EQU 20h
(for example)
what i meant was i wanted to use address 20h
now is it usual to use the 'DS' command to do this
kind of thing? i.e.
ORG 20h
CTR DS 1
ORG 21h
CTR2 DS 1
i'm kinda unsure about the direct/indirect addressing..
- say i want a small buffer (i.e. maybe 12/16 bits) - i do this
ORG 30h
BUFFER DS 16
now how do i get at this buffer? i know i can do BUFFER+<offset>
but i want to use 'a variable' for the offset, increment it,
etc etc as i would in a high level language...
i thought of having another memory location holding a 'pointer'
to my buffer and then incrementing/decrementing this - but
trying to implement this seems kinda unnecessarily complex..
any tips? i guess i'm still thinking high level language...
thanks
nishant
ISE III BEng
Incremental Sanity Erosion at Imperial College
There is a register called the FSR (I think that stands for File Select
Register). You load the address of the start of the buffer into this
register. Then you read register 0 (I think it is called INDF) this
register will now hold the value of the register pointed to by the FSR.
Thus you would do something like this:
movlw Buffer ;this places the address of you 'Buffer' into w
movwf FSR ;place the address into FSR
Now you can work with the buffer:
movfw INDF ;This will put the value at Buffer into w
incf FSR ;Point to buffer+1
clrf INDF ;clear the data at Buffer+1
You can increment, decrement, add to & subtract from the FSR like with any
other register
I often use this method when I have a piece of code that performs a similar
function of a lot of registers.
Here is an example of how I define my variables:
CBLOCK 0ch
SaveW ;01 holds W register durring interrupt
SaveS ;02 holds Status register durring interrupt
SaveFSR ;03 Holds copy of FSR durring interrupt
T1 ;04 Timer values
T2 ;05
T3 ;06
T4 ;07
ENDC
I like using this method because if I want to add a variable say between
SaveS and SaveFSR (it makes more visual sense for whatever reason) the I
don't have to renumber all the variables. The compiler will renumber
consecutively them from 0ch until it reaches ENDC.
As for setting up the buffer, I have not had to do that so I couldn't tell
you for sure but I think you are right.
Cheers
Dennis
____________________________________________________
FROST - Electronic Design, Manufacture & Consulting.
Dennis Frost
Tel: +27 331 965125
Cel: +83 2275216
Email: spamBeGonedennis.frostpixie.co.za
Pietermaritzburg, South Africa
Products: Medical Motivational equipment
Timers for food processing
Random number generator
Temperature controllers
____________________________________________________
PS Anyone looking for someone in the hardware/software development fields,
I am available. I intend leaving South Africa for the West coast of the US
early this year.
----------
> From: Nishant Deshpande <EraseMEnd4EraseMEDOC.IC.AC.UK>
> To: spamBeGonePICLISTspam_OUT.....MITVMA.MIT.EDU
> Subject: programming question
> Date: 02 March 1997 09:57
>
> hi all,
>
> i've just started programming the pic - i've got the led's lit up
> etc etc now moving on to bigger & better things..
>
> a couple of questions regarding common practice :
>
> - i started off assigning my own registers just using
> CTR EQU 20h
> (for example)
> what i meant was i wanted to use address 20h
> now is it usual to use the 'DS' command to do this
> kind of thing? i.e.
> ORG 20h
> CTR DS 1
> ORG 21h
> CTR2 DS 1
>
> i'm kinda unsure about the direct/indirect addressing..
>
> - say i want a small buffer (i.e. maybe 12/16 bits) - i do this
> ORG 30h
> BUFFER DS 16
>
> now how do i get at this buffer? i know i can do BUFFER+<offset>
> but i want to use 'a variable' for the offset, increment it,
> etc etc as i would in a high level language...
>
> i thought of having another memory location holding a 'pointer'
> to my buffer and then incrementing/decrementing this - but
> trying to implement this seems kinda unnecessarily complex..
>
> any tips? i guess i'm still thinking high level language...
>
> thanks
>
> nishant
> ISE III BEng
> Incremental Sanity Erosion at Imperial College
>I often use this method when I have a piece of code that performs a similar
>function of a lot of registers.
>
>Here is an example of how I define my variables:
>
> CBLOCK 0ch
> SaveW ;01 holds W register durring interrupt
> SaveS ;02 holds Status register durring interrupt
> SaveFSR ;03 Holds copy of FSR durring interrupt
> T1 ;04 Timer values
> T2 ;05
> T3 ;06
> T4 ;07
> ENDC
Could this be analogous to setting up an object oriented procedure ?
Rgds
Mike
Some say there is no magic but, all things begin with thought then it becomes
academic, then some poor slob works out a practical way to implement all that
theory, this is called Engineering - for most people another form of magic.
Massen
>
> Hi Nishant
>
> There is a register called the FSR (I think that stands for File Select
> Register). You load the address of the start of the buffer into this
> register. Then you read register 0 (I think it is called INDF) this
> register will now hold the value of the register pointed to by the FSR.
>
> Thus you would do something like this:
>
> movlw Buffer ;this places the address of you 'Buffer' into w
> movwf FSR ;place the address into FSR
>
> Now you can work with the buffer:
>
> movfw INDF ;This will put the value at Buffer into w
>
> incf FSR ;Point to buffer+1
>
> clrf INDF ;clear the data at Buffer+1
>
> You can increment, decrement, add to & subtract from the FSR like with any
> other register
>
> I often use this method when I have a piece of code that performs a similar
> function of a lot of registers.
>
> Here is an example of how I define my variables:
>
> CBLOCK 0ch
> SaveW ;01 holds W register durring interrupt
> SaveS ;02 holds Status register durring interrupt
> SaveFSR ;03 Holds copy of FSR durring interrupt
> T1 ;04 Timer values
> T2 ;05
> T3 ;06
> T4 ;07
> ENDC
>
> I like using this method because if I want to add a variable say between
> SaveS and SaveFSR (it makes more visual sense for whatever reason) the I
> don't have to renumber all the variables. The compiler will renumber
> consecutively them from 0ch until it reaches ENDC.
>
> As for setting up the buffer, I have not had to do that so I couldn't tell
> you for sure but I think you are right.
>
> Cheers
> Dennis
> ____________________________________________________
> FROST - Electronic Design, Manufacture & Consulting.
> Dennis Frost
> Tel: +27 331 965125
> Cel: +83 2275216
> Email: spamdennis.frostpixie.co.za
> Pietermaritzburg, South Africa
> Products: Medical Motivational equipment
> Timers for food processing
> Random number generator
> Temperature controllers
> ____________________________________________________
>
> PS Anyone looking for someone in the hardware/software development fields,
> I am available. I intend leaving South Africa for the West coast of the US
> early this year.
> ----------
>
> > From: Nishant Deshpande <RemoveMEnd4KILLspamKILLspamDOC.IC.AC.UK>
> > To: EraseMEPICLISTspamBeGonespamMITVMA.MIT.EDU
> > Subject: programming question
> > Date: 02 March 1997 09:57
> >
> > hi all,
> >
> > i've just started programming the pic - i've got the led's lit up
> > etc etc now moving on to bigger & better things..
> >
> > a couple of questions regarding common practice :
> >
> > - i started off assigning my own registers just using
> > CTR EQU 20h
> > (for example)
> > what i meant was i wanted to use address 20h
> > now is it usual to use the 'DS' command to do this
> > kind of thing? i.e.
> > ORG 20h
> > CTR DS 1
> > ORG 21h
> > CTR2 DS 1
> >
> > i'm kinda unsure about the direct/indirect addressing..
> >
> > - say i want a small buffer (i.e. maybe 12/16 bits) - i do this
> > ORG 30h
> > BUFFER DS 16
> >
> > now how do i get at this buffer? i know i can do BUFFER+<offset>
> > but i want to use 'a variable' for the offset, increment it,
> > etc etc as i would in a high level language...
> >
> > i thought of having another memory location holding a 'pointer'
> > to my buffer and then incrementing/decrementing this - but
> > trying to implement this seems kinda unnecessarily complex..
> >
> > any tips? i guess i'm still thinking high level language...
> >
> > thanks
> >
> > nishant
> > ISE III BEng
> > Incremental Sanity Erosion at Imperial College
You don't need to put all those ORGs there, as the assembler tracks what
you've used.
Simply do this:
org 20h
CTR ds 1
CTR2 ds 1
Then you can insert CTR1 between them:
org 20h
CTR ds 1
CTR1 ds 3
CTR2 ds 1
and it will know that CTR1 is 3 bytes long, moving CTR2 down.
To access the three bytes of CTR1, you can do the following
bcf C
rlf CTR1,F
rlf CTR1+1,F
rlf CTR1+2,F
Which is the same as multiplying CTR1 = CTR1 * 2.
To access it using FSR is correct, as detailed in another reply.
Andy
==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
Hardware & Software for Industry & R/C Hobbies
"Go fast, turn right, and keep the wet side down!"
==================================================================
>
> At 07:57 PM 3/2/97 +0000, you wrote:
> > ORG 20h
> > CTR DS 1
> > ORG 21h
> > CTR2 DS 1
>
> Nishant,
>
> You don't need to put all those ORGs there, as the assembler tracks what
> you've used.
>
> Simply do this:
>
> org 20h
> CTR ds 1
> CTR2 ds 1
>
> Then you can insert CTR1 between them:
>
> org 20h
> CTR ds 1
> CTR1 ds 3
> CTR2 ds 1
>
> and it will know that CTR1 is 3 bytes long, moving CTR2 down.
>
> To access the three bytes of CTR1, you can do the following
>
> bcf C
> rlf CTR1,F
> rlf CTR1+1,F
> rlf CTR1+2,F
>
> Which is the same as multiplying CTR1 = CTR1 * 2.
>
> To access it using FSR is correct, as detailed in another reply.
>
> Andy
> ==================================================================
> Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
> Hardware & Software for Industry & R/C Hobbies
> "Go fast, turn right, and keep the wet side down!"
> ==================================================================
>
> Does someone know the common problems & solutions for the COM84
> programmer? My attempts to program PIC16F84 with COM84 has been
> very unsuccesful.
>
> I build my COM84 with instructions found from
> http://hobbes.king.ac.uk/matt/pic/prog.html. Is that circuit ok? When I
> write something with pip02 program (I use com84.exe driver, does it work
> with 16F84) I get programming error. Reading the chip always tells me 3f
> ff stuff.
>
> Even that the circuit is very simple, I tried it again: I asked my friend
> to make the COM84, we used a fresh PIC and his computer. Nada, same
> symptoms.
>
> But I think that there is something strange going on, because while
> programming, my multimeter shows only about 5-6V as the voltage of MCLR.
> As far as I know, it can't be right? It should be higher? Is the problem
> too low voltage, possibly caused by lame serial ports? (but if it's so,
> lame RS ports are very common; I have tried two different mother board
> integrated and one separate adapter card) Or is MCLR switched on/off
> during write procedure?
>
> Please, can you tell me what is going wrong?
>
> /Taiska (novadays known as Desperado :(
Try putting 18pf caps on RB6 and RB7 and/or clock in (LPT pin 3)
and data (LPT pin 2)
I had the same problem and the caps fixed it
--
Peter Cousens
email: KILLspampetercousens.her.forthnet.gr
snailmail: Peter Cousens, karteros, Heraklion, Crete, 75100, Greece,
phone: + 3081 380534, +3081 324450 voice/fax
After Bill Gates announced to the world that he was Microsoft,
his wife was asked to comment. She said that as his wife, she
had been the first to notice this problem
Can anyone tell me the requirements for programming the C54 in circuit,
what do you need to do with the MCLR pin. I can't find any data in the
microchip data book. I take it that the C54 can be programmed serially
as it can be programmed with the D. Tait type of programmer.
Regards
Ken.
+-----------------------------+----------------------------------+
| ken hewitt | Email kenspam_OUTspamwelwyn.demon.co.uk |
+-----------------------------+----------------------------------+
At 07:42 PM 11/3/97 +0000, you wrote:
>Can anyone tell me the requirements for programming the C54 in circuit,
>what do you need to do with the MCLR pin. I can't find any data in the
>microchip data book. I take it that the C54 can be programmed serially
>as it can be programmed with the D. Tait type of programmer.
nop, you need to use 16C554 if you want to use ICP.
MCLR must have circuitry that allows to be pulled up to +12V,
In programming same applies as for 16C84
Not sure if David's original software supports 16C55X programming
our PIP02 does support, and supports amongst other programmers
David Tait's programmer too
I'd like to program 16C73A devices with my PIC84PGM programmer (Don
McKenzie). I am planning on building up a 28-pin ZIF socket to connect to
the 10-pin header that is included on the PIC84PGM programmer. If I
understand correctly, I'll need to wire up the RB7, RB6, VCC, GND, and MCLR
pins from the 10-pin header to the appropriate positions on the 28-pin ZIF
socket.
I'd like to know what I should use to program the part. I've been using the
PICPROG programming software (Nigel Goodwin) with success to program 16C84
parts, but I assume this software won't work for EPROM parts since the
timing for programming will be different.
I looked at the PGM16CXX software (Ken Segler) and it looks like it will
program 16c73 parts, but I'm worried about the additional code protect bits
in the 16c73a part and wondering what this programmer will do with them
since it doesn't list the 16c73a part specifically.
>
> Can anyone tell me the requirements for programming the C54 in circuit,
> what do you need to do with the MCLR pin. I can't find any data in the
> microchip data book. I take it that the C54 can be programmed serially
> as it can be programmed with the D. Tait type of programmer.
No, nope, and not a chance.
The C54 has parallel programming only, cannot be programmed byt the D. Tait
type circuit and has no provisions for in circuit programming.
Think about a C55X or C62X type chip. Same footprint but is much closer to
a C84 than a C5X in terms of these issues.
>
> I'd like to program 16C73A devices with my PIC84PGM programmer (Don
> McKenzie). I am planning on building up a 28-pin ZIF socket to connect to
> the 10-pin header that is included on the PIC84PGM programmer. If I
> understand correctly, I'll need to wire up the RB7, RB6, VCC, GND, and MCLR
> pins from the 10-pin header to the appropriate positions on the 28-pin ZIF
> socket.
>
> I'd like to know what I should use to program the part. I've been using the
> PICPROG programming software (Nigel Goodwin) with success to program 16C84
> parts, but I assume this software won't work for EPROM parts since the
> timing for programming will be different.
>
> I looked at the PGM16CXX software (Ken Segler) and it looks like it will
> program 16c73 parts, but I'm worried about the additional code protect bits
> in the 16c73a part and wondering what this programmer will do with them
> since it doesn't list the 16c73a part specifically.
>
> Thanks,
> --Anil
No Nigel Goodwin's software will only do 84's, but very nicely.
I have spoken to Nigel recently about catering for the F84, however I
think all he really needs is a device to try.
Ken Segler's software last count, didn't cater for the two code protect
bits. I sent him Email about this a long time ago, but haven't heard
anything back. Still with us Ken?
Octavio Nogueira (TATO Computers) last time I looked, didn't support it
either, however I think he has some 'A' parts support. Perhaps he will
reply to this and update us.
Antti Lukats (SiStudio) doesn't support it yet in his PIP02 driver. Rest
assured I have prompted him about this and the F84 support.
I know that the 'A' parts are gradually replacing the old versions. I
can no longer get non-'A' PIC16C74/JW parts.
I wonder if the same thing will happen with the C84.
Sorry I couldn't give you anything positive on the Davit Tait type
programmer software upgrades. Perhaps someone else can. Maybe even David
knows. :)
As new devices come out, you can rest assured the saga will continue. :)
At: http://dontronics.com/hints.html
you will find the wiring of the header to the 28 pin socket.
Also the combination of my DT.001 board, (updated PIC84PGM) and a
PIC.003 SimmStick board will do this job for you.
SLI, the serial LCD that auto detects baud rates from 100 to 125K bps.
SimmStick(tm) A PIC proto PCB the size of a 30 pin Simm Memory Module.
Covers all versions of the PIC16cxx family plus the Atmel AT89C2051.
> Can anyone tell me the requirements for programming the C54 in circuit,
> what do you need to do with the MCLR pin. I can't find any data in the
> microchip data book. I take it that the C54 can be programmed serially
> as it can be programmed with the D. Tait type of programmer.
The 16C54 requires that you control--literally--all of its pins during
programming (well, Vss remains grounded, but...) One person has posted
on the list that they in fact designed a circuit which would allow ISP'ing
the 54 even under those conditions, but I doubt such a thing would usually
be practical.
To program the '54, you need to power the thing up and take /MClr very
quickly from zero to VPP (about 13 volts I think). After that each pulse
of the RTCC input will either output the contents of address zero onto
pins RA3-RA0:RB7-RB0 or else try to "burn" the contents of those pins into
address zero. You should alternate between the read and write until add-
ress zero reads correctly. After that, you should hit the /OSCin pin to
advance to the next memory location; RTCC will toggle between reading and
writing that. Continue in this fashion until you have done the entire
chip.
> The 16C54 requires that you control--literally--all of its pins
> during programming (well, Vss remains grounded, but...) One person
> has posted on the list that they in fact designed a circuit which
> would allow ISP'ing the 54 even under those conditions,....
That was me.
> .... but I doubt such a thing would usually be practical.
You're correct... The method I came up with isn't suited for
general-purpose programming at all. If in-circuit programming
is required, I'd recommend staying away from the 16C5x parts.
-Andy
=== Andrew Warren - .....fastfwd@spam@ix.netcom.com
=== Fast Forward Engineering - Vista, California
===
=== Custodian of the PICLIST Fund -- For more info, see:
=== www.geocities.com/SiliconValley/2499/fund.html
> Can anyone tell me the requirements for programming the C54 in circuit,
> what do you need to do with the MCLR pin. I can't find any data in the
> microchip data book. I take it that the C54 can be programmed serially
> as it can be programmed with the D. Tait type of programmer.
However it's not intended to program the chip in-circuit as the C54
cannot be programmed in serial mode. That doesn't mean you couldn't
come up with a circuit to do that (I'm sure Andrew Warren said he once
worked with such a setup) but I doubt if that's the best way forward
nowadays with such a gamut of alternative PICs available.
I am a beginner in programming pics. I do have an electronics
background. I was going to build Octavio's ProPic programmer, and put
it off. I have now decided to build it.
I want to start off slow and inexpensive, being a student. What I
want to know, is where can I get the software to create a hex file in
order to program the pic16c84?
I have a copy of P16PRO that was mentioned a while ago, I have check
this out and the circuit that was included in the zip file is a PC
printer port programmer, with only 5 connections to the PIC, Vss, Vdd,
RB6, RB7 and MCLR.
I have run the programming software that was with it and looked at the
device list it includes the 54 and 52, I have not tried it out yet as I
have not got around to building the hardware, should I bother or not.
Ken.
+-----------------------------+----------------------------------+
| ken hewitt | Email @spam@kenwelwyn.demon.co.uk |
+-----------------------------+----------------------------------+
At 01:04 PM 3/12/97 -0600, you wrote:
>Hello,
>
> I am a beginner in programming pics. I do have an electronics
>background. I was going to build Octavio's ProPic programmer, and put
>it off. I have now decided to build it.
>
>
> I want to start off slow and inexpensive, being a student. What I
>want to know, is where can I get the software to create a hex file in
>order to program the pic16c84?
>
>
>Brian
>
Hi!
Try this site: http://hobbes.king.ac.uk/matt/pic/
There is a very cheap and good programmer to the c84. Hardware and software.
I have used it many times and it works.
Johan joha1359RemoveMEhem1.passag
en.se
>
> Octavio Nogueira (TATO Computers) last time I looked, didn't support it
> either, however I think he has some 'A' parts support. Perhaps he will
> reply to this and update us.
>
Hi,
The ProPic programmer V3.2 can program the following PICs:
Octavio
========================================================
Octavio Nogueira
e-mail: spamnogueiramandic.com.br
homepage: www.geocities.com/SiliconValley/Pines/6902/index.html
voice/fax: +55 11 240-6474
"ProPic" The first Production PIC Programmer running in
Windows and under US$ 20.00.
========================================================
I'm trying to program a 16C84 with a low cost PARALLAX programmer
and have some trouble:
1/ I'm obliged to program 3 or 5 times the chip to have
the oscillator programmed for CRYSTAL and not RC
2/ I have the programmed chip (SMD), then sold it onto the board.
I connect RB6,RB7, MCLR and VCC to the programmer in order to modify
the program. Problem is as the chip is programmed for Crystal oscillator
the programmer as many difficulties to read and program it.
Does anybody know if it's necessary the oscillator section run properly
to re-program a 16C84 ?
Does somebody have the same problem with a parallax programmer ?
In a message dated 97-03-17 11:40:53 EST, you write:
<<
Hi all,
I'm trying to program a 16C84 with a low cost PARALLAX programmer
and have some trouble:
1/ I'm obliged to program 3 or 5 times the chip to have
the oscillator programmed for CRYSTAL and not RC
2/ I have the programmed chip (SMD), then sold it onto the board.
I connect RB6,RB7, MCLR and VCC to the programmer in order to modify
the program. Problem is as the chip is programmed for Crystal oscillator
the programmer as many difficulties to read and program it.
Does anybody know if it's necessary the oscillator section run properly
to re-program a 16C84 ?
Does somebody have the same problem with a parallax programmer ?
Regards,
Philippe.
>>
Philippe,
The system my company makes has 14 PIC16F84s on a single control board. They
are all SMD chips and are all programmed through an in-circuit programming
connector. I use the Parralax programmer to accomplish this. I have
experienced the same type of problem that you describe here. Our problem was
caused by the Ocsillator (We use one 10mhz oscilator to drive all 14 pics).
The Microchip spec. say that there can be no oscillation on the crystal
inputs durring the first three transitions of the serial clock used for
programming. We now put the oscillator in a socket and insert it after
programming is complete. This seems to solve all of our little quirky
problems.
Hope this helps.
Dave Duley
V.P. DreiTek Inc.
At 17:20 17/03/97 -0800, you wrote:
>I'm trying to program a 16C84 with a low cost PARALLAX programmer
>and have some trouble:
> 1/ I'm obliged to program 3 or 5 times the chip to have
>the oscillator programmed for CRYSTAL and not RC
> 2/ I have the programmed chip (SMD), then sold it onto the board.
>I connect RB6,RB7, MCLR and VCC to the programmer in order to modify
>the program. Problem is as the chip is programmed for Crystal oscillator
>the programmer as many difficulties to read and program it.
>
>Does anybody know if it's necessary the oscillator section run properly
>to re-program a 16C84 ?
>Does somebody have the same problem with a parallax programmer ?
I've tried the in-circuit programming with a DIY "LUDIPIPO" programmer,
and I've found that the extra power consummed by the PIC while it is in the
circuit (with the oscilator running) make it impossible to re-program. May
be the Parallax Programmer works in a simmilar way (I dont'k know), then
you need a programmer with its own power supply (just what I'm trying to
build now ).
good lucky.
-----------------------------------------------------------------------
| Adolfo Cobo Garcia - UNIVERSIDAD DE CANTABRIA |
| E.T.S.I.I. y Telecomunicacion, Grupo de Ingenieria Fotonica |
| Avda. Los Castros s/n E-39005 Santander SPAIN |
| Tfno. +34-42-201539 Fax +34-42-201873 Email: spam_OUTacobo@spam@RemoveMEteisa.unican.es |
-----------------------------------------------------------------------
Hi all, I recently purchased a J&M Microtek PIC programmer but I am
having some problems getting my assembled code to work in my pic
project.
First, I am using the baseline pic16c54 rc/p chip for my project. After
I load my assembled data (*.hex) into the programming software and set
the configuration for OSC=RC, WDT=ON, CP=ON, everything seems to program
properly and the chip verifies but when I use the chip in my
application, it does not work as it should. Reading the config data back
from the programmed chip returns the factory settings for the chip. Am I
doing something wrong here?
My default config options in the *.ASM file looks like this:
Everything seems okay but I am just getting started in the pic world and
am far from being an expert in this. I would appreciate any and all help
for a beginner. I suppose my specific questions are:
1) Can I use my *.HEX file as is to program a PIC16c54-rc/p AND a
PIC16c54A or do I need to set the config for each type of chip?
2) If I program my 16c54-rc/p code into a 16c54A chip, will the 16c54A
work properly? And vice versa?
3) If I set the config options manually, will they override the default
config settings programmed into my *.asm file? For example, I find that
when I write the code to the chip, the settings always come back as:
OSC=RC, WDT=ON, CP=OFF
These are the default settings for the chip when I do a read config from
a blank chip so it looks like the config file is not being written. Is
this the case or am I doing something else wrong? This is also the case
when I set the config manually with the software that J&M has shipped
with their programmer. I want CP to be On but it always comes back as
Off and then the chip does not work as it should. Thanks again for any
help and suggestions.
At 05:20 PM 3/17/97 -0800, you wrote:
>Hi all,
>
>I'm trying to program a 16C84 with a low cost PARALLAX programmer
>and have some trouble:
> 1/ I'm obliged to program 3 or 5 times the chip to have
>the oscillator programmed for CRYSTAL and not RC
> 2/ I have the programmed chip (SMD), then sold it onto the board.
>I connect RB6,RB7, MCLR and VCC to the programmer in order to modify
>the program. Problem is as the chip is programmed for Crystal oscillator
>the programmer as many difficulties to read and program it.
>
>Does anybody know if it's necessary the oscillator section run properly
>to re-program a 16C84 ?
>Does somebody have the same problem with a parallax programmer ?
I used the schematic Microchip had in the data sheet with the Parallax
programmer, and it works very well. Perhaps you have RB6 and RB7 in
contention with another device on your target board?
You DON't want the oscillator running at this time. You can accomplish
that by simply grounding pin OSC1.
Andy
==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
Hardware & Software for Industry & R/C Hobbies
"Go fast, turn right, and keep the wet side down!"
==================================================================
At 17.20 17-03-1997 -0800, you wrote:
>Hi all,
>
>I'm trying to program a 16C84 with a low cost PARALLAX programmer
>and have some trouble:
> [ ... ]
> Problem is as the chip is programmed for Crystal oscillator
>the programmer as many difficulties to read and program it.
>
>Does anybody know if it's necessary the oscillator section run properly
>to re-program a 16C84 ?
>Does somebody have the same problem with a parallax programmer ?
>
>Regards,
> Philippe.
Hi Philippe
I've had a similar problem with a 16C74 and a Smart-ICEPIC, a
programmer/simulator/emulator from RAM Technology Systems, Dorset, England.
The PIC was not programmed reliably when the oscillator was running. I was
told that it's a problem with PIC device, not the programmer.
Try disconnecting the crystal while programming, the device don't need it.
It worked for me and the 16C74. I don't know about the 16C84 but it may work
for you too. Bonne chance.
The Microchip data sheet says the 16C7X PIC's can be programmed
in-circuit via RB6,RB7, VDD, VSS, and MCLR.
1. Has anybody done this.
2. I have a PICSTART Plus programmer, can I hook the appropriate pins on
the PICSTART to the 16C7X and program it in-circuit. I followed the
data sheet suggestions for in-circuit programming while developing the
schematic for the board.
3. If not #2, is there any available software to read a Mplab programming
file and generate the programming waveforms using a PC parallel port.
Hello PICkers!
Can anybody send me a copy of the PROGRAMMING DATA SHEET for the 16C84
please? I have asked Microchip already and did not get any reply.
Thank you in advance.
In a message dated 97-04-10 11:30:26 EDT, you write:
<<
Hello PICkers!
Can anybody send me a copy of the PROGRAMMING DATA SHEET for the 16C84
please? I have asked Microchip already and did not get any reply.
Thank you in advance.
The Microchip data sheet says the 16C7X PIC's can be programmed
in-circuit via RB6,RB7, VDD, VSS, and MCLR.
1. Has anybody done this.
2. I have a PICSTART Plus programmer, can I hook the appropriate pins on
the PICSTART to the 16C7X and program it in-circuit. I followed the
data sheet suggestions for in-circuit programming while developing the
schematic for the board.
3. If not #2, is there any available software to read a Mplab programming
file and generate the programming waveforms using a PC parallel port.
> The Microchip data sheet says the 16C7X PIC's can be programmed
> in-circuit via RB6,RB7, VDD, VSS, and MCLR.
>
> 1. Has anybody done this.
Yes.
> 2. I have a PICSTART Plus programmer, can I hook the appropriate
> pins on the PICSTART to the 16C7X and program it in-circuit. I
> followed the data sheet suggestions for in-circuit programming
> while developing the schematic for the board.
Yes, you can run wires from the PICSTART to your target board;
just make them as short as possible, and make sure that you halt
your target circuit's oscillator during programming by grounding
the PIC's OSC1 pin or whatever.
I have loocked extensively on the microchip site and I can't find the
PROGRAMMING data sheet for the 16c84. If any of you know the exact URL for
the site please tell me. Do not confuse the ordinary data sheet with the
programming one.
Francesco Cembrola wrote:
>
> I have loocked extensively on the microchip site and I can't find the
> PROGRAMMING data sheet for the 16c84. If any of you know the exact URL for
> the site please tell me. Do not confuse the ordinary data sheet with the
> programming one.
>
> Francesco Cembrola
Send a blank message to helpspam_OUTspam_OUTdontronics.com for more info.
SLI, the serial LCD that auto detects baud rates from 100 to 125K bps.
SimmStick(tm) A PIC proto PCB the size of a 30 pin Simm Memory Module.
At 03:20 PM 4/10/97 GMT, you wrote:
>The Microchip data sheet says the 16C7X PIC's can be programmed
>in-circuit via RB6,RB7, VDD, VSS, and MCLR.
I recommend pulling OSC1 to ground also to prevent oscillation screwing up
the start of the program mode.
My in-circuit programming jack is now a six-lead connection to take care of
this.
It works fine even from a Parallax programmer.
Andy
==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
Hardware & Software for Industry & R/C Hobbies
"Go fast, turn right, and keep the wet side down!"
==================================================================
Get AN589 - application note for simple programmer. It is like a case
study even.
On Thu, 10 Apr 1997, Francesco Cembrola wrote:
> I have loocked extensively on the microchip site and I can't find the
> PROGRAMMING data sheet for the 16c84. If any of you know the exact URL for
> the site please tell me. Do not confuse the ordinary data sheet with the
> programming one.
>
> Francesco Cembrola
>
At 17:58 10/04/1997 -0400, you wrote:
>I have loocked extensively on the microchip site and I can't find the
>PROGRAMMING data sheet for the 16c84. If any of you know the exact URL for
>the site please tell me. Do not confuse the ordinary data sheet with the
>programming one.
>
Exact data-sheet number is: 30189D.PDF - 114.031 Bytes, 14 pages
I notice that Daniel Chester is programming sucessfully from his parallel
port over a long length of cable. This doesn't mean that every PC will do
so. A lot depends on the characteristics of the PC's port. Funnily enough,
the older the PC's I/O the better it is likely to work for PIC programming.
See some relevant info on David Tait's pages at http://www.man.ac.uk/~mbhstdj/maplin.html with some follow-up and suggested
further reading linked from there. I made a Maplin kit which worked fine on
every PC but mine - guess which one had the "best" I/O card? I think Steve
Nolan's suggestion to limit cable length is probably a good one.
Tim Forcer Tel: (+44) (0)1703 593362
Fax: (+44) (0)1703 592053
email: @spam@tmfRemoveMEecs.soton.ac.uk
Department of Electronics & Computer Science
Room 3005, Building 35
The University, Southampton, SO17 1BJ UK
I also use the parallel printer port for programming the PIC. I got my
programmer kit from Magenta Electronics. At first it refused to work and
aftef being satisfied that the hardware was functional I looked at the CMOS
setting of may P.C. and changed the printer port fron enhanced to standard,
and it worked!
Any ideas as to what the best programmer is for in circuit programming?
I have a design that is having trouble with in circuit programming using
the picstart 16C. I use a '73A. Rb6 and Rb7 have 20K ohm between them. They
also drive the input of a 5V logic chip. I've put a fast buffer on Vpp and
Vdd. Still the Picstart 16C errors out after a adress or two. I've tried
the picstart plus and it's worse. It won't even blank check the parts. (I
just love destroying all these OTP parts! :-)
I suspect that the long leads and parasitic effects are causing the
pic to miss data on the Rb6/7 pins. The Picstart seems to be pushing some
of the clock pulses fast to make up time, I figure those are the ones that
are not getting through.
Does anyone know what programmers would be a bit slower in the
clock and data timing? Or has anyone sucessfully slowed down a Picstart
16C? At this stage in the game I would be happy to buy any programmer that
would pull it off.
TIA
-Otmar-
-----------------------------------------------------------------------
Otmar Ebenhoech Electric Vehicle Components Ltd.
"I wish I die sleeping like my grandfather,
not screaming in terror like his passengers." Otmar@spam@EraseMEEVCL.com (415) 494-9255
-----------------------------------------------------------------------
Today, for the second time, I tried programming a 16F84 in my self-built
programmer at work (normally I use a BP Microsystems unit, but on this
occasion my self-built one was hooked up). Unfortunately, my programmer
doesn't seem to work on any non-blank 16F84's (it worked fine for reprog-
ramming 16C84's). My suspicion is that Microchip has changed the opera-
tion of the "program word" instruction so that it no longer does an erase
before write.
[1] Is there any way to erase a word of code space on the 16F84 without
erasing the whole thing?
[2] How should I erase the whole thing if needed? I'm running in serial
mode. I tried the command someone posted once but it didn't seem to
work; maybe I misremembered it?
[3] If the part no longer does an erase-before-write, does this mean that it
can be programmed any faster? Is there any way to see if the device is
done with a spot (other than waiting 10ms)?
______________________________ Reply Separator _________________________________
Subject: Programming 16C84 vs 16F84
Author: John Payson <spam_OUTsupercatspam_OUTRemoveMEMCS.NET> at Internet_Exchange
Date: 4/24/97 7:10 PM
-snip-
My suspicion is that Microchip has changed the opera- tion of the "program
word" instruction so that it no longer does an erase before write.
A. Suspicion incorrect. F84 programs identically to C84 and does a erase
before write.
[1] Is there any way to erase a word of code space on the 16F84 without
erasing the whole thing?
A. Program 03FFFh
[2] How should I erase the whole thing if needed? I'm running in serial
mode. I tried the command someone posted once but it didn't seem to
work; maybe I misremembered it?
A. See PIC16F8X programming spec pg. 17-81 in latest databook or pull
from the web. FYI; 001001 is bulk erase program memory, 001011 is
bulk erase data memory.
[3] If the part no longer does an erase-before-write, does this mean that it
can be programmed any faster? Is there any way to see if the device is
done with a spot (other than waiting 10ms)?
A. There is an internal timer and control circuit that does the
erase/program cycle. You must wait the 10ms for it to finish. BTW, we
are looking at methods to make the programming faster on the next
generation F8X devices.
First of all, I would like to know if I could program the 16C74
with the EPIC Programmer. I do not have any adapter but could I just
pull all the wires from the programmer's socket onto the correct pins
of the 16C74 PLCC?
Does any of you know any source code that implements the 16C74's
PWM module? I would like to use it for servo control...
KM> Today, for the second time, I tried programming a 16F84 in my self-b
KM> programmer at work (normally I use a BP Microsystems unit, but on th
KM> occasion my self-built one was hooked up). Unfortunately, my progra
KM> doesn't seem to work on any non-blank 16F84's (it worked fine for re
KM> ramming 16C84's). My suspicion is that Microchip has changed the op
KM> tion of the "program word" instruction so that it no longer does an
KM> before write.
The problem might be that the code protection has changed. Instead of
one bit (#4) there are ten bits (13-4) protecting code. Your programmer
software isn't aware of that, and that's why it can't erase F-part.
Though, if you haven't protected parts (intentionally or un-) there
is something else going wrong. Remember, F's CP is the same way
than C's, the PWRTE is vice versa.
One solution would be going back to C-parts, but F's do have more
precious RAM, so...
Does anyone know of a WWW addess that has the "Reference Documents" that
are described in the Microchip databooks? Specifically, I am looking
for the details of In-Circuit programming of a 16C62A. The manual
refers to Reference Doc. #DS30228. Any details would be appriciated
(including any hardware, schematics, download code, etc...)
--
Daniel Holt - Genetronics Inc.
______________________________ Reply Separator _________________________________
Subject: In-Circuit Programming
Author: Daniel Holt <EraseMEdholtKILLspamGENETRONICS.COM> at Internet_Exchange
Date: 4/28/97 4:30 PM
Does anyone know of a WWW addess that has the "Reference Documents" that
are described in the Microchip databooks? Specifically, I am looking
for the details of In-Circuit programming of a 16C62A. The manual
refers to Reference Doc. #DS30228. Any details would be appriciated
(including any hardware, schematics, download code, etc...)
--
Daniel Holt - Genetronics Inc.
After finding out that Needhams can't even say when they will support
the PIC 16C924, I got to thinking there must be a way to program these
on existing programmers. Since most of the PICs use the same serial
programming algorithm, it seems like any similar PIC could be programmed
by wiring an adapter socket to bring the programming pins to the correct
locations. (such as an adapter to make a 16C924 look like a 16C74 to
the programmer) Has anyone tried this?
I am interested in In-Circuit Programming some parts in a future
system. Is it possible to simply take the four or so lines required to
program a part (and assuming I leave the required pins free on the
board) use my pic-start programmer to do the programming by taking the
relevant data lines from the ZIF socket to a socket on the board? This
seams like an easy way to do this by just making a jumper cable of
sorts. Any reason this wouldn't work?
--
Daniel Holt - Genetronics Inc. EraseMEdholtspamBeGonegenetronics.com http://www.genetronics.com http://rohan.sdsu.edu/home/holt/index.html
Daniel Holt wrote:
>
> I am interested in In-Circuit Programming some parts in a future
> system. Is it possible to simply take the four or so lines required to
> program a part (and assuming I leave the required pins free on the
> board) use my pic-start programmer to do the programming by taking the
> relevant data lines from the ZIF socket to a socket on the board? This
> seams like an easy way to do this by just making a jumper cable of
> sorts. Any reason this wouldn't work?
> Daniel Holt - Genetronics Inc.
No, you will find a circuit of just that using a 4PDT switch to do the
job. In the case of 84's, it means target board programming on the fly.
That is, a load/go switch. http://www.dontronics.com/84.html
PICSTART and Newfound PIC Programmers Firmware Upgrades.
SLI, the serial LCD that auto detects baud rates from 100 to 125K bps.
SimmStick(tm) A PIC proto PCB the size of a 30 pin Simm Memory Module.
Send a blank message to helpspam_OUTdontronics.com for more info.
Display limited to first 300 matches. Add keywords to narrow the result set or browse by year:
- In 1997
, 1998 only
- Today - New search...
informatik.uni-kiel.de
