Encouraging people to store what might be large amounts of data one byte at a time will wear out the EEPROM rather fast won't it?
Nope. The EEPROM on AVR processors is byte-wise. One byte at a time in. One byte at a time out. If a byte wears out the neighbors are not affected.
4 bytes according to page 299 of the datasheet, or have I misunderstood it?
And I've checked the source for the arduino EEPROM library, and it only wraps the eeprom_write_byte / read functions...
However it would appear from the reference to 4 byte pages, that you are only "wearing out" a block of 4 bytes by writing to EEPROM.
Quote from: Coding Badly on May 29, 2012, 11:31 pmNope. The EEPROM on AVR processors is byte-wise. One byte at a time in. One byte at a time out. If a byte wears out the neighbors are not affected.4 bytes according to page 299 of the datasheet, or have I misunderstood it?
Interesting, the page size does seem to be 4 bytes. Possibly this is why AVR GCC has a write / read word function?
Might be worth digging into the AVR GCC source,
though I have a feeling the EEPROM stuff will be assembly guh.
There are a few folks who have published write-to-death testing. The results are consistently byte-wise failure.
I assume the 4 byte page is to make external programming more efficient.
It is organized as a separate data space, in which single bytes can be read and written.
Please enter a valid email to subscribe
We need to confirm your email address.
To complete the subscription, please click the link in the
email we just sent you.
Thank you for subscribing!
via Egeo 16