Delays, yields & problems between nRF52/54 and ESP8266w/WiFi w/RF24Ethernet

[TMRh20]

As it stands, with the existing code, users may experience WDT timer resets with ESP8266 if using WiFi along with RF24Ethernet. I haven't been able to test fully with ESP32 yet.

I was able to work around the issue by removing all the delay() calls in RF24Network, and replacing with millis() based functions. This is because the RF24Network write() function is called from within lwIP callbacks, and yield() should not be called within the callbacks, but the delay() function calls yield so it causes issues. This is only an issue when using WiFi, since it uses lwIP as well.

The problem with the workaround is that it negatively affects nRF52 & 54 based devices, which then end up hanging on network.write() eventually.

Essentially, we need two types of delays, one millis() based for ESP8266 and possibly ESP32, and another delay() based for devices that don't use WiFi like the nRF52 & 54.

I was thinking of defining an internal RF24Network delay function:

void RF24NetworkDelay(uin32_t delay){
    uint32_t timer = millis();
    while(millis() < timer + delay){}
}

Then do some trickery, something like

#if defined ESP8266
    #define RF24NETWORK_DELAY(x) RF24NetworkDelay(x)
#else
    #define RF24NETWORK_DELAY(x) delay(x)
#endif

[2bndy5]

I got stumped on the network layer in rf24-rs because tracking time in embedded-rust is very much dependent on the MCU's HAL (and there's no convenient API like the Arduino Framework). Looks like you're now facing a similar complexity, albeit due to async usage at higher OSI layers.

[TMRh20]

Interesting, this was a case of fix one thing, break another. Until I figured out it affected both sets of devices, which took a while.

Can't you just implement some sort of timing API yourself? Or is that what you did?

[2bndy5]

Can't you just implement some sort of timing API yourself?

Its not so brutish in rust, rather more compartmentalized.

In rust, there are traits. Traits are kinda like C/C++ templates; they declare a promise of implementation(s) without providing the actual implementation.

• On a lib level, its really just a matter of finding the right trait in a lib dep, and using that trait as the instantiated timer's data type.
• But on the app level, the dev would have to find the right implementation of the lib-required trait for the target MCU. And passing an instantiated timer into the lib API can be very different depending on the MCU HAL's implementation (& corresponding setup()-like code).

The second point is why writing universal examples for embedded-rust is so damn hard.

Or is that what you did?

I didn't yet. On the RF24 core level, I require users pass in an implementation of a DelayNs trait to the c'tor. Then I reuse that implementation whenever the RF24 lib needs to wait (eg switching TX/RX mode).

---

Fun fact, espressif just reused their vast ESP-IDF in rust via FFI bindings (like how we use C in Python). So using embedded-rust on an ESP32 actually offers no better safety guarantees than using C (on the system core level -- rust can still help safeguard third-party lib and app code).

Although at some point, there has to be some unsafe rust code at play in embedded-rust (preferably on the lowest possible level of a HAL).

[TMRh20]

So I think I addressed the issues concerning nRF52/nRF54 directly in the nrf_to_nrf library just by adding a timeout to all the while() loops. Things with the nRFs have been stable for days.

These mods are still needed for ESP8266, but I'm not sure yet if needed for ESP32. Testing is at a point where things only happen every 4-5 days so its taking time, but at least we are at a point of stability now. I should be able to test this with ESP32 over the next week or two depending on current results.