Replies: 2 comments 1 reply
-
For me it is covered by #333 IIWR Writing to flash one or more bytes required to write full page. |
Beta Was this translation helpful? Give feedback.
0 replies
-
I see, so your proposal is to use |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Is your feature request/improvement related to a problem? Please describe.
According to the source code,
EEPROM.write
assigns value to EERef:(EERef(idx)) = val;
.This calls
EERef::operator=
which in turn callseeprom_write_byte
.On devices without actual EEPROM, it calls
eeprom_buffered_write_byte
andeeprom_buffer_flush
which erases and rewrites the whole page of flash leading to excessive wear.Describe the solution you'd like
I like the approach taken in the alternative implementation: https://github.com/rogerclarkmelbourne/Arduino_STM32/tree/master/STM32F1/libraries/EEPROM
Not only it erases the flash page only when needed, it avoids the buffer in RAM by writing half words directly to the free space on the flash page. The new variable value is written to the free space, not overwriting its previous value, thus avoiding the need for flash page erase.
On another hand, that implementation writes a header for each stored variable, halving the available space, whereas this implementation just gives access to the raw contents of the flash page.
Maybe it's possible to add a pair of function like
disableAutoFlush
andenableAutoFlush
, documenting that each flush causes flash page erase cycle?Or should I use
eeprom_buffered_write_byte
andeeprom_buffer_flush
directly? ThenEEPROMClass
is not very much usable with respect to writing data - as I said, each byte change will cause flash page erase.Beta Was this translation helpful? Give feedback.
All reactions