On Sat, 9 Aug 1997, Mike Keitz wrote:

>
> The binary data to program the chip with is also contained in the .HEX
> file, in a very simple format.  For your programmer to be compatible with
> more software, it should (also) be able to use .HEX files which are
> supported by all PIC assemblers/compilers and used by all PIC
> programmers.  There is no certainty that Microchip .COD files will match
> Hitech, will match CCS, etc.
>

        Good point, I could easily modify the portion for reading the
data.  If the input file has the HEX extension it reads HEX.  If it has a
COD extension; well you get the picture.

> It also allows you to alter the data value at one
> >address
> >during program time, if you wish to include a "chip ID" which your
> >program
> >can read.  (If you have several PICs on a serial line and you wish to
> >talk
> >to one of them you would send its ID.  This programming feature allows
> >you
> >to vary that chip number at program time rather than re-assembling.
>
> If you're reading the .COD file, the programmer software would have
> access to the symbols, so one could define a special symbol and label a
> location with it, and the programmer would know to put the ID there.
> Using the hex file the user would need to enter the address of the ID
> location for the programmer.

        I do this.  Before Walter sent me the file format, I had to scan
for a long series of 0000s then switch to a mode to scan for variable
names.  Now that I have the format, I can do this with greater elegance.
        The symbols that I scan for are
#ChipID:   -   marks the address of special chip ID address
#LastLine: -   marks the end of the program (so I only burn the locations
               actually containing code.

The # is the lowest printable ASCII letter that doesn't mean something to
the MPASM assembler.  This helps push the locations to the top of the list
and lowers the time required to scan for them.  These variables set
default values for questions which ask where to modify and where to stop
burning.  The part of my program that modifies the ChipID instruction only
modifies the lower 8 bits and is intended to work with retlw or movlw
instructions.

>
> >As I
> >understand it the PIC program can not read the chip ID numbers that
> >you
> >can program at the ID locations.)
>
> This is true.  The ID locations can only be read when the chip is in
> programming mode.  But it would be a good idea to store a copy of the ID
> value there so someone checking later could find it easily without
> needing to know where it is buried in the program.
>

        I suppose I could do that, but I have not.  I guess all I really
need to figure out is which location would be best to store this value (by
way of a standard), and then just copy it there.  Right now I don't ever
program this space.  I do program the configuration word (my circuits use
crystals and those bits need to be set), but I don't like it.  I've
already blown the write protection bit on a 16C74 and had to buy another.
I can kind of understand why you can't erase that bit, but I can't
understand why you can't blindly program the rest of the chip with a new
program.  Maybe I'm just not trying hard enough.