[Top][All Lists]

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

Re: [avr-gcc-list] Storing variables in external memory - suggestions

From: David Kelly
Subject: Re: [avr-gcc-list] Storing variables in external memory - suggestions
Date: Fri, 22 May 2009 08:48:41 -0500
User-agent: Mutt/

On Fri, May 22, 2009 at 05:35:43AM -0700, Parthasaradhi Nayani wrote:
> Hello all,
> I was wondering if any one can suggest a decent method of
> automatically assigning address space to variables in external EEPROM.
> For internal EEPROM the attribute EEMEM will allocate addresses in
> sequence. One can insert or delete a variable and the address space
> gets adjusted properly. Is there a method of doing something similar
> for external EEPROM. I have an external EEPROM where I would like to
> store and retrieve variables. Thanks in advance for your suggestions.

All EEMEM does is this in eeprom.h:

#define EEMEM __attribute__((section(".eeprom")))

AVR Studio convention is that internal .eeprom starts at 0x00810000. So
what I'd do if I were you and wanted the compiler to assign static
memory addresses in an external eeprom would be:

#define EEEXT __attribute__((section(".eeexternal")))

Then in my Makefile (or somewhere in AVR Studio) would add this to the
linker definitions (am not certain 0x00a10000 is available):


If you put initialized definitions in EEEXT they will be lost. Your
code has to write them in the external device because neither the
compiler nor AVR Studio knows how. You can add a rule to the Makefile
(if you are using make) to write a hex file containing your external
EEPROM initial values:

%_eeext.hex: %.elf
        avr-objcopy -j .eeexternal --change-section-lma .eeexternal=0 -O ihex 
$< $@

Then you need a target such as this which will invoke the above rule
(think it needs a blank line after):


Finally, believe it goes without saying that you have to provide
routines to access your external EEPROM device.

David Kelly N4HHE, address@hidden
Whom computers would destroy, they must first drive mad.

reply via email to

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