Skip to content

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

Closed
hasenbanck opened this issue Aug 9, 2018 · 2 comments
Closed

Buffered read / writes for the EEPROM emulation #296

hasenbanck opened this issue Aug 9, 2018 · 2 comments

Comments

@hasenbanck
Copy link
Contributor

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:

void eeprom_buffer_fill();
void eeprom_buffer_flush();
uint8_t eeprom_buffered_read_byte(const uint16_t __p);
void eeprom_buffered_write_byte(uint16_t __p, uint8_t __value);

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?

@fpistm
Copy link
Member

fpistm commented Aug 9, 2018

The EEPROM is not really optimized.
This feature is mainly to provide easiest way to save/restore some user settings which don't required high data rate and access else a real storage (SD,...) should be used.
Anyway, your suggestions seems a good improvement.

@hasenbanck
Copy link
Contributor Author

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.

fpistm pushed a commit to fpistm/Arduino_Core_STM32 that referenced this issue Sep 8, 2018
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>
fpistm pushed a commit to fpistm/Arduino_Core_STM32 that referenced this issue Sep 10, 2018
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>
fpistm pushed a commit to fpistm/Arduino_Core_STM32 that referenced this issue Sep 15, 2018
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>
@fpistm fpistm closed this as completed in e9dbcd3 Sep 21, 2018
xC0000005 pushed a commit to xC0000005/Arduino_Core_STM32 that referenced this issue Nov 27, 2018
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>
benwaffle pushed a commit to benwaffle/Arduino_Core_STM32 that referenced this issue Apr 10, 2019
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants