STM32 Buffered EEPROM

[aaron-neal]

I found the eeprom write slow, which was a known fact due to the EEPROM emulation in the official STM32 core.
I have found using the buffered write and flush methods resolves this problem.
I am not intending this to be the final solution, as my tests have been succesful but minimul in nature.

Happy to help to get this merged if you feel it is helpful for others.

I haven't found the read an issue, maybe eeprom_buffered_read_byte should be used as well?

[bblanchon]

Hi @porkyneal,

Thank you for this PR.
However, I want to reduce platform-specific code in this library, and this change is very specific.
Moreover, you can achieve the same result with a BufferedStream:

EepromStream eepromStream{0, 1024};
BufferedStream bufferedEepromStream{eepromStream, 32};

After all, that's the purpose of this library: augment existing streams with decorators.

Best regards,
Benoit

[aaron-neal]

Thanks @bblanchon I will give this a go and I appreciate wanting to keep it platform agnostic. It is the reason I am here, this helps me keep configuration code the same between ESP32 targets and STM32 ones.

I am not clear how the example helps as the stm32 core underlying non buffered eeprom write is highly ineffective as it updates an entire page for every single byte written. That's why the bufered functions exist in the core. See the commit here

But I may be missing something, will report back at some point.

[nerdyscout]

I guess supporting SAMD NVM as an EEPROM is not planned for the same reason?
https://github.com/nerdyscout/ArduinoStreamUtils/tree/SAMD

[bblanchon]

Indeed, @nerdyscout, the change you suggest relies on a third-party library; I restrict myself to built-in libraries to avoid making maintenance a nightmare.
For example, in your fork, you assume that all SAMD users have FlashStorage_SAMD installed, which will cause a compilation error for most users.