-
Notifications
You must be signed in to change notification settings - Fork 1k
Rework eeprom emulation for buffered access #302
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The current eeprom emulation didn't had any buffered access to the data on the flash. Every access to a byte would trigger a whole page read / write. For writes it would mean, that the whole page would be erased. For backward compability we will keep the current functions as they are, but will add functions to fill/flush the buffer and read from it. The buffer size is static and is one page in size. This commit also cleans up old unused code comments and documentation stubs. I also cleaned up the old references to the original author / version / date, since we already refactored this code quite well. The copyright notice of course is still intact. Fixes: #296
Thanks @hasenbanck |
@fpistm Are you back from your vacation? Could my work be merged sooner or later? |
Hi @hasenbanck |
@hasenbanck I've reviewed the code and it looks fine. |
Maybe an example using the new api could be added. |
Were would you like to have an example for the C API? Maybe in the STM32Example repository? We could of course rework the EEPROM class to support this buffering, but for now I would separate it from this pull request (or your branch of it). |
Yes STM32Example is a good candidate. |
[#302 review]Rework eeprom emulation for buffered access
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed in #333
#333 merged |
[stm32duino#302 review]Rework eeprom emulation for buffered access
The current eeprom emulation didn't had any buffered access to the
data on the flash. Every access to a byte would trigger a whole
page read / write. For writes it would mean, that the whole page
would be erased. For backward compatibility we will keep
the current functions as they are, but will add functions
to fill/flush the buffer and read from it.
The buffer size is static and is one page in size.
This commit also cleans up old unused code comments and
documentation stubs. I also cleaned up the old references
to the original author / version / date, since we already
refactored this code quite well. The copyright notice of
course is still intact.
@fpistm If I reworked too much from the file, then I can of course pull back the RC and just change the affected parts, but I thought it would be best if I clean up the code while working on it anyhow.
Fixes: #296