RNode EEPROM configuration, issue on NRF52

[jacobeva]

Because my NRF52 testbed does not have an EEPROM, the current implementation I use writes the data to flash instead. However, because I do not know when the EEPROM has been finished writing to, I have to close and open the file again to save it at regular intervals, to ensure no data is lost. This is really slow, and a bad implementation. What would be much better, is to have a single command byte at the end of a set of EEPROM write commands to indicate the device should save the data. For native EEPROMs, this will be discarded, but for flash-based emulated implementations, this will allow the file to be saved, and speed up these write operations significantly. I am happy to draft a PR for rnodeconf if necessary, is that the only utility which manipulates the EEPROM?

[faragher]

Ah. I think I see where the confusion comes in. The ESP32 also doesn't have an EEPROM and uses flash. I see you're using files directly in your implementation.

My limited understanding is when you call EEPROM.begin(n) on an ESP32, you pull N bytes from a certain flash location into RAM. You then treat all EEPROM calls as that RAM address+offset, basically using the RAM as the "EEPROM" until EEPROM.commit() is called and the memory is written to storage.

Even if that's not exactly how it works, it's a reasonable method. Since you can simply commit after a change, it doesn't have file access time unless it's updated, and you have a smaller risk of file system corruption. It is slightly memory intensive, but it's likely only marginally worse than the file handle/operation.

If there's no equivalent EEPROM library functionality for the NRF52, I'd suggest following that pattern.

Regarding use outside of rnodeconf: yes, and I see you've already worked on it. ;) The backlight intensity command in the firmware.

https://github.com/markqvist/RNode_Firmware/blob/7466b675b0d647ca2770f788288eea689a569d3a/Utilities.h#L1221

It actually looks like you basically already implemented it this way . . . I think I see. You're keeping the file handle open instead of making a RAM copy and opening the file only to dump it to disk.

Would loading the file to RAM, closing it, and only reopening to commit solve your issue? Again, I believe that's what the ESP32 is doing under the hood anyway.

Edit: While it's the 8266 instead of the 32, it's a good rundown. https://arduino.stackexchange.com/questions/25945/how-to-read-and-write-eeprom-in-esp8266

[jacobeva]

Would loading the file to RAM, closing it, and only reopening to commit solve your issue? Again, I believe that's what the ESP32 is doing under the hood anyway.

Mike, thank you. That's a great suggestion. I will probably have to write my own lib to do it, but that's likely the best way.

I considered writing to the flash directly at one point by using memcpy, but that turned out to just suck, not to mention that it would create problems with the InternalFileSystem library, given that it takes up all the remaining free user flash space on the NRF52 for the file system.

Hopefully your suggestion will make things a bit quicker, we will see!

[faragher]

I can only take credit for finding someone else's solution to the issue,

I'm often a fan of clever solutions, like the memcpy one, but usually it turns out that simple beats c;lever, which is a real shame.

Good hunting, and thanks for all the hard work!