Re: [avr-gcc-list] Re: Larger than 64K memory sections

[Tero Sinervo]

David Brown wrote:
> It does not matter what addresses are used for ram variables, nor for 
> the flash code that is updated.  But very often it /does/ matter for 
> persistent data, and it is certainly important for pre-defined memory 
> maps such as for external peripherals (there is a good reason why 
> internal peripherals are not defined in a file with lines like "volatile 
> uint8_t PORTD" !).  The only way to be entirely sure that an object is 
> allocated to the same address each time is for it to be the only thing 
> in a section, and the section is given an explicit address at link time. 
>  When you are talking about data that can't be addressed directly in C 
> on the AVR anyway, why bother with that?

Yes, very often but not always. Consider having text strings in pgmspace 
but running out of space. Good thing you have a mass storage and file 
system - you can move the text strings to an external section and load 
the section to a file. Only thing you need to do is write a driver that 
replaces pgmspace string stuff with file access. It doesn't matter in 
which order the strings are in the file.


> Note that you /can/ (and should) get the compiler to do most of the 
> effort in the allocation.  The easiest way is to make a struct type for 
> all your eeprom data:
>
>     typedef struct { uint16_t moneyLeft; uint16_t runTimeSeconds; }
>     eepromData;
>
> Then you can access this data with something like:
>
>     eeprom_read_word((uint16_t*) (baseAddress +
>             offsetof(eepromData, runTimeSeconds)));
>
> You manually specify a base address, and let the compiler handle the rest.

This is all all right although perhaps offsetof is redundant:

eepromData* eeprom = BASEADDRESS;
eeprom_read_word(&eeprom->runTimeSeconds);


--
Tero Sinervo