v5.5beta1 undocumented difference (IDFGH-15486) (AEGHB-1126)

[dannybackx]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.5beta1

Operating System used.

Linux

How did you build your project?

Command line with idf.py

If you are using Windows, please specify command line type.

None

What is the expected behavior?

Compile like with v5.4.1

What is the actual behavior?

/home/danny/src/esp-idf/ZX3D95CD01S/b/components/bus/8080_lcd_esp32s3.c: In function 'lcd_set_pin':
/home/danny/src/esp-idf/ZX3D95CD01S/b/components/bus/8080_lcd_esp32s3.c:257:5: error: implicit declaration of function gpio_hal_iomux_func_sel'; did you mean 'gpio_hal_func_sel'? [-Wimplicit-function-declaration]
  257 |     gpio_hal_iomux_func_sel(GPIO_PIN_MUX_REG[config->pin_num_wr], PIN_FUNC_GPIO);

Steps to reproduce.

Try to compile a source that calls gpio_hal_iomux_func_sel

Build or installation Logs.

/home/danny/src/esp-idf/ZX3D95CD01S/b/components/bus/8080_lcd_esp32s3.c: In function 'lcd_set_pin':
/home/danny/src/esp-idf/ZX3D95CD01S/b/components/bus/8080_lcd_esp32s3.c:257:5: error: implicit declaration of function gpio_hal_iomux_func_sel'; did you mean 'gpio_hal_func_sel'? [-Wimplicit-function-declaration]
  257 |     gpio_hal_iomux_func_sel(GPIO_PIN_MUX_REG[config->pin_num_wr], PIN_FUNC_GPIO);

Diagnostic report archive.

No response

More Information.

No response

[suda-morris]

Hi @dannybackx

components/bus/8080_lcd_esp32s3.c: In function 'lcd_set_pin':

This is not a component in esp-idf, right? gpio_hal_iomux_func_sel is an internal function in esp-idf, and it was replaced by gpio_func_sel in esp-idf v5.5.

BTW, for using the i8080 LCD driver, we recommend you to use the esp_lcd_io_i80.h driver offered by esp-idf.

If you prefer to use continue using the bus component, feel free to open another issue in the repo where serves the "bus" component. Maybe this one https://github.com/espressif/esp-iot-solution/tree/master/components/bus?

[leeebo]

Hi @dannybackx,

Thank you for your attention. Since the release of esp_lcd (from IDF v4.4), we have been recommending customers to use the API provided by esp_lcd for screen development.

This is a historical issue, and I would like to add some explanation here. Back in 2021, with the introduction of the I2S peripheral on the ESP32-S2, it became possible—through special configuration—to support 8080 interface screens. At that time, the ESP LCD peripheral IP was still evolving, and esp-idf did not yet offer an official LCD driver solution. Unified screen driver development was still under exploration. Some of our early efforts were released as two components, bus and screen in esp-iot-solution, for customer use.

Later on, as esp-idf enhanced its screen support and introduced esp_lcd, the screen and bus components were no longer recommended. They have remained available only to support certain customers with legacy products—especially ESP32/ESP32-S2 I2S LCD applications.

As for the bus component, we refactored and split out the relevant code into separate components—i2c_bus and spi_bus. The remaining I2S_LCD and 8080-related code is still retained in the current bus component (not published to esp-registry), but it is expected to be removed in the next version update of esp-iot-solution.

[dannybackx]

Thanks so much for the insight.

I had frustrating times coping with (what I guess is) the backlash of this.
I tried - to no avail - to get some of the modules I own to work with components from https://components.espressif.com . For some I can, others remain stuck with outdated dependencies like what you describe.

So is there a guideline on how to replace such code by recommended modules ? Some of the legacy code depends on components/touch_panel -> components/screen -> components/bus . So I see code like this :

  i2c_config_t i2c_conf = {
    .mode               = I2C_MODE_MASTER,
    .sda_io_num         = TP_SDA,
    .scl_io_num         = TP_SCL,
    .sda_pullup_en      = GPIO_PULLUP_ENABLE,
    .scl_pullup_en      = GPIO_PULLUP_ENABLE,
    .master = {
      .clk_speed        = 100000,
    },
    .clk_flags          = 0,
  };
  i2c_bus_handle_t i2c_bus = i2c_bus_create(I2C_NUM_0, &i2c_conf);

  touch_panel_config_t touch_cfg = {
    .interface_i2c = {
      .i2c_bus          = i2c_bus,
      .clk_freq         = 100000,
      .i2c_addr         = 0x38,
    },
    .interface_type = TOUCH_PANEL_IFACE_I2C,
      .pin_num_int      = -1,
      .direction        = TOUCH_DIR_LRTB,
      .width            = 480,
      .height           = 480,
  };
  touch_panel_find_driver(TOUCH_PANEL_CONTROLLER_FT5X06, &g_touch);
  g_touch.init(&touch_cfg);

The frustrating bit is that the LVGL demo application (the one with the Elena Smith visual) shows a rock solid display, but when I try to port my own application, all I get is either slightly flickering display, or wildly flickering ones.