Topic PIC16PGM from HARDW FAQ base
Ïîæàëóéñòà, îáðàòèòå âíèìàíèå íà äàòó ïðåäñòàâëåííîãî çäåñü ñîîáùåíèÿ! Èíôîðìàöèÿ îá àäðåñàõ, òåëåôîíàõ, îðãàíèçàöèÿõ è ëþäÿõ íàâåðíÿêà óñòàðåëà è ïîòåðÿëà ïðàêòè÷åñêóþ öåííîñòü, îáðåòÿ, îäíàêî, öåííîñòü èñòîðè÷åñêóþ, çàðàäè êîòîðîé äî ñèõ ïîð è õðàíèòñÿ...
— SU.HARDW.OTHER (2:5020/299) ———————————————————————————————— SU.HARDW.OTHER —
From : Antony Drokin 2:5020/49.2 Mon 27 Mar 95 23:56
Subj : .õåìà ïpîãpàììàòîpà äëÿ PIC 16c84. .î çàÿâêàì ÷èòàòåëåé ;)
————————————————————————————————————————————————————————————————————————————————
=== Cut ===
Basic PIC 16C84 programmer for PC parallel port
===============================================
David Tait (david.tait@man.ac.uk)
=================================
_____ _________
13.8V | | 5V | |
+--+---|78L05|--+---|1/4 4066|-----------------------------+
| |_____| | |_________| |
_|_ | _|_ | ________________ | 100n
10u___ | ___100n | O| 1 U 18 |O | | |
| | | | O| |O +----| |----+
/// /// /// | O| |O | | | |
| +-----O| MCLR/Vpp |O | _____ |
|\ | | +--O| Vss Vdd |O----+--|_____|--+
-----| >o--+---------+ | | O| RB7 |O------+ 10k |
(4) |/ | _____ | /// O| RB6 |O----+ | ///
+-|_____|--+ | O| 16C84 |O | |
-------+ 18k 13.8V | O|________________|O | |
(25) /// _________ | | |
| | | _____ | |
13.8V +------|1/4 4066|----+---|_____|---+ | |
|_________| 10k | | |
|\ | _____ /// | |
-----| >o-------+----|_____|--+ 13.8V | |
(5) |/ 18k | |
_____ | |
LPT1 +--|_____|--+ 5V | |
|\ | 10k | |
-----| >o----+------------------------------------------+ |
(3) |/ _____ |
+--|_____|--+ 5V |
|\ | 10k |
-----| >o----+--------------------------------------------+
(2) |/ |
All gates are inverting or non-inverting |
/| TTL O/C buffers, 74xx06, or 74xx07 |
<-ACK>----o< |--------------------------------------------------+
(10) \|
4066: pin-14, 13.8V; pin-7, GND. buffer: pin-14, 5V; pin-7, GND.
=== Cut ===
— SU.HARDW.OTHER (2:5020/299) ———————————————————————————————— SU.HARDW.OTHER —
From : Antony Drokin 2:5020/49.2 Mon 27 Mar 95 00:18
Subj : FAQ ïî ïpîãpàììàòîpó äëÿ PIC16c84 1/4
————————————————————————————————————————————————————————————————————————————————
=== Cut ===
Frequently Asked Questions About PIC84PGM.ZIP With Some Answers
===============================================================
(Original 11th March 95) V-0.1 16th March 95
David Tait
Electrical Engineering Dept
The University
Manchester M13 9PL
UK
david.tait@man.ac.uk
Copyright (C) 1995 David Tait
Introduction
------------
PIC84PGM.ZIP (available from ftp.ee.ualberta.ca/pub/cookbook/comp/ibm,
Microchip's BBS in the 3RDPARTY library, and elsewhere) contains a
crude ASCII schematic for a simple PIC16C84 programmer designed to be
attached to the parallel port of a PC. It also includes the source
code for some rudimentary C and QBasic drivers for the hardware. In
case you don't know, the PIC16C84 is a single chip microcontroller
which fits a lot of good things into a small (18-pin) package; in fact
it is a developers dream come true. It's fast, moderately cheap, and
best of all it's program is stored in EEPROM. This last feature makes
it especially convenient in the development stages of a project; it
even has cheaper one-time programmable (OTP) cousins for use in a
final product. Another useful attribute of the 16C84 is that it can
be programmed with only a few signals (called serial mode programming)
and what's more, the required signals have very lax timing specs. As
a considerable bonus, the manufacturer, Microchip Technology Inc,
provide free PIC development software via their BBS or Internet site.
You can also grab useful software and information from the Internet
site of Parallax Inc, a company that supports the PIC series. It is
true that both these companies also sell some reasonably priced
prototype programmers, but if you want a dedicated 16C84 programmer,
the DIY route is quite attractive.
When I looked about a year ago I couldn't find anything to help me
build a programmer so I just got the required info from Microchip and
did it myself; it was not very difficult (I had to have a couple of
goes at getting the hardware right though). I decided to make my info
available on the net just in case it helped anyone about to re-invent
this particular "wheel". It turns out I didn't explain things as
comprehensively as I should have done and the legacy of this project
has been a steady stream of e-mail that has to be answered. It seems
that many people from all over the world are just discovering the
delights of the 16C84 and would like a cheap and cheerful development
system to go with it. Helped no doubt by the very useful PIC FAQ
produced by Tom Kellett et al, these same people get to hear about my
humble efforts. I guess most people that grab the files just take the
good bits (if indeed there are any) and get on with designing their
own superior versions. It's likely I'll never hear from this group at
all. I suspect this group own oscilloscopes. On the the other hand
there are some people that assume that my design can replicated
exactly and will work from the first moment they apply power, and
though this will be true for a lucky few, on the whole this group run
into some kind of hardware/software problems. Needless to say this
group are unlikely to own oscilloscopes and I certainly do hear from
them. I try hard to help, but faultfinding by e-mail is a frustrating
experience at best. I feel responsible for their disappointment and
frustration. All is not lost though; there are some common stumbling
blocks that account for most of the problems that can crop up. The
purpose of these notes is just to describe the potential gremlins and
their cures, and to answer one or two other questions that I'm often
asked. I'm sorry this file is so long and rambling, but I hope that
if I answer everything now as fully as possible, I might get a rest
from answering the same questions multiple times by e-mail.
Some answers refer to my programs for reading a PIC. The software is
supplied as both C (rp.c) and QBasic (rp.bas) source and should be
available where you picked up this document or even packaged with it.
The software is only designed to read program memory but it's really
very easy to modify it to read other areas of the 16C84 memory. See
the source comments for details on how to run the programs.
Hardware Questions
------------------
Q1. Has _anybody_ got this to work?
A1. Yes. At least 40-50 people have been kind enough to send me mail
to say they got it working themselves. I've lost count of the number
people I have tried to help by e-mail. I suspect that a great many
others have got it to work too, but they have not got in touch for one
reason or another. Ask any shareware writer about the likely ratio of
registered users to total users and then remember my stuff is free, so
there is not much incentive to get in touch. (Unless there is a
problem that is, which is the motivation behind this document in the
first place.) As I write this, I see that the file has been
downloaded well over a thousand times from the Microchip BBS alone.
Q2. Your drawing shows devices marked 74xx07 and 74xx06. I can't find
them in any catalogue, where can I get them?
A2. I just meant any TTL open-collector (O/C) buffer like the plain
7407 or 7406, or better still if you can get them, the 74LS07 or the
74LS06. Similar members of the 74HC family are probably OK if such
things exist. One of my programmers uses a 74LS05 which is really out
of spec in this circuit, but seems to work fine. I didn't think the
choice of buffer was critical, but a few reports have made me think
again about using the plain 7406 or 7407. I understand that another
popular 16C84 programmer design uses a 74C906, and this slightly more
modern device may have been a better choice for my programmer too. If
you want to try one, please note that it is not a drop-in replacement
for a 7406. It seems you can be even more adventurous about replacing
the buffer: one person told me that he couldn't find a suitable chip
in his junkbox so he replaced the buffers with 5 VMOS FETs and they
worked a treat. I suppose it is even possible to connect the PIC
directly to the parallel port and do away with the buffers altogether.
Though this needs a little trickiness because RB7 is read/write.
Anyway, I wouldn't recommend this, but I know it can be done. For the
real minimalist, do this and replace the electronic switches with
manual ones and get the program to prompt you to operate them at the
correct times!
Q3. Your diagram implies that either inverting or non-inverting buffers
can be used. Surely they can't be interchangeable, or can they?
A3. Well not exactly. This is something I should have mentioned in
the README but didn't. You _can_ use either type of buffer but you
must make sure the software is changed accordingly. As supplied, the
source and the EXE file assume inverting buffers are used (i.e. the
74xx06 type). In fact as one of the 6 available buffers is not used I
actually missed an opportunity to make the hardware self configuring.
If I had connected the input of the spare buffer to an output pin of
the parallel port and the output of the buffer to an input pin the
software could have worked out itself whether the buffer inverted or
not. Oh well. You should refer to the software section if you
happened to select non-inverting buffers to build the circuit.
Q4. It would make my life easier if you could supply me with a PCB
layout. Do you have one? What about a better diagram at least?
A4. Recently one satisfied user promised to send me a layout so that
I could make it generally available. I don't have it yet, but when I
do I'll ask the designer whether I can upload it to the circuit
cookbook site. Actually it's not obvious that a PCB layout of the
circuit exactly as shown would be the most useful. I mentioned in the
README file that the spare sections of the 4066 could be used to
isolate the RB6 and RB7 pins from the buffers. Maybe it wasn't
obvious, but I meant that this would be a good way to implement an
in-system programming system. You'll also need to arrange for MCLR to
be taken to +5V for the PIC to run - a diode to +5V is probably OK; in
fact someone sent me a diagram of exactly this setup so they obviously
got the message. If you want to design your own PCB it shouldn't be
too much of a problem; the low complexity of this programmer is
ideally suited for use in evaluating the numerous demo versions of PCB
software that are in circulation. I was quite impressed with a demo
of CIRCAD (no, not the program by the same name that's on the Simtel
sites). As I write this, a copy can be snatched from
ftp://mobius.gmu.edu/pub/circad. It has both PCB layout functions and
schematic capture so you can draw a better diagram yourself! Recently
Don Mckenzie has posted info on the 3RDPARTY file area of the
Microchip BBS about a supply of PCBs for his own programmer design.
He doesn't have Internet access but you can reach him on the Microchip
BBS e-mail system where his user ID is simply don mckenzie. I only
mention this here because he supplies his own improved version of my
QBasic software and he was kind enough to send me a free PCB :-) See
the PIC FAQ about connecting to the BBS if you want to get in touch
with him.
Q5. I have built your hardware exactly as shown and it doesn't work!
I have checked it a hundred times and it looks OK to me. Are you
_sure_ the diagram is correct?
A5. Well, the fact that it doesn't work might not be due to the
programmer hardware alone and you should look at the answers to the
software questions too. To answer the correctness question: the
diagram is correct as far as it goes. My first programmer of this
type was more or less exactly as shown. However it does suffer from
some sins of omission. I should have made it clear that it is
necessary to add decoupling capacitors for the 4066 and the buffer.
The decoupling components are not shown in the diagram, but 100nF caps
should be connected between, and close to, the power pins of both
chips. As one of my e-mail correspondents put it: if the person
building this circuit didn't know that they should add decoupling
caps, then they are going to have a terrible time getting their PIC
applications to work. That made me feel good for a minute or so, then
I felt guilty again because I hadn't made the need for decoupling
explicit. The circuit is deceptively simple, but it is not that easy
for an absolute beginner to go from my diagram to a working
programmer. Not really a correction, but a couple of LEDs on VPP and
VDD, while not helping the circuit work any better, are at least
colourful and let you know that things are working. By the way,
rather than just giving the board a visual check, I would urge you to
write a simple program to toggle the LPT output pins (D0-D3) and read
the input pin (-ACK) - QBasic is great for this. If you don't have
any test equipment, use the spare buffer to drive an LED and use this
as a simple logic probe. Getting the pins to change as expected will
go 99% of the way to solving your problems.
Q6. Why 13.8V?
A6. Initially I used a power supply intended for citizen's band or
amateur radio equipment (I have such a thing handy because I'm a radio
ham - G0JVY). As much of this equipment is expected to be used
mobile, i.e. in a car or truck, the power supply is designed to
produce the typical voltage of a fully charged car battery - 13.8V
apparently. You don't have to follow this slavishly; the spec is
something like VDD+4V (i.e. 9V) to 14V, but I'm reliably informed that
using too low a voltage can lead to unreliable programming. A 3-pin
12V regulator, like a 7812, with a couple of silicon diodes from its
ground lead to ground gives a decent enough 13.2V when supplied with
16-18V from a unregulated wall adapter. Following a suggestion made
on the net, I mentioned in the README that it's possible to get power
from a spare floppy disk lead. After hearing a sad tale from someone
who tried this, I no longer think that's a good idea.
Q7. Anything I should know about the cable between the PC and the
programmer?
A7. Keep it short for one thing. There are some fast pulses
travelling along this connection and long runs of ribbon or multiway
cable terminated in a just a TTL input can mangle them. I suppose
twisted pairs with separate earths and good terminations would be
best, but my own cable is nothing special and I have no problems.
Hopefully you will not either. However, if the programmer seems to
fail with a verify error at location 0 (the typical indicator of
programmer malfunction), it is worth paying some attention to the
waveforms produced at RB6 and RB7 and the inputs of their associated
buffers. Ideally you would use an oscilloscope to view them; perhaps
then you can see what might be done to improve them. Resistive
terminations should be the order of the day, but if you are not proud,
don't own an oscilloscope, and are ready to accept a more empirical
approach: two small caps (10-50pF) one between RB6 and ground and one
between RB7 and ground are certainly worth a try. This has been
suggested to me a couple of times. One person mentioned that the
circuit worked with an oscilloscope connected to RB6 and RB7 but
failed to do so when the scope was not connected, so, being a clever
chap he simulated the two scope connections with 1M resistors in
parallel with 12pF and this solved his problem.
Q8. I have read the programming specs in data sheet DS30189C and your
design cannot possibly work. If you had read them too you would have
seen that the max current from Vdd (+5V) is rated at 50mA. Now, let
me point out that the R-on spec for a 4066 switch is 80 Ohms; perhaps
you are not aware of Ohms law, but it says that 0.05*80 = 4V will be
dropped across the switch leaving only 1V for the PIC! What's more
the maximum possible R-on is much higher than 80 Ohms leaving even
less for the PIC. What do you have to say to that?
A8. Thanks for the electronics lesson. I can only plead ignorance
(though not of Ohms law!) because I designed the circuit based on the
information in DS30189A which is an earlier version of the data sheet
you quote. There was no mention of such a high current rating in my
data sheet. In fact, because my programmer _does_ work, it seems most
unlikely that a typical PIC needs anything like this much current. I
have measured the voltage drop across the Vdd switch and it is
typically only a few tens of mV (though I must admit I've only tried
this with a few different PICs and 4066s). I also have connected a
scope to Vdd during programming and I couldn't detect any short
glitches which might indicate large current demands for short amounts
of time. If you are still worried about this, the 4066 switch can be
ditched in favour of a separate bipolar transistor switch. Here is an
ASCII sketch of a suitable replacement:
+5V
+
___ |
+--[___]---+
| |
|\ ___ | B |/ E
----| >o---[___]---+--------| PNP
|/ |\ C
|
+---+ Vdd
The resistors can be 10K. You should retain the 10K//100nF network
connected to Vdd. Of course it makes sense to change the Vpp switch
too so that you don't need the 4066 at all (the Vpp switch should have
E connected to +13.8V and C connected to Vpp and be driven by the
buffer connected to D3). If you have already built the hardware and
used a socket for the 4066, a neat idea is to put the transistor
switches on a DIL header and simply replace the 4066 with this. The
software will need minor changes to account for the inverted operation
of the new switches. In the programs you'll find definitions for
controlling the LPT pins for both types of buffer. To get an inverted
signal just borrow the definitions for the opposite type.
Q9. Your circuit has an error! Have you forgotten to include a
pull-up resistor for the O/C buffer driving the ACK pin (pin 10)?
A9. I think you are right. However, I didn't forget to include one
because I thought that the ACK pin had an internal pull-up. I don't
use ACK pull-ups on my own programmers and they seem to work. Anyway,
it can do no harm, and probably some good, if you fit a 10K resistor
between the ACK pin and +5V. Certainly this is something to try if
you are having trouble getting the programmer to work.
Q10. Are there any other designs available, especially for other
members of the PIC family? If not can your design be suitably
modified? Where can I get more PIC info?
A10. The 16C84 is particularly well served by DIY programmer designs
and there have been more universal designs published in several hobby
mags (see the PIC FAQ for some pointers). The 16C5X family cannot be
programmed in serial mode, but I believe most, if not all the 16CXX
PICs could be programmed using some approximation of my hardware.
However, the programming pulses required are considerably different to
those produced by my software; they need to be more accurate for one
thing. Although it's not an entirely trivial job, it is worth getting
the programming specs and having a go at writing your own programmer
software. For more info on PICs I only need to give you one
suggestion: get the PIC FAQ. The FAQ will tell you about the
Microchip BBS and Internet sites, the PICLIST mailing list, the
Parallax Internet site and lots more besides. To get the PIC FAQ you
can use Andy Errington's Web page:
http://www.lancs.ac.uk/people/cpaame/pic/pic.htm
It's links are growing daily and one should point at the latest copy
of the PIC FAQ. By the way, Andy recommends the everyone interested
in PICs should equip themselves with a copy of Microchip's Embedded
Controller Handbook.
Q11. How many programming cycles can I expect to get?
A11. How long is a piece of string? The expected range of
possibilities is very large. You should be able to rewrite program
memory an absolute minimum of 100 times and typically a few hundred to
maybe a thousand times. Data EEPROM can be reprogrammed many hundreds
of thousands of times I think.
Q12. Can your hardware be used to read a code-protected 16C84? Do
you know how to read a code-protected PIC?
A12. I have heard speculation and rumour, nothing more.
Q13. Can I use your programmer for in-system programming?
A13. See A4 above for some hints. Also see Microchip application
note AN589 by Robert Spur for another design. Although the
application note gives the core routine for serial mode programming,
it needs a wrapper to use it as ready-to-go progamming software.
It's possible to use pp.c or pp.bas instead with just a few mods.
Q14. You say in the comments of pp.c that your design is _not_ a
production quality programmer. What is it then?
A14. It's a prototype programmer. These are terms used by Microchip.
The difference is based on the thoroughness of the verification
procedures used. A production programmer not only verifies with Vdd
set at a nominal +5V, but it also does so at other values (typically
+4.5V and +5.5V). It's no doubt possible to modify my programmer to
do this, but if you are going into production and programming many
PICs you probably owe it to your customers to invest in a more
upmarket programmer.
Q15. Thanks for making your programmer design available and I am
very happy with it. How can I thank you?
A15. Spare a moment to let me know you got it working by sending an
e-mail message to david.tait@man.ac.uk (or to user ID david tait on
the Microchip BBS). A postcard would be nice if you can't send
e-mail. Anyway, if it has saved you a bit of time and effort I'll be
happy.
Software Questions
------------------
Q1. Do I need a QBasic compiler to run the QBasic program?
A1. No. Just use the interpreter that comes with MS-DOS. I wrote
the Qbasic stuff so that people without a C compiler could still hack
something. I'm afraid I learnt QBasic from the on-line help in a
couple of days and it shows.
Q2. I built your hardware design using a 7407. I tried the EXE supplied
and it didn't work. I tried the Qbasic program and it didn't work either.
What is wrong?
A2. Try a 7406 instead! The trouble is that both the C and QBasic
programs were set up for hardware employing inverting buffers like the
7406. This means the EXE was built for 7406 based hardware too. The
C program can be reconfigured for non-inverting buffers like the
7407 by including the line "#define U7407" (it is commented out in the
distributed version). The Qbasic program can be set up for a 7407 by
using these definitions:
CONST DataInv = 0
CONST VppOn = 8, VppOff = 0, VddOn = 4, VddOff = 0
CONST ClkHi = 2, ClkLo = 0, OutHi = 1, OutLo = 0
The comments incorrectly suggest that you should use ClkHi = 4. Surely
very few programs have bugs in the comments!
Q3. I monitor the VDD and VPP supplies on my board with LEDs and I see
that one of the supplies is turned on after I reboot my machine.
Is it OK to insert the PIC into the programming socket despite this?
A3. No. Just run the software with the port number as the only
argument; the program will initialise the port and the supplies will
be switched off.
Q4. I am using the C software and I know it is correctly configured
for my hardware but it still doesn't seem to work. Whenever I try to
program a PIC I get an error message something like this:
pp: 0000: YYYY != XXXX
pp: Verify failed during programming
Nothing I do gets round this. Can you help?
A4. Reports from people getting this error message account for quite
a bit of the e-mail I receive about my programmer. Unfortunately on
its own it is not a very helpful diagnostic. The error simply means
that the programmer tried to program the very first location in
program memory to XXXX (hex) but read back YYYY. To save programming
cycles the software doesn't try a second time. (When things are
working properly all locations should program first time anyway.) The
fact that it was the first location that failed is usually indicative
of some sort of programmer malfunction. If verify errors occur at
other addresses it's just as likely to be caused by a PIC's EEPROM
becoming unreliable. I suggest the real answer to your problem will
be found somewhere in the answers to the hardware questions. However
when you've tried all the ideas from there, you might start to suspect
a timing problem. In this case it's worth trying the QBasic software
to check your hardware - the QBasic interpreter runs slowly enough for
timing not to be a problem. If the QBasic stuff works then change the
delay constants (THLD, TSET and TDLY) in the C source. Compare pp.c
with the source of my PIC reader rp.c to see what changes I have made
for my own 486DX33. The main idea is to ensure TDLY is about 1
microsecond, and THLD=TSET give the hardware enough time to respond.
In fact the constants I use in rp.c give very long delays, but as they
are still very small compared to the time taken to program a location
(about 10ms) they don't add much to the total time it takes to program the
device - there is really no need to spend time optimising the values.
If you are using my EXE file with a 486 then that may be the problem
in itself. I suspect the version of Borland C I use has a bug in the
delay() routine (needed to get the 10ms programming delay) that only
manifests itself with some CPU types, though I haven't been able to pin
it down. Try recompiling, maybe the bug is fixed in your compiler. If
you do recompile you can get stung by another problem: the latest C
compilers will optimise the tiny_delay() routine to nothing. This
will only be a problem on a fast PC that must rely on this routine to
slow it down. Again see rp.c for a fix to tiny_delay(). If all else
fails try running the PC at a slower clock speed if you can (some PCs
have a Turbo button for this).
Q5. PP.EXE complains that the hardware is not attached when I know
it is. I have specified the correct port but whatever I do it
refuses to work. What am I doing wrong?
A5. If the hardware is built correctly then nothing. It's likely you
have a pretty fast PC and/or "slow" hardware. To check that the
hardware is connected, the program writes to it and reads back the
response immediately; it is possible that the hardware doesn't respond
in time. See the changes to test_hw() in the source of the PIC reader
rp.c to see how you can cure this.
Q6. I hate MS-DOS. Will your programmer run under Linux? I hate
MS-DOS boxes. Will your programmer run on an Amiga/Macintosh/Atari?
A6. The "prog84" package from Wim Lewis will let you use my hardware
under Linux; look for it on ftp://ftp.funet.fi/pub/microprocs/pic (in
the directory burners). You should also get Ian King's software tools
from the same place (in the directory pictools). These programs are
probably fairly portable across all PC versions of Unix. For other
systems, the easiest thing might be for you to write your own
controller in your own favourite language. My C program will need a
little work for non-MS-DOS machines, but provided you have a C
compiler, a computer with a parallel port, access to I/O routines for
the parallel port and finally a millisecond accuracy delay routine it
shouldn't be too difficult to get it going. Ironically, having ported
the software from MS-DOS, you might find yourself using an MS-DOS
emulator in order to run a decent assembler/simulator. I'm told that
using the unmodified C program with an MS-DOS emulator works on the
Amiga.
Q7. I notice your program calls a routine named "erase" before it
attempts to program the PIC. The routine uses the undocumented
commands 1 and 7. What's going on?
A7. This is a routine to disable code protection so that a previously
protected chip can be reprogrammed. It has the side-effect of bulk
erasing the chip, that is erasing all program and data memory.
Microchip recommend that this procedure is performed before any other
programming is attempted. However, for some unexplained reason they
don't document the procedure for serial mode. I just tried the
parallel mode approach and it seems to work. Someone suggested that
this routine should only be selected if you are programming a
protected PIC thereby decreasing wear and tear on the fuse EEPROM
cells. They may have a point. See A11 for other mods of this kind.
Q8. How do I produce a suitable file to initialise data EEPROM?
A8. The programmer software takes a word (16-bits) of data from the
hex file and puts the least significant byte into the EEPROM data
memory. A suitable hex file can be created with any assembler. I
use MPASM and here's a short example that generates a valid INHX8M
data file:
list p=16c84
;
org 0
;
data 1,2,3,0xFF
data 'S,'t,'r,'i,'n,'g,'.
end
Note the special handling of the text string because the software
ignores every second byte of data.
Q9. Your programmer seems to work OK with files produced by MPASM
or MPALC. However I prefer to use the mnemonics offered by the Parallax
assemblers. Unfortunately your programmer software chokes on Parallax
hex files even though they are INHX8M compatible. Can you fix that?
A9. The problem (or perhaps advantage) with Parallax files is that
they embed FUSE, ID and EEPROM data into the same file and my software
doesn't expect that. The best solution is to change the loadhex
function to understand these files. Alternatively you can simply
ignore the non-program elements of the file by replacing this chunk of
loadhex:
for ( i=0; i= bufsize )
quit("Impossible address");
w = hexword(fp);
buf[address] = (hextype == INHX8M)? swab(w): w;
}
with
for ( i=0; i= bufsize )
continue;
buf[address] = (hextype == INHX8M)? swab(w): w;
}
Of course there is a similar workaround for the QBasic source; look for the
subroutine "LoadHex". It contains a FOR-NEXT loop that in the
original looks like:
FOR i = 1 TO NWords
IF Address >= BufSize THEN Quit ERRHEX, 0, 0, 0
wHi = HexByte%(Chan)
wLo = HexByte%(Chan)
IF HexType = INHX8M THEN w = 256 * wLo + wHi ELSE w = 256 * wHi + wLo
IF Which = ProgMem THEN ProgBuf(Address) = w ELSE DataBuf(Address) = w
Address = Address + 1
NEXT i
Delete line 2 and bracket the "IF Which = ....." with another IF
statement to get this:
FOR i = 1 TO NWords
wHi = HexByte%(Chan)
wLo = HexByte%(Chan)
IF HexType = INHX8M THEN w = 256 * wLo + wHi ELSE w = 256 * wHi + wLo
IF Address < BufSize THEN
IF Which = ProgMem THEN ProgBuf(Address) = w ELSE DataBuf(Address) = w
ENDIF
Address = Address + 1
NEXT i
Q10. I have version 0.3 of your software. Do you have you an updated
version?
A10. No. The existing version works for me and does everything I
need, so I doubt if I'll ever get round to producing a significantly
better version. An important function that you might want is a
routine to read the PIC and so I have written a separate utility to do
that; it is also easy enough to verify a PIC by combining the PIC
reader functionality with the loadhex routine from the programmer
source. The core parts of rp.c and rp.bas are tiny routines to
actually read the PIC and some routines to spit out INHX8M files;
the rest is much the same as pp.c and pp.bas. If you _really_
wanted INHX16, check loadhex() for hints on the difference.
Q11. The time to program the PIC seems independent of the number of
locations that must be programmed. Why?
A11. My software programs all locations every time. It is easy to
change this behaviour. One modification you might consider would be
to read the entire PIC (program/data/fuses) into a buffer and then
only reprogram the items that differ from the new values. The
verify() and config() routines can be modified and combined to read
the entire PIC.
Q12. I use the QBasic program and sometimes when I quit I get a blank
screen and the machine seems dead. Can I fix that?
A12. Yes. If you type CLS the screen will come back to life. Fix
the source by adding a CLS statement just before each occurrence of
the END statement (a couple of places). You can also replace END
with SYSTEM for a more abrupt end.
Q13. I use MPASM which amongst other things produces .obj files. The
instructions for pp.c say it expects "objfiles" but when I try to use
the .obj files it complains. Why?
A13. You should use the .hex files produced by MPASM. I know my name
is confusing, but it's because when I wrote the program I used the MPALC
naming convention. MPASM produces INHX8M by default whereas MPALC
produced INHX16, so you might like to change the programmer defaults
if you use MPASM (or the Parallax assembler with the A9 fix).
Q14. My PC makes a noise when I run your QBasic program. Is anything
wrong?
A14. No. I use the Qbasic PLAY command to get a small delay and on
some PCs this can lead to a slight purr from the internal speaker. If
you find it objectionable just replace the "PrgDly" routine with a
FOR-NEXT loop that wastes an amount of time of at least 10ms.
Q15. Can I use your software from a DOS window under Windows?
A15. Try it. On my own PC the C version runs OK, but the QBasic
program seems to have problems; perhaps the way I time the programming
signals is being interfered with by Windows somehow.
Q16. Is that all?
A16. I hope so.
=== Cut ===
Antony@apdr.msk.ru
--- GoldED 2.50.Beta4+
* Origin: 28800 AD Micro BBS, Worktime: CM (095)-162-8405 (2:5020/49.2)