Skip to content

3.0.0 version Migration related issues #8796

Closed
@VojtechBartoska

Description

@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.

Activity

converted this from a draft issue on Oct 23, 2023
changed the title [-]3.0.0 version Migration Related issues[/-] [+]3.0.0 version Migration related issues[/+] on Oct 23, 2023
TD-er

TD-er commented on Oct 23, 2023

@TD-er
Contributor

I think this is also related: #8774

everslick

everslick commented on Oct 27, 2023

@everslick
Contributor

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

me-no-dev commented on Oct 27, 2023

@me-no-dev
Member

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

Probably needs particular include. Some have changed in IDF5

everslick

everslick commented on Oct 28, 2023

@everslick
Contributor

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?

everslick

everslick commented on Oct 29, 2023

@everslick
Contributor

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

me-no-dev commented on Oct 30, 2023

@me-no-dev
Member

@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 commented on Oct 30, 2023

@everslick
Contributor

@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.

223 remaining items

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    3.0 migrationissue relates to migration from 2.X to 3.X version

    Type

    No type

    Projects

    Status

    Done

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @mathieucarbou@everslick@bobemoe@TD-er@kapyaar

        Issue actions

          3.0.0 version Migration related issues · Issue #8796 · espressif/arduino-esp32