3.0.0 version Migration related issues

[VojtechBartoska]

Hello,

purpose of this issue is to cover problems related to migration from 2.X (at the moment of writing the latest version is 2.0.14) to 3.X version.

💥 If you have any problems, please add comment to this issue. 💥

3.0.0 version introduces breaking changes in those APIs:

• ADC
• BLE
• Hall Sensor
• I2S
• LEDC
• RMT
• SigmaDelta
• TIMER
• UART
• WiFi

🎉 For more details plese take a look on MIGRATION GUIDE FROM 2.X TO 3.X. 🎉

---

List of all related issues: (will be updated)

Please take a look on those issue before adding comment to this ticket.

• V3.0.0 alpha2 Issues with esp32-hal-timer "update" #8776
• Arduino 3.0.0 alpha1 missing entries for gpio_intr_enable and gpio_intr_disable #8737
• SDK is missing on 3.0.0-alpha1 #8746
• Compiling problem - Is 3.0.0.alpha2 more fussy about the source code configuration? #8765
• esp32 board 3.0.0-alpha2: The legacy RMT driver is deprecated #8780
• Board Manager esp32 version 3.0.0-alpha2 does not support MCPWM #8783
• [IDF5.x] Client remoteIP incorrect #8774
• 3.0.0 Alpha2 :: Serial + RMT doesn't work. #8809
• ledcAttach is undefined  #9169

[TD-er]

I think this is also related: #8774

[everslick]

The OneWire lib does not compile anymore, because GPIO is not defined.

libs/OneWire/OneWire.h:167:17: error: 'GPIO' was not declared in this scope; did you mean 'PI'?
  167 |         return (GPIO.in >> pin) & 0x1;
      |                 ^~~~
      |                 PI

This can be fixed by including:

#if ESP_ARDUINO_VERSION_MAJOR >= 3
#include <driver/gpio.h>
#include <hal/rtc_io_ll.h>
#else
#include <driver/rtc_io.h>
#endif

And then using the functions:

rtcio_ll_get_level, rtcio_ll_set_level, rtcio_ll_input_enable and rtcio_ll_output_enable

where appropriate.

Real fix is:

#if ESP_ARDUINO_VERSION_MAJOR >= 3
#include <soc/gpio_struct.h>
#else
#include <driver/rtc_io.h>
#endif

[me-no-dev]

The OneWire lib does not compile anymore, because GPIO is not defined.

Probably needs particular include. Some have changed in IDF5

[everslick]

I have difficulty porting the following code to IDF5. Please look at the line below FIXME! HELP NEEDED!.

error: cannot convert 'wifi_interface_t' to 'esp_netif_t*' {aka 'esp_netif_obj*'}
  esp_netif_get_ip_info(WIFI_IF_AP, &info);

Snippet:

#ifdef ESP32
#ifdef IDF5
  typedef esp_netif_ip_info_t ip_info_t;
#else
  typedef tcpip_adapter_ip_info_t ip_info_t;
#endif
#endif
#ifdef ESP8266
  typedef struct ip_info ip_info_t;
#endif

static ip_info_t ap_ip_info(void) {
  ip_info_t info = { 0 };

#ifdef ESP32
#ifdef IDF5
  // FIXME! HELP NEEDED!
  // esp_netif_get_ip_info(WIFI_IF_AP, &info);
#else // !IDF5
  tcpip_adapter_get_ip_info(TCPIP_ADAPTER_IF_AP, &info);
#endif // !IDF5
#endif // ESP32

#ifdef ESP8266
  wifi_get_ip_info(SOFTAP_IF, &info);
#endif

  return (info);
}

Are wifi_interface_t and esp_netif_t incompatible types or can I just take the address of the former and cast it to the latter?

[lbernstone]

@everslick https://github.com/espressif/esp-idf/blob/v5.1/examples/protocols/http_server/captive_portal/main/dns_server.c#L152

[everslick]

One VERY peculiar thing I just witnessed: Calling yield() in a very tight loop seems to crash with exception 29 (LoadProhibited), while PC points to a few lines above the call to yield() which makes it especially difficult to debug. Luckily I have yield() wrapped in my own system_yield() so I can switch codepaths between versions (and work around the bug). Like:

void system_yield(void) {
#ifdef IDF5
  delay(1);
#else
  yield();
#endif

#ifdef HAVE_WATCHDOG
  watchdog_feed();
#endif
}

When the tight loop, yield() is called in, gets slowed down enough (with e.g. debug prints) it does not crash.

[me-no-dev]

@everslick I am rewriting/restructuring the whole network stack in order to decouple WiFi from the rest of the network functions. Many things have changed and will be fixed/rewritten to work. Some APIs will change/get deprecated, but it's for the better.

[everslick]

@everslick I am rewriting/restructuring the whole network stack in order to decouple WiFi from the rest of the network functions. Many things have changed and will be fixed/rewritten to work. Some APIs will change/get deprecated, but it's for the better.

Yes, I've seen the issue for it. I'm very much looking forward to it!

While we are at it. One of the things I do not really like about the Arduino API is the omnipresent instantiation of singleton like APIs. We have NO_GLOBAL_INSTANCES for that, but this is not always implemented for all interfaces. In case of WiFi, it is so baked in, that nothing works anymore if the global WiFi object is not there. Maybe, if possible, this is something to consider, when reworking the API.