The subject arose because I wanted to replace at Atmel chip (real EEPROM) with a Chinese STC12C5Axx single-clocker.

A 1k of real EEPROM is very convenient for non-volatile data. Each location may be altered 50-100 times a year. So it is neither once-only nor 'data logger'. Nor is the endurance much of an issue.

The STC chips offer 1k to 28k of 'Flash eeprom' so space is not an issue.

1. maintaining a linear 'array' means a copy-erase-write of a whole 512 byte sector. e.g. 21ms erase + 56ms write (max) if copy is in __XDATA. Almost every time a byte is changed. This is a serious number of sector-erases.

2. maintain a linear 'array'. If the byte is invalid, write a 0 and store the new value in a secondary array. This gives a rapid 'lookup_eeprom(loc)' function involving a maximum two reads. This uses twice the number of sectors, but reduces the need to copy-erase-write dramatically.

3. the linked list or flagged block structure suggested by Erik will also use more sectors. The lookup_eeprom(loc) algorithm could involve a lot of reads in the worst case.

4. A data-logger can generally start from erased sectors, and never overwrites. It suits flash-pages.

My (2) method is fairly complex but it works. I was just surprised at how awkward paged-flash is to manage. And how simple the Atmel eeprom is to use!

Yes. A 24Cxxx eeprom gives byte access and typical 4ms write time. It is an extra chip though.

David.

p.s. Jan, what is the Basic-52 trick?