Searching \ for '[PIC] Re: *.COD file format why I want it' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Re: *.COD file format why I want it'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Re: *.COD file format why I want it'
1997\08\10@125556 by Fred Thompson

flavicon
face
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.

{Quote hidden}

       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.

{Quote hidden}

       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.

1997\08\10@143439 by John Payson

picon face
>         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.

While simulation, etc. might benefit from #LastLine, I think it's better to
look at the hex file to see what locations need burning.  For the 14-bit
parts, I find it easy to simply fill my buffer with $FFFF [not a valid code]
and then use one of four modes when processing those addresses:

[1] Don't blank-check that address; simply ignore it.

[2] Blank-check it and require it to be blank.

[3] Unconditionally program a zero there.

[4] Blank-check it; if blank or zero, leave alone; otherwise burn all zeroes.

Given that $3FFF at the start of a program is essentially a do-nothing opcode,
using option #4 makes overburning (i.e. using excess code-space in the chip
to hold multiple versions of the code without having to erase) much easier.
For example, if my program is 512 bytes or less and I'm programming a 16C622
(2K), then I burn my first program at address zero.  If that doesn't work, I
modify my code, change the start address to $200, and burn again (same chip,
no erase).  Then $400, then $600.  If I'm using interrupts, things get a
little bit harder (but not too much): on the first burn, $000 is a jump to
start of code, $004 is a jump to start of interrupt, and the rest of the code
starts at address $008.  On the second burn, $001, $005, and $208.  Etc.

For the 16-bit parts, the $FFFF-as-flag-value technique doesn't work (though
CALL $1FFF is an unlikely instruction, $FFFF could be part of a data table).
Consequently, I had to make my hex-loader take note of the last byte loaded,
but this wasn't too hard (actually, I may subdivide memory into 16-byte chunks
and make the loader set the flag for every chunk that's used.  If any code
has gaps in the middle this should speed up programming a bit).  Has anyone
else used techniques like this in burners?  I've found them to be quite help-
ful at times.

1997\08\11@080745 by Fred Thompson

flavicon
face
> Given that $3FFF at the start of a program is essentially a do-nothing opcode,
> using option #4 makes overburning (i.e. using excess code-space in the chip
> to hold multiple versions of the code without having to erase) much easier.
> For example, if my program is 512 bytes or less and I'm programming a 16C622
> (2K), then I burn my first program at address zero.  If that doesn't work, I
> modify my code, change the start address to $200, and burn again (same chip,
> no erase).  Then $400, then $600.  If I'm using interrupts, things get a
> little bit harder (but not too much): on the first burn, $000 is a jump to
> start of code, $004 is a jump to start of interrupt, and the rest of the code
> starts at address $008.  On the second burn, $001, $005, and $208.  Etc.

       Thats a good idea!  I'm just writing short test programs right now
and this trick would save a great deal on erasing.  I'm not clear on why
the HEX file is a benefit here unless you take advantage of its text
nature and modify your hex code before running the programmer.  I should
probably add a "Modify Data" feature to my programmer as this would be
easy.

{Quote hidden}

       I'm not yet into 16 bit parts.  I'm sure the day will come.

Thanks for the tips
Fred
spam_OUTfthompsoTakeThisOuTspammail.win.org

1997\08\11@114405 by John Payson

picon face
>>Given that $3FFF at the start of a program is essentially a do-nothing op
>>using option #4 makes overburning (i.e. using excess code-space in the chip
>>to hold multiple versions of the code without having to erase) much easier.
>>For example, if my program is 512 bytes or less and I'm programming a 16C622
>>(2K), then I burn my first program at address zero.  If that doesn't work, I
>>modify my code, change the start address to $200, and burn again (same chip,
>>no erase).  Then $400, then $600.  If I'm using interrupts, things get a
>>little bit harder (but not too much): on the first burn, $000 is a jump to
>>start of code, $004 is a jump to start of interrupt, and the rest of the
>>code starts at address $008.  On the second burn, $001, $005, and $208. Etc.
>
>         Thats a good idea!  I'm just writing short test programs right now
> and this trick would save a great deal on erasing.  I'm not clear on why
> the HEX file is a benefit here unless you take advantage of its text
> nature and modify your hex code before running the programmer.  I should
> probably add a "Modify Data" feature to my programmer as this would be
> easy.

I use the .hex files because I understand them, I had code lying around from
another application, they're universal, and THEY WORK JUST FINE.  Perhaps a
.COD file would work better, but I can't see any "problem" with .HEX that it
would fix (for emulation, that would be a different story of course).

Personally, I'm waiting for the day when someone adds the following features
to compilers/assemblers:

[1] The ability to take information about starting address, etc. from a file
   that would be updated (by the burner) whenever a chip was burned, thereby
   automating the overburn process (perhaps it could use an old copy of the
   .HEX/.COD files to find out exactly what needed to be overburned and what
   routines could be left as-is.  The .COD could be *extremely* helpful for
   that.

[2] A "#strike"/"#endstrike" directive which would cause the compiler/assembler
   to emit NOPs instead of the struck code.  When striking out moderately long
   routines, it's a pain having to insert precisely the right number of NOPs
   to make everything else line up.  An automated directive could simplify
   this.

Anyone else like these ideas?

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