Impact of EEPROM.commit() ?

[obdevel]

What if anything is the impact of EEPROM.commit() on e.g. interrupts, XIP cache, etc ? And is there any way to reduce this ?

I have an unsubstantiated feeling that it may be causing an interrupt problem/delay but I'd like to confirm either way before I change my code to reduce the number of commits and risk unwritten data if the device is powered off.

Does the size set in EEPROM.begin() have any effect or is the page size fixed at 4KB ?

This is specifically on the original RP2040 Pico. The code uses both cores but accesses flash only from core 0. It uses EEPROM but not a filesystem.

Thanks.

... later ...

I've looked at the source for the EEPROM library and it does idle the other core and suspend interrupts. So it seems I have options to (i) reduce the EEPROM size set in begin() to some smaller multiple of 256 bytes, and/or (b) commit less often. I will try both.

Any other thoughts would be welcome.

[earlephilhower]

If you want to roll your own flash interface, look at https://github.com/earlephilhower/arduino-pico/blob/master/cores/rp2040/sdkoverride/btstack_flash_bank.cpp . Basically you can allocate a 4k-aligned page in your app code and then use raw SDK calls to access it. It's up to you to decide if you can guarantee nobody else needs to read/execute from RAM while the operation is going on (this includes things like the std:: templates and GCC silently inserting calls to memcpy/bzero for assignment operations).

[obdevel]

Thanks. A little context: we're using the PIO CAN bus implementation (https://github.com/KevinOConnor/can2040) which is intolerant of missed interrupts. In this case, we write a value to EEPROM after a specific CAN message and sometimes miss the next message. The message pattern in question is quite predictable so we can delay the EEPROM commit until all CAN messages in the expected sequence have been received. I also chose the largest EEPROM size, as I thought the only downside was the additional RAM usage and we have plenty of that ! So, we can also reduce that to limit the time spent with interrupts suspended.

I will experiment with your suggestion as an additional option.