piclist 1997\08\11\114405a >
Thread: Re: *.COD file format why I want it
www.piclist.com/techref/microchip/devices.htm?key=pic
picon face BY : John Payson email (remove spam text)



>>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?
<199708111511.KAA19164@Mars.mcs.net>

In reply to: <Pine.GSO.3.96.970811070201.27790B-100000@winc0> from "Fred Thompson" at Aug 11, 97 07:05:56 am
See also: www.piclist.com/techref/microchip/devices.htm?key=pic
Reply You must be a member of the piclist mailing list (not only a www.piclist.com member) to post to the piclist. This form requires JavaScript and a browser/email client that can handle form mailto: posts.
Subject (change) Re: *.COD file format why I want it

month overview.

new search...