Tamas Rudnai wrote:
> I thought the best for time critical app is to have a shadow RAM for the
> EEPROM so that when you read data you do not need to access to the EEPROM
> and then when you write data you just put the new data to the place and
> indicate somewhere (in a bitfield for example) that the place had been
> changed. Next time when an interrupt occurs you can check whenever the
> shadow had been changed and you can write the changed bytes into the EEPROM
> -- when finished a new interrupt will be triggered..and so on. The only
> problem is how to start the writing mechanism -- so that if there is no any
> data waiting to be written already, you have to start the whole manually
> (with an initial write) or do some tricks when timer or other interrupts
> occur making sure not interfering with the EEIF.
>
> Tamas
>
>   
>   
Just a comment or two. Using a shadow ram is fine, but sometimes, due to 
ESD or whatever, the shadow
ram might get corrupted, and could cause a disaster.

What I have found is that if you use a shadow, you need to re-read the 
shadow ram whenever a checksum
fails to match, in additione to changes in EPROM that are needed.

But there is a more serious problem, at least with recent PICs (nanowatt 
series)- the EEPROM data itself drops
bits at random with usage. Microchip recommends a "refresh cycle", but 
their strategy does not include any correction.
I have adopted a "best 2 of 3" or "best 3 of 5" algorithm whenever the 
data is critical to make the EEPROM work as
well as it did before (compared to PIC16CExxx EEPROM devices). The way 
it works is that all 3 are read, and if all
match, the variable is used; but if even ONE fails to match, then all 3 
are rewritten. Unfortunately, the algorithm is lengthy
code-wise.


--Bob
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist