-
Notifications
You must be signed in to change notification settings - Fork 1k
Buffered read / writes for the EEPROM emulation #296
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
Comments
The EEPROM is not really optimized. |
Since I'm currently adapting Marlin for your core, this problems popped up. Currently Marlin would safe the configuration (around 600 bytes) one byte at a time and would use 600 erase cycles of the whole page just for one save operation. I implemented the usage of the Backup SRAM as an alternative, but I want to correct the current default operation mode non the less. I will open a PR once I finished and tested the implementation. |
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. Fixes: stm32duino#296 Signed-off-by: Nils Hasenbanck <nils.hasenbanck@trendig.com>
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. Fixes: stm32duino#296 Signed-off-by: Nils Hasenbanck <nils.hasenbanck@trendig.com>
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. Fixes: stm32duino#296 Signed-off-by: Nils Hasenbanck <nils.hasenbanck@trendig.com>
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. Fixes: stm32duino#296 Signed-off-by: Nils Hasenbanck <nils.hasenbanck@trendig.com>
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. Fixes: stm32duino#296 Signed-off-by: Nils Hasenbanck <nils.hasenbanck@trendig.com>
Right now the EEPROM emulation inside the core (stm32_eeprom.c/h) provides two functions for reading and writing to an EEPROM emulated via flash (size of a page).
Both functions are touching the whole page in each function call, which is especially wasteful when writing to the flash.
To stay backward-compatible, I would propose to add four new functions to the core library:
The developer would then to first fill the static, private buffer with the fill function, interact with it and when he wants to save the content of the buffer to flash, flush the buffer to flash.
Implementing these changes shouldn't take much effort, since all pieces are already in place. I would like to do the implementation.
Comments? Suggestions?
The text was updated successfully, but these errors were encountered: