[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [avr-gcc-list] Binary image length
From: |
Eric Weddington |
Subject: |
RE: [avr-gcc-list] Binary image length |
Date: |
Tue, 21 Nov 2006 16:38:57 -0700 |
> -----Original Message-----
> From:
> address@hidden
> [mailto:address@hidden
> org] On Behalf Of Shaun Jackman
> Sent: Tuesday, November 21, 2006 4:30 PM
> To: address@hidden
> Subject: [avr-gcc-list] Binary image length
>
> What's the best approach to place the length of a binary firmware
> image in the image itself at a constant location in the image? If
> possible, I'd like to avoid using a linker script. I suppose the ideal
> location for the firmware length would be immediately following the
> interrupt vector table. On my ATMEGA64, this address appears to be
> 0x8c. I've noticed that the progmem section is placed at this
> location. So, I suppose one solution would be to place as the first
> declaration in the first file specified on the command line link
> order:
>
> extern char __data_load_end;
> const prog_uint16_t image_size = (uint16_t)&__data_load_end;
>
> Checking just now, this approach seems to work. Any better
> suggestions?
Hi Shaun,
There are two different parts here:
- The location of the data (length of firmware image)
- And generating the data itself
Another suggestion for the location of the data is at a high address, to
avoid your application code altogether. You may not want to put the data in
the Boot flash area, in case you use a bootloader, but perhaps the address
right before your lowest possible bootloader address. Remember the Boot
flash area size is settable via a fuse.
Another method for generating the data is to use the Srecord utilities:
<http://sourceforge.net/projects/srecord>
The Srecord utilities can manipulate load files, including in the Intel hex
format. So with some scripting trickery you can post-process your hex file
to calculate and insert the data actually in the hex file.
HTH
Eric Weddington