Re: [avr-chat] ?Optimized eeprom?

[David Brown]

> On Thursday 15 June 2006 06:59, Steve Franks wrote:
> > 'Evening.
> >
> > It would seem that changing from -O0 to -Os removes all unreferenced
> > entires from my eeprom.hex file.  Failing that it still moves things
around
> > even if no unrefereced vars.  Not good when you are sticking things in
> > places that are not explicitly defined and using several firmware revs..
> > Some questions come to mind:
> >
> > 1) Did I just forget to add something to the makefile to keep the
> > optimization settings from mucking with the eeprom?
> >
> > 2) Beyond using '__attribute__((section (".eeprom")))', or just
hardcoding
> > an adress, is there a cleaner way to specify, "I want X in the eeprom at
> > location Y, refering to it in the code by name Z"?
>
> For the optimization issue, you could try __attribute__((used)) . This way
you
> tell the compiler to assume that the variable is used even if it actually
> isn't.
>

That won't necessarily work - the linker could still remove it.  In fact, I
believe that the compiler can still remove the variable if it finds that you
don't actually use it (for example, if you've declared it "static", or used
"whole-program" compilation) - the attribute simply tells the compiler not
to warn you that it's unused.

And even if you persuade the compiler to leave the variable in place, there
is no reason to assume that it has a specific address - the compiler and
linker can freely re-arrange the ordering of the data, even if they are
declared within the one file.

The only reliable, repeatable and maintainable (i.e., without manually
specifying each address) way to get consistent addresses is to put all your
eeprom data into a single struct.  It's best to make sure that any padding
involved is explicit (using the "-wpadded" warning).