[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: |
Parthasaradhi Nayani |
Subject: |
Re: [avr-gcc-list] Storing variables in external memory - suggestions |
Date: |
Fri, 22 May 2009 07:38:36 -0700 (PDT) |
--- On Fri, 5/22/09, David Kelly <address@hidden> wrote:
> 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):
>
> LDFLAGS+=--section-start=.eeprom=00a10000
>
>
> 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):
>
> object_eeext.hex:
>
>
> Finally, believe it goes without saying that you have to
> provide
> routines to access your external EEPROM device.
Hello David Kelly,
Thanks a lot for the suggestions. Yes, I understand that initializing the
variables will not actually save the vales into the memory locations. I will
try a sample code and revert. Thanks once again.
B Regards
Nayani P