[avr-libc-commit] [2258] In faq_eeprom_corruption: Remove the remarks about the EEPROM being

[Joerg Wunsch]

Revision: 2258
          http://svn.sv.gnu.org/viewvc/?view=rev&root=avr-libc&revision=2258
Author:   joerg_wunsch
Date:     2011-10-13 07:05:03 +0000 (Thu, 13 Oct 2011)
Log Message:
-----------
In faq_eeprom_corruption: Remove the remarks about the EEPROM being
erased pagewise, as they are not true.

Modified Paths:
--------------
    trunk/avr-libc/ChangeLog
    trunk/avr-libc/doc/api/faq.dox

Modified: trunk/avr-libc/ChangeLog
===================================================================
--- trunk/avr-libc/ChangeLog    2011-09-26 16:59:36 UTC (rev 2257)
+++ trunk/avr-libc/ChangeLog    2011-10-13 07:05:03 UTC (rev 2258)
@@ -1,3 +1,8 @@
+2011-10-13  Joerg Wunsch <address@hidden>
+
+       * doc/api/faq.dox (faq_eeprom_corruption): Remove the remarks about
+       the EEPROM being erased pagewise, as they are not true.
+
 2011-09-26  Eric B. Weddington <address@hidden>
 
        Partial fix for bug #32945.

Modified: trunk/avr-libc/doc/api/faq.dox
===================================================================
--- trunk/avr-libc/doc/api/faq.dox      2011-09-26 16:59:36 UTC (rev 2257)
+++ trunk/avr-libc/doc/api/faq.dox      2011-10-13 07:05:03 UTC (rev 2258)
@@ -1637,20 +1637,7 @@
 EEPROM actually needs to be written, so not to cause unnecessary EEPROM
 wear.
 
-AVRs use a paging mechanism for doing EEPROM writes.  This is almost
-entirely transparent to the user with one exception: When a byte is
-written to the EEPROM, the entire EEPROM page is also transparently
-erased and (re)written, which will cause wear to bytes that the
-programmer did not explicitly write.  If it is desired to extend
-EEPROM write lifetimes, in an attempt not to exceed the datasheet
-EEPROM write endurance specification for a given byte, then writes
-must be in multiples of the EEPROM page size, and not sequential
-bytes.  The EEPROM write page size varies with the device.  The EEPROM
-page size is found in the datasheet section on Memory Programming,
-generally before the Electrical Specifications near the end of the
-datasheet.
-
-The failure mechanism for an overwritten byte/page is generally one of
+The failure mechanism for an overwritten byte is generally one of
 "stuck" bits, i. e. a bit will stay at a one or zero state regardless of
 the byte written.  Also a write followed by a read may return the
 correct data, but the data will change with the passage of time, due