[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Tero Sinervo
Subject: Re: [avr-gcc-list] Re: Larger than 64K memory sections
Date: Thu, 27 Aug 2009 15:36:35 +0300
User-agent: Thunderbird (Windows/20090812)

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; }

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;

Tero Sinervo

reply via email to

[Prev in Thread] Current Thread [Next in Thread]