GG wrote:
> 
> I'm working on a project where they implemented a data store in EEPROM and a
> copy of it in RAM. The RAM copy is updated all the time and a low priority
> task writes it back to EEPROM.
> There is also a task that eery once in a while copies back from EEPROM to
> it's RAM shadow. I can't understand why someone would want to do that - if
> it is to overcome corruption, isn't it better to reset the system ?
> Otherwise, you can get real messy...
> Can you think of some benefit from this policy?

Not really, no.

I designed and implemented a system that stores configuration data in a
EEPROM.  The EEPROM is read once at reset into a RAM buffer.  All of the
system's read and write accesses are from and to the RAM buffer.  A three
second timer is started any time that the RAM buffer is written and, when
that timer expires, the EEPROM is updated.  This supports a compromise
between wearing out the EEPROM with excessive writes and the desire to
keep the EEPROM up to date.

HTH

-- 
========================================================================
          Michael Kesti            |  "And like, one and one don't make
                                   |   two, one and one make one."
          mkesti@gv.net            |          - The Who, Bargain

GG wrote:

> I'm working on a project where they implemented a data store in
> EEPROM and a copy of it in RAM. The RAM copy is updated all the time
> and a low priority task writes it back to EEPROM.
> There is also a task that eery once in a while copies back from
> EEPROM to it's RAM shadow. I can't understand why someone would want
> to do that - if it is to overcome corruption, isn't it better to
> reset the system ?  Otherwise, you can get real messy...
> Can you think of some benefit from this policy?

are you sure about the copy back to ram? Icould see where once in a
while you would compare ram vs eeprom to be sure everything is still in
working order, but copy?

I'm working on a project where they implemented a data store in EEPROM and a 
copy of it in RAM. The RAM copy is updated all the time and a low priority 
task writes it back to EEPROM.
There is also a task that eery once in a while copies back from EEPROM to 
it's RAM shadow. I can't understand why someone would want to do that - if 
it is to overcome corruption, isn't it better to reset the system ?
Otherwise, you can get real messy...
Can you think of some benefit from this policy?