add eeprom_flush() in _conf_save(...) functions for nrf52-boards without eeprom

[nilu96]

Config changes were not saved properly without eeprom_flush() because nRF52 boards without real EEPROM use a file-backed EEPROM emulation that is only flushed after multiple byte writes. So a change of a single byte will not be written. This is the same procedure as already implemented in bt_conf_save() for example.

[drupol]

There has been some changes in commit 98072da when it comes to writing, especially for nrf52 boards. Can you check if this PR is still valid ?

[nilu96]

Thanks for checking! I think the PR is still valid. The changes in that commit deal specifically with overriding the standard library's ⁠_write⁠ stub (using ⁠__wrap__write⁠ for the nRF52) to redirect ⁠stdout⁠ and ⁠printf()⁠ console logs into KISS frames.

Because ⁠_write⁠ should only handle the standard output stream and does not interact with memory storage, it is completely separate from the EEPROM write logic. Therefore, the EEPROM fixes in this PR are unaffected and still valid.

[attermann]

Thanks for bringing this to my attention. I remember this issue from long ago and thought it had been resolved, but apparently that's not the case.
Do you recall why nRF2 "eeprom" flushing only occurs after 8 bytes? I assume it's to reduce flash wear, but 8 bytes seems rather random.
I just want to be sure that this 1-byte flushing is a relatively rare event and not in some potentially busy path that could lead to unnecessary flash wear.
An alternative approach would be to flush on a timer or prior to soft-reset, but that has it's edge cases too and may be overkill for the realistic frequency that this will happen.

[nilu96]

Hi attermann,
I have absolutely no idea where the 8 byte rule comes from. As far as I know, RNode uses EEPROM only for storing configuration, but I am not sure about that. Since configuration changes should be rare events, these 1 byte writes hopefully aren’t a problem.

But I did not trace back the function calls to track how often the eeprom is written.

[attermann]

I tend to agree that extra writing on eeprom changes will be rare relative to all of the other writes being done to flash. I'll merge this and we can re-visit later if this assumption changes.