| ??? 07/23/08 14:03 Read: times |
#156978 - Larger EEPROM = simple code Responding to: ???'s previous message |
Yes, that is an example of selecting a larger EEPROM to allow the use of a trivial algorithm for spreading the writes.
Most of the time, it is cheaper to go for such a solution. Only when very, very large volumes of units are sent out will it be meaningful to instead implement clever algorithms that uses all of the EEPROM at the same time, and instead regularly rotates the contents. The data rotation code is error-prone and hard to test and must also be robust enough that a power-failure in the middle can be correctly handled. If producing in k volumes, simplicity is to be recommended. If producing in the millions, then the company can afford the extra development time and the very, very expensive testing needed for a "clever" solution. The important thing is that the EEPROM - and the code that uses it - must not be made the weakest link. Or in some cases several orders of magnitude weaker than the rest of the solution. |
| 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 |