Deleting EEPROM
Tinker
Posts: 12
Hi - I'm using the 24FC512 EEPROM for datalogging apps. My first attempt to 'delete' (write $FF to all of the cells) one EEPROM took about 45 minutes. The code was brute force. I placed "I2COUT 0, $A0, hibyte\lobyte [noparse][[/noparse]$FF] " in a loop and sat back. If waiting this long is one of those "facts of life" I'll just live with it.
I suppose I could look for the first $FF using a read before each write and stop when I detect one. Does I2COUT support page writing?
On the other hand can you avoid deleting entirely and define another byte, say $00, as an end-of-file, and download data until you reach a $00? Then any old data that exists past that point wouldn't be read. You would have to be careful not to write either a $FF or a $00 as data values. Has anyone had experience with this problem? Tnx
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
.
I suppose I could look for the first $FF using a read before each write and stop when I detect one. Does I2COUT support page writing?
On the other hand can you avoid deleting entirely and define another byte, say $00, as an end-of-file, and download data until you reach a $00? Then any old data that exists past that point wouldn't be read. You would have to be careful not to write either a $FF or a $00 as data values. Has anyone had experience with this problem? Tnx
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
.
Comments
I2COUT 0, $A0, hibyte\lobyte [noparse][[/noparse]REP $FF\64]
The REP modifier repeats the $FF 64 times. That will be 64 times faster, because the delay for write is the same whether you do a single byte or a whole page.
It can be totally faster if you don't have to erase the EEPROM at all. Instead, hold your address pointer in non-volitile RAM (battery backed clock chip), as well as a pointer to the start of the data file, too, if you use one. Erasing the file is then simply a matter of moving the pointers to the same value.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com