Yahoo Groups archive

AVR-Chat

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

Message

Re: need variables to be stored in EEPROM

2005-04-25 by arhodes19044

Actually, that struct idea is just perfect.

I definitely was planning on keeping an SRAM version of the 
variables, then only save the requesite info when necessary.

One of these will be a "first-run" flag which will allow 
initialization of the EEPROM, then there are some setting and 
calibration values to keep.  Most of the time I will have time to 
write then verify the data.  Maybe once in a while the writes will 
occur during a time-critical period, so those (what is it? 4ms to 
write?).  I can not turn off interrupts because there is a 1ms clock 
tick interrupt.  Other less important interrupts occur at a MAXIMUM 
frequency of every 1.8ms.  And usually those interrupts will be 
every 45ms or so!

Anyway, I can not disable interupts, but I can verify at the end.

From the code I saw, I would not have thought that interrupting the 
register loading process would be a problem, but maybe it uses that 
TEMP register.  I have not looked at the specific doc for the 128 
yet.  About to, tho.

Thanks for the ideas.

-Tony


--- In AVR-Chat@yahoogroups.com, Philipp Adelt <p.adelt@w...> wrote:
> 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.