[Top][All Lists]

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

Re: [avr-gcc-list] External EEPROM verses internal EEPROM data handling

From: David Kelly
Subject: Re: [avr-gcc-list] External EEPROM verses internal EEPROM data handling
Date: Mon, 4 May 2009 14:13:15 -0500
User-agent: Mutt/

On Mon, May 04, 2009 at 11:46:40AM -0700, Steven Michalske wrote:
> On May 4, 2009, at 11:33 AM, David Kelly wrote:
> >
> >IIRC the compiler doesn't know internal AVR EEPROM either. AVR
> >EEPROM is not mapped in CPU address space but it faked into the load
> >map for debugging and device programming.
> >
> Good catch Dave,  avr libc  has macros for accessing the AVR eeprom.
> Look at http://www.nongnu.org/avr-libc/user-manual/group__avr__eeprom.html 
>   for insperation on writing your own macros.
> You can add another section to your linker script for the external
> eeprom if you wanted to as well.

Did that on a project some time ago. The advantage is to initialize the
EEPROM at device programming time. You can get "addresses" off your
structures initialized in the EEPROM but have to use them as offsets
when using EEPROM routines rather than as pointers into RAM or FLASH.

Other than the ability to initialize EEPROM with an AVR programming tool
there isn't much difference in use of internal vs external EEPROM.

The OP might consider writing to FLASH for his data logger assignment.
Is harder to use as one must write bigger blocks at a time. Might be a
wear limit depending on how many write/erase cycles are needed.

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]