| ??? 07/23/08 10:26 Read: times |
#156972 - Socketed EEPROM? Responding to: ???'s previous message |
Producing code that requires the EEPROM to be socketed isn't the right way to go. The price difference between EEPROM sizes is so small (especially contra badwill and repair costs) that a big enough EEPROM can be selected that there are ample cells to rotate the data between.
That gives a choice between writing intelligent - but costly to write/test - code that rotates static and dynamic data around to give even wear, and trivial code that just makes use of a lot of extra memory cells where static data is always stored at fixed locations, but dynamic data splits the writes between all the extra cells. By the way - what does the counter represent? Is it basically some form of uptime counter that is incremented every 7 minutes, or is the events bursty and 7 min is just the expected long-time average? What is the cost of loosing a one or a few updates by holding updates and only perform one write every hour or once/day or similar? |
| Topic | Author | Date |
| incrementing a large number in assembly | 01/01/70 00:00 | |
| Wear and tear | 01/01/70 00:00 | |
| The EEPROM is | 01/01/70 00:00 | |
| F-RAM | 01/01/70 00:00 | |
| F-RAM problem | 01/01/70 00:00 | |
| what's the problem? | 01/01/70 00:00 | |
| found a substitute | 01/01/70 00:00 | |
| first do it in C, then | 01/01/70 00:00 | |
| Load/Save in loop | 01/01/70 00:00 | |
| To Answer Your Question ... | 01/01/70 00:00 | |
| Thanks Russ - slow event | 01/01/70 00:00 | |
| A sample code for your task | 01/01/70 00:00 | |
| Sample code irrelevant | 01/01/70 00:00 | |
| Socketed EEPROM? | 01/01/70 00:00 | |
| walking writes are dead simple | 01/01/70 00:00 | |
| Larger EEPROM = simple code | 01/01/70 00:00 | |
| the counter is | 01/01/70 00:00 | |
| good point | 01/01/70 00:00 | |
Blinkers | 01/01/70 00:00 |