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, dke...@hiwaay.net ======================================================================== Whom computers would destroy, they must first drive mad. _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
