Closed aaron-neal closed 1 year ago
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
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.
I guess supporting SAMD NVM as an EEPROM is not planned for the same reason? https://github.com/nerdyscout/ArduinoStreamUtils/tree/SAMD
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.
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?