>Hmmm.... by "map file" do you mean the .LST file?  Taking
>one of my apps/code as an example, the .LST file shows:
>        Program memory words used: 599
>        Program memory words free: 1449
>
>Neat.  These even add up to 2048, so it sounds plausible,
>but how come the .HEX file size is 3418 bytes?  From
>archive posts, I gathered that the .HEX file is a little over
>twice the actual code size, so I'd expect the .HEX file to be
>about 1200-1300, maybe even 1400-1500 bytes.  Why does
>it come up with 3418 ('ls -al').
>
>There's gotta be a logical answer here somewhere.  If the
>real answer is that the .HEX file is many times the size of the
>code, and the .LST file shows the correct code size, I would
>be most ecstatic to save the utility coding time.

Well there is the code, plus the overhead (I believe this will be 2 char for
checksum, 2 char record type, 4 char address, 1 char (:) record start, 2
char EOL, that's 11 char overhead per 16 bytes of code) plus there will be a
complete record for the configuration word.

Now on the basis of the figures you quote, 599 words used will be 599*2
bytes, or 599*4 characters, which will be (599*2)/16 records which is 74.8
records, which will translate to 75 records.

Each record will have 32 characters for the bytes, plus 11 for the overhead,
which is 43 characters. There are 75 records, so 75*43 = 3225 characters,
plus another record of 11+4 characters for the configuration record, plus an
EOF record which will be another 11 char. so the total would look to be 3225
+ 15 + 11 = 3251 characters, which is still 167 less than your ls gets. I am
going on memory of the Intel hex string, so it looks like I am 2 char per
record short in my memory :)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads