Yahoo Groups archive

AVR-Chat

Index last updated: 2026-04-28 22:41 UTC

Message

Re: [AVR-Chat] need variables to be stored in EEPROM

2005-04-25 by Philipp Adelt

Hi Tony,

arhodes19044 schrieb:
> I see in the docs how to use the registers to access the EEPROM on 
> my ATmega128.
> 
> However, Which part of it is allowed to be used?  Is there nothing 
> in it unless I use it myself?

This is correct, you can use each and every byte. There have been 
rumours that the first types of AVR had a problem with "random" 
corruption of the very first EEPROM cell at address 0. Most people tell 
that Atmel has fixed the problem in newer (mega) devices. Others say 
that due to the improved startup behavior of newer device types 
(including the advent of the brown-out detector) bad user design is less 
likely to lead to execution of random commands that could lead to 
corruption of address 0. (Remember that in a brown-out condition, an AVR 
can easily execute >10million errors per second..)

> Does GCC-avr give me tools to allocate variables in eeprom 
> automatically?  Should I use MALLOC in some manner?  I see some 
> basic tools in libc to access EEPROM at a very low level.  Are there 
> some higher level access routines?

AFAIK, the avr-libc routines in avr/eeprom.h are as good as it gets. You 
could write your own macros of course. Remember to respect the timed 
write requirements from the data sheet (or the avr-libc routines). This 
includes disabling interrupts or a scheme to re-try writing if you can't 
afford turning them off.
Malloc won't be your friend, it will allocate you a heap chunk of SRAM.

> I only have a few variables of various sizes to save, but I may want 
> to use the rest as a data-logging function, in some sort of circular 
> buffer.  The circular buffer would be accessed as a big array 
> structure, probably.

The easy way is to put all your EEPROM variables into a struct, hold an 
instance of that struct in SRAM and save the entire sizeof(struct) bytes 
into the EEPROM as a block (avr-libc has a nice function for that). If 
SRAM is so tight that you can't afford holding a copy of the data in it, 
this won't help.

Philipp

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.