Michael Clift wrote:
Thanks for all the responses guys, some interesting ideas.
I don't really want to put all of my EEPROM data into one structure,
as I have many eeprom variables with initializers distributed across
a number of files.
What I ended up doing, was to change the .eep output format to
binary, then I copied this to an object file as described here
http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_binarydata
I then linked this object into my main code. It works a treat, only I
have to build my code twice to get the initial values updated to
flash, once to create .eep, and again to link in the object.
When you do this, are you 100% sure that the addresses of the eeprom
variables don't change? You have no guarantees about this, unless you
work very hard with segment names and linker files. Far and away the
safest and most reliable method is to put your eeprom data within a
single defined structure. It is better to have to restructure your
program a bit at this stage, than to stick with your scattered data
approach and have weird bugs later when the order of data in the final
build does not match that of .eep file build. It also makes it far
easier to put it in a single build without using external utilities.
A poor but workable substitute would be to build in a check in your
build process that confirms that that your linked .eep file matches
the .eep file generated in the final build. You'll still get problems
if you ever want to update the software in a system without reseting
the eeprom to the flash defaults.
The main reason for doing this, is that I have a boot loader that I
want our clients to be able to use, only the boot loader does not
support eeprom loading. It also saves me having to program the eeprom
in production.
Regards, Michael.
_______________________________________________
AVR-GCC-list mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list