Persistent data storage with RadioLib >= 6.2.0 (arduino-esp32, esp32-s2, esp32, ESPNOW)

[shaffenmeister]

Observation

• FDRA 2.0.1 depends on RadioLib
• when using RadioLib >= 6.2.0 with arduino-esp32, the following error is issued: ArduinoHal.cpp:6:10: fatal error: EEPROM.h: No such file or directory
• This is expected as ESP32 and ESP32-S2 do not provide EEPROM memory.

Environment

CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/lolin_s2_mini.html PLATFORM: Espressif 32 (2023.11.1) > WEMOS LOLIN S2 Mini HARDWARE: ESP32S2 240MHz, 320KB RAM, 4MB Flash DEBUG: Current (cmsis-dap) External (cmsis-dap, esp-bridge, esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa) PACKAGES:

• framework-arduinoespressif32 @ 2.0.14
• tool-esptoolpy @ 1.40700.0+dev2 (4.7.0)
• tool-mklittlefs @ 3.2.0
• tool-mkspiffs @ 2.230.0 (2.30)
• toolchain-riscv32-esp @ 8.4.0+2021r2-patch5
• toolchain-xtensa-esp32s2 @ 8.4.0+2021r2-patch5

Dependency Graph |-- WiFi @ 2.0.0 |-- SPI @ 2.0.0 |-- Farm-Data-Relay-System @ 2.0.1 |-- RadioLib @ 6.3.0 |-- ArduinoJson @ 6.21.3`

The sketch uses ESPNOW as a controller and not LoRa.

Workaround

• define build_flags = -D RADIOLIB_EEPROM_UNSUPPORTED=1

Caveats

• After applying the workaround RadioLib successfully compiles but issues the warning RadioLib/src/protocols/LoRaWAN/LoRaWAN.cpp:7:4: warning: #warning "Persistent storage not supported!" [-Wcpp]

Implications

• Not clear: Does FDRS need to store any LoRa related data?
• Filed this issue for reference.

[timmbogner]

Hey, thanks for this detailed report. Here is the first red flag that I see:

The sketch uses ESPNOW as a controller and not LoRa.

This isn't expected behavior to me. Under Arduino, if USE_LORA is not enabled, then RadioLib is never even included. I don't use PlatformIO except occasional testing, so I'm not totally fluent in its workings. I will have time to set up a matching setup to yours on the weekend. The issue doesn't seem to present in the Arduino IDE.

That confusion aside, it seems like this could be a bit of a RadioLib hiccup. @jgromes is adding LoRaWAN support to RadioLib, which is why the persistent storage stuff is being included. If needed, I think I can add in the workaround for the appropriate chips to FDRS. Having LoRaWAN within RadioLib will open the door to a LoRaWAN front-end in FDRS, which will be pretty cool 😎

[jgromes]

Hello everyone,

@shaffenmeister

This is expected as ESP32 and ESP32-S2 do not provide EEPROM memory.

That's not actually true. ESP32 provides EEPROM library, which emulates EEPROM in ESP32 flash. Which arduino-esp32 version are you using, maybe it's outdated?

[shaffenmeister]

Hello everyone,

@shaffenmeister

This is expected as ESP32 and ESP32-S2 do not provide EEPROM memory.

That's not actually true. ESP32 provides EEPROM library, which emulates EEPROM in ESP32 flash. Which arduino-esp32 version are you using, maybe it's outdated?

Hi, I know about the emulation layer, works like a charm. Platformio provides framework-arduinoespressif32 @ 2.0.14.

Will check and Report Back.

[shaffenmeister]

Okay, this is well-defined behaviour of the dependency resolver in platformio:

When not using -D RADIOLIB_EEPROM_UNSUPPORTED=1 but #include <EEPROM.h> instead in the main Arduino code file the library is compiled in: Dependency Graph (new) |-- WiFi @ 2.0.0 |-- SPI @ 2.0.0 |-- Farm-Data-Relay-System @ 2.0.1 |-- RadioLib @ 6.3.0 |-- ArduinoJson @ 6.21.3 |-- EEPROM @ 2.0.0

Manually specifying lib_deps = EEPROM in platformio.ini resolves the problem as well.

I would have expected the underlying library to pull-in its dependencies on its own using library.json and the like.