text:
Arduino RGB example error for ESP32 S3 to run ST7262 display

Hello,
I installed this library and I solved first library requirement which is esp_io_expander.h
Then I got this error, where esp_memory_utils.h is located in esp-idf-master.
In file included from E:\Programs_Files\Arduino\libraries\ESP32_Display_Panel-master\src/ESP_PanelLog.h:9,
                 from E:\Programs_Files\Arduino\libraries\ESP32_Display_Panel-master\src\lcd\ESP_PanelLcd.cpp:8:
E:\Programs_Files\Arduino\libraries\ESP32_Display_Panel-master\src/ESP_Panel_Conf_Internal.h:51:35: error: operator '!' has no right operand
 #if !ESP_PANEL_CONF_INCLUDE_INSIDE
                                   ^
E:\Programs_Files\Arduino\libraries\ESP32_Display_Panel-master\src\lcd\ESP_PanelLcd.cpp:13:10: fatal error: esp_memory_utils.h: No such file or directory
 #include "esp_memory_utils.h"
          ^~~~~~~~~~~~~~~~~~~~
compilation terminated.
exit status 1
Error compiling for board ESP32S3 Dev Module.

So how to solve these two errors ?

OK, I solved esp_memory_utils.h problem by including the full file path.
But still the second error:
In file included from E:\Programs_Files\Arduino\libraries\ESP32_Display_Panel-master\src/ESP_Panel_Library.h:9,
                 from E:\Programs_Files\Arduino\libraries\ESP32_Display_Panel-master\examples\LCD\RGB\RGB.ino:42:
E:\Programs_Files\Arduino\libraries\ESP32_Display_Panel-master\src/ESP_Panel_Conf_Internal.h:51:35: error: operator '!' has no right operand
 #if !ESP_PANEL_CONF_INCLUDE_INSIDE
                                   ^
exit status 1
Error compiling for board ESP32S3 Dev Module.

Hi @eagl1,
Sorry, it was a bug in the library. And I fixed it in the newest version, please update it.
BTW, if you don't want to update, it can also be resolved by copying the ESP_Panel_Conf.h into the project.

OK, I deleted the previous library folder and downloaded the new one, and I get this error:
Arduino: 1.8.19 (Windows 10), Board: "ESP32S3 Dev Module, Disabled, Disabled, QIO 80MHz, 4MB (32Mb), Core 1, Core 1, Hardware CDC and JTAG, Disabled, Disabled, Disabled, UART0 / Hardware CDC, Default 4MB with spiffs (1.2MB APP/1.5MB SPIFFS), 240MHz (WiFi), 921600, None, Disabled"

E:\Programs_Files\Arduino\libraries\ESP32_Display_Panel-master\src\backlight\ESP_PanelBacklight.cpp: In constructor 'ESP_PanelBacklight::ESP_PanelBacklight(int, bool, bool)':

E:\Programs_Files\Arduino\libraries\ESP32_Display_Panel-master\src\backlight\ESP_PanelBacklight.cpp:18:92: error: no matching function for call to 'ledc_timer_config_t::ledc_timer_config_t(<brace-enclosed initializer list>)'

     _channel_config(ESP_PANEL_BACKLIGHT_LEDC_CHANNEL_CONFIG_DEFAULT(io_num, light_up_level))

                                                                                ^

In file included from E:\Programs_Files\Arduino\libraries\ESP32_Display_Panel-master\src\backlight\ESP_PanelBacklight.h:9,

                 from E:\Programs_Files\Arduino\libraries\ESP32_Display_Panel-master\src\backlight\ESP_PanelBacklight.cpp:8:

C:\Users\eagle\AppData\Local\Arduino15\packages\esp32\hardware\esp32\2.0.17/tools/sdk/esp32s3/include/driver/include/driver/ledc.h:56:3: note: candidate: 'ledc_timer_config_t::ledc_timer_config_t()'

 } ledc_timer_config_t;

   ^~~~~~~~~~~~~~~~~~~

C:\Users\eagle\AppData\Local\Arduino15\packages\esp32\hardware\esp32\2.0.17/tools/sdk/esp32s3/include/driver/include/driver/ledc.h:56:3: note:   candidate expects 0 arguments, 1 provided

C:\Users\eagle\AppData\Local\Arduino15\packages\esp32\hardware\esp32\2.0.17/tools/sdk/esp32s3/include/driver/include/driver/ledc.h:56:3: note: candidate: 'constexpr ledc_timer_config_t::ledc_timer_config_t(const ledc_timer_config_t&)'

C:\Users\eagle\AppData\Local\Arduino15\packages\esp32\hardware\esp32\2.0.17/tools/sdk/esp32s3/include/driver/include/driver/ledc.h:56:3: note:   no known conversion for argument 1 from '<brace-enclosed initializer list>' to 'const ledc_timer_config_t&'

C:\Users\eagle\AppData\Local\Arduino15\packages\esp32\hardware\esp32\2.0.17/tools/sdk/esp32s3/include/driver/include/driver/ledc.h:56:3: note: candidate: 'constexpr ledc_timer_config_t::ledc_timer_config_t(ledc_timer_config_t&&)'

C:\Users\eagle\AppData\Local\Arduino15\packages\esp32\hardware\esp32\2.0.17/tools/sdk/esp32s3/include/driver/include/driver/ledc.h:56:3: note:   no known conversion for argument 1 from '<brace-enclosed initializer list>' to 'ledc_timer_config_t&&'

exit status 1

Error compiling for board ESP32S3 Dev Module.

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

The library depends on arduino-esp v3.0.x SDK. For more details, please check the docs.

I updated the package to the latest one 3.0.1 and got these errors:
Arduino: 1.8.19 (Windows 10), Board: "ESP32S3 Dev Module, Disabled, Disabled, QIO 80MHz, 4MB (32Mb), Core 1, Core 1, Hardware CDC and JTAG, Disabled, Disabled, Disabled, UART0 / Hardware CDC, Default 4MB with spiffs (1.2MB APP/1.5MB SPIFFS), 240MHz (WiFi), 921600, None, Disabled, Disabled"

In file included from C:\Users\eagle\AppData\Local\Arduino15\packages\esp32\tools\esp32-arduino-libs\idf-release_v5.1-442a798083\esp32s3/include/freertos/FreeRTOS-Kernel/portable/xtensa/include/freertos/portmacro.h:79,

                 from C:\Users\eagle\AppData\Local\Arduino15\packages\esp32\tools\esp32-arduino-libs\idf-release_v5.1-442a798083\esp32s3/include/freertos/FreeRTOS-Kernel/include/freertos/portable.h:59,

                 from C:\Users\eagle\AppData\Local\Arduino15\packages\esp32\tools\esp32-arduino-libs\idf-release_v5.1-442a798083\esp32s3/include/freertos/FreeRTOS-Kernel/include/freertos/FreeRTOS.h:71,

                 from E:\Programs_Files\Arduino\libraries\ESP32_Display_Panel-master\src\lcd\ESP_PanelLcd.cpp:15:

C:\Users\eagle\AppData\Local\Arduino15\packages\esp32\tools\esp32-arduino-libs\idf-release_v5.1-442a798083\esp32s3/include/esp_hw_support/include/esp_memory_utils.h:29:20: error: redefinition of 'bool esp_dram_match_iram()'

   29 | inline static bool esp_dram_match_iram(void) {

      |                    ^~~~~~~~~~~~~~~~~~~

In file included from E:\Programs_Files\Arduino\libraries\ESP32_Display_Panel-master\src\lcd\ESP_PanelLcd.cpp:13:

E:\Programs_Files\Arduino\hardware\esp-idf-master\components\esp_hw_support\include\esp_memory_utils.h:29:20: note: 'bool esp_dram_match_iram()' previously defined here

   29 | inline static bool esp_dram_match_iram(void) {

      |                    ^~~~~~~~~~~~~~~~~~~

C:\Users\eagle\AppData\Local\Arduino15\packages\esp32\tools\esp32-arduino-libs\idf-release_v5.1-442a798083\esp32s3/include/esp_hw_support/include/esp_memory_utils.h:41:20: error: redefinition of 'bool esp_ptr_in_iram(const void*)'

   41 | inline static bool esp_ptr_in_iram(const void *p) {

      |                    ^~~~~~~~~~~~~~~

E:\Programs_Files\Arduino\hardware\esp-idf-master\components\esp_hw_support\include\esp_memory_utils.h:41:20: note: 'bool esp_ptr_in_iram(const void*)' previously defined here

   41 | inline static bool esp_ptr_in_iram(const void *p) {

      |                    ^~~~~~~~~~~~~~~

C:\Users\eagle\AppData\Local\Arduino15\packages\esp32\tools\esp32-arduino-libs\idf-release_v5.1-442a798083\esp32s3/include/esp_hw_support/include/esp_memory_utils.h:57:20: error: redefinition of 'bool esp_ptr_in_dram(const void*)'

   57 | inline static bool esp_ptr_in_dram(const void *p) {

      |                    ^~~~~~~~~~~~~~~

E:\Programs_Files\Arduino\hardware\esp-idf-master\components\esp_hw_support\include\esp_memory_utils.h:57:20: note: 'bool esp_ptr_in_dram(const void*)' previously defined here

   57 | inline static bool esp_ptr_in_dram(const void *p) {

      |                    ^~~~~~~~~~~~~~~

C:\Users\eagle\AppData\Local\Arduino15\packages\esp32\tools\esp32-arduino-libs\idf-release_v5.1-442a798083\esp32s3/include/esp_hw_support/include/esp_memory_utils.h:69:20: error: redefinition of 'bool esp_ptr_in_diram_dram(const void*)'

   69 | inline static bool esp_ptr_in_diram_dram(const void *p) {

      |                    ^~~~~~~~~~~~~~~~~~~~~

E:\Programs_Files\Arduino\hardware\esp-idf-master\components\esp_hw_support\include\esp_memory_utils.h:69:20: note: 'bool esp_ptr_in_diram_dram(const void*)' previously defined here

   69 | inline static bool esp_ptr_in_diram_dram(const void *p) {

      |                    ^~~~~~~~~~~~~~~~~~~~~

C:\Users\eagle\AppData\Local\Arduino15\packages\esp32\tools\esp32-arduino-libs\idf-release_v5.1-442a798083\esp32s3/include/esp_hw_support/include/esp_memory_utils.h:81:20: error: redefinition of 'bool esp_ptr_in_diram_iram(const void*)'

   81 | inline static bool esp_ptr_in_diram_iram(const void *p) {

      |                    ^~~~~~~~~~~~~~~~~~~~~

E:\Programs_Files\Arduino\hardware\esp-idf-master\components\esp_hw_support\include\esp_memory_utils.h:81:20: note: 'bool esp_ptr_in_diram_iram(const void*)' previously defined here

   81 | inline static bool esp_ptr_in_diram_iram(const void *p) {

      |                    ^~~~~~~~~~~~~~~~~~~~~

C:\Users\eagle\AppData\Local\Arduino15\packages\esp32\tools\esp32-arduino-libs\idf-release_v5.1-442a798083\esp32s3/include/esp_hw_support/include/esp_memory_utils.h:98:20: error: redefinition of 'bool esp_ptr_in_rtc_iram_fast(const void*)'

   98 | inline static bool esp_ptr_in_rtc_iram_fast(const void *p) {

      |                    ^~~~~~~~~~~~~~~~~~~~~~~~

E:\Programs_Files\Arduino\hardware\esp-idf-master\components\esp_hw_support\include\esp_memory_utils.h:98:20: note: 'bool esp_ptr_in_rtc_iram_fast(const void*)' previously defined here

   98 | inline static bool esp_ptr_in_rtc_iram_fast(const void *p) {

      |                    ^~~~~~~~~~~~~~~~~~~~~~~~

C:\Users\eagle\AppData\Local\Arduino15\packages\esp32\tools\esp32-arduino-libs\idf-release_v5.1-442a798083\esp32s3/include/esp_hw_support/include/esp_memory_utils.h:114:20: error: redefinition of 'bool esp_ptr_in_rtc_dram_fast(const void*)'

  114 | inline static bool esp_ptr_in_rtc_dram_fast(const void *p) {

      |                    ^~~~~~~~~~~~~~~~~~~~~~~~

E:\Programs_Files\Arduino\hardware\esp-idf-master\components\esp_hw_support\include\esp_memory_utils.h:114:20: note: 'bool esp_ptr_in_rtc_dram_fast(const void*)' previously defined here

  114 | inline static bool esp_ptr_in_rtc_dram_fast(const void *p) {

      |                    ^~~~~~~~~~~~~~~~~~~~~~~~

C:\Users\eagle\AppData\Local\Arduino15\packages\esp32\tools\esp32-arduino-libs\idf-release_v5.1-442a798083\esp32s3/include/esp_hw_support/include/esp_memory_utils.h:130:20: error: redefinition of 'bool esp_ptr_in_rtc_slow(const void*)'

  130 | inline static bool esp_ptr_in_rtc_slow(const void *p) {

      |                    ^~~~~~~~~~~~~~~~~~~

E:\Programs_Files\Arduino\hardware\esp-idf-master\components\esp_hw_support\include\esp_memory_utils.h:130:20: note: 'bool esp_ptr_in_rtc_slow(const void*)' previously defined here

  130 | inline static bool esp_ptr_in_rtc_slow(const void *p) {

      |                    ^~~~~~~~~~~~~~~~~~~

C:\Users\eagle\AppData\Local\Arduino15\packages\esp32\tools\esp32-arduino-libs\idf-release_v5.1-442a798083\esp32s3/include/esp_hw_support/include/esp_memory_utils.h:145:22: error: redefinition of 'void* esp_ptr_diram_dram_to_iram(const void*)'

  145 | inline static void * esp_ptr_diram_dram_to_iram(const void *p) {

      |                      ^~~~~~~~~~~~~~~~~~~~~~~~~~

E:\Programs_Files\Arduino\hardware\esp-idf-master\components\esp_hw_support\include\esp_memory_utils.h:145:22: note: 'void* esp_ptr_diram_dram_to_iram(const void*)' previously defined here

  145 | inline static void * esp_ptr_diram_dram_to_iram(const void *p) {

      |                      ^~~~~~~~~~~~~~~~~~~~~~~~~~

C:\Users\eagle\AppData\Local\Arduino15\packages\esp32\tools\esp32-arduino-libs\idf-release_v5.1-442a798083\esp32s3/include/esp_hw_support/include/esp_memory_utils.h:159:22: error: redefinition of 'void* esp_ptr_diram_iram_to_dram(const void*)'

  159 | inline static void * esp_ptr_diram_iram_to_dram(const void *p) {

      |                      ^~~~~~~~~~~~~~~~~~~~~~~~~~

E:\Programs_Files\Arduino\hardware\esp-idf-master\components\esp_hw_support\include\esp_memory_utils.h:159:22: note: 'void* esp_ptr_diram_iram_to_dram(const void*)' previously defined here

  159 | inline static void * esp_ptr_diram_iram_to_dram(const void *p) {

      |                      ^~~~~~~~~~~~~~~~~~~~~~~~~~

C:\Users\eagle\AppData\Local\Arduino15\packages\esp32\tools\esp32-arduino-libs\idf-release_v5.1-442a798083\esp32s3/include/esp_hw_support/include/esp_memory_utils.h:178:20: error: redefinition of 'bool esp_ptr_dma_capable(const void*)'

  178 | inline static bool esp_ptr_dma_capable(const void *p)

      |                    ^~~~~~~~~~~~~~~~~~~

E:\Programs_Files\Arduino\hardware\esp-idf-master\components\esp_hw_support\include\esp_memory_utils.h:192:20: note: 'bool esp_ptr_dma_capable(const void*)' previously defined here

  192 | inline static bool esp_ptr_dma_capable(const void *p)

      |                    ^~~~~~~~~~~~~~~~~~~

C:\Users\eagle\AppData\Local\Arduino15\packages\esp32\tools\esp32-arduino-libs\idf-release_v5.1-442a798083\esp32s3/include/esp_hw_support/include/esp_memory_utils.h:200:20: error: redefinition of 'bool esp_ptr_word_aligned(const void*)'

  200 | inline static bool esp_ptr_word_aligned(const void *p)

      |                    ^~~~~~~~~~~~~~~~~~~~

E:\Programs_Files\Arduino\hardware\esp-idf-master\components\esp_hw_support\include\esp_memory_utils.h:214:20: note: 'bool esp_ptr_word_aligned(const void*)' previously defined here

  214 | inline static bool esp_ptr_word_aligned(const void *p)

      |                    ^~~~~~~~~~~~~~~~~~~~

C:\Users\eagle\AppData\Local\Arduino15\packages\esp32\tools\esp32-arduino-libs\idf-release_v5.1-442a798083\esp32s3/include/esp_hw_support/include/esp_memory_utils.h:213:20: error: redefinition of 'bool esp_ptr_executable(const void*)'

  213 | inline static bool esp_ptr_executable(const void *p)

      |                    ^~~~~~~~~~~~~~~~~~

E:\Programs_Files\Arduino\hardware\esp-idf-master\components\esp_hw_support\include\esp_memory_utils.h:227:20: note: 'bool esp_ptr_executable(const void*)' previously defined here

  227 | inline static bool esp_ptr_executable(const void *p)

      |                    ^~~~~~~~~~~~~~~~~~

C:\Users\eagle\AppData\Local\Arduino15\packages\esp32\tools\esp32-arduino-libs\idf-release_v5.1-442a798083\esp32s3/include/esp_hw_support/include/esp_memory_utils.h:245:20: error: redefinition of 'bool esp_ptr_internal(const void*)'

  245 | inline static bool esp_ptr_internal(const void *p) {

      |                    ^~~~~~~~~~~~~~~~

E:\Programs_Files\Arduino\hardware\esp-idf-master\components\esp_hw_support\include\esp_memory_utils.h:259:20: note: 'bool esp_ptr_internal(const void*)' previously defined here

  259 | inline static bool esp_ptr_internal(const void *p) {

      |                    ^~~~~~~~~~~~~~~~

C:\Users\eagle\AppData\Local\Arduino15\packages\esp32\tools\esp32-arduino-libs\idf-release_v5.1-442a798083\esp32s3/include/esp_hw_support/include/esp_memory_utils.h:290:20: error: redefinition of 'bool esp_ptr_in_drom(const void*)'

  290 | inline static bool esp_ptr_in_drom(const void *p) {

      |                    ^~~~~~~~~~~~~~~

E:\Programs_Files\Arduino\hardware\esp-idf-master\components\esp_hw_support\include\esp_memory_utils.h:304:20: note: 'bool esp_ptr_in_drom(const void*)' previously defined here

  304 | inline static bool esp_ptr_in_drom(const void *p) {

      |                    ^~~~~~~~~~~~~~~

C:\Users\eagle\AppData\Local\Arduino15\packages\esp32\tools\esp32-arduino-libs\idf-release_v5.1-442a798083\esp32s3/include/esp_hw_support/include/esp_memory_utils.h:312:20: error: redefinition of 'bool esp_stack_ptr_in_dram(uint32_t)'

  312 | inline static bool esp_stack_ptr_in_dram(uint32_t sp)

      |                    ^~~~~~~~~~~~~~~~~~~~~

E:\Programs_Files\Arduino\hardware\esp-idf-master\components\esp_hw_support\include\esp_memory_utils.h:326:20: note: 'bool esp_stack_ptr_in_dram(uint32_t)' previously defined here

  326 | inline static bool esp_stack_ptr_in_dram(uint32_t sp)

      |                    ^~~~~~~~~~~~~~~~~~~~~

C:\Users\eagle\AppData\Local\Arduino15\packages\esp32\tools\esp32-arduino-libs\idf-release_v5.1-442a798083\esp32s3/include/esp_hw_support/include/esp_memory_utils.h:337:20: error: redefinition of 'bool esp_stack_ptr_is_sane(uint32_t)'

  337 | inline static bool esp_stack_ptr_is_sane(uint32_t sp)

      |                    ^~~~~~~~~~~~~~~~~~~~~

E:\Programs_Files\Arduino\hardware\esp-idf-master\components\esp_hw_support\include\esp_memory_utils.h:351:20: note: 'bool esp_stack_ptr_is_sane(uint32_t)' previously defined here

  351 | inline static bool esp_stack_ptr_is_sane(uint32_t sp)

      |                    ^~~~~~~~~~~~~~~~~~~~~

exit status 1

Error compiling for board ESP32S3 Dev Module.

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

OK, the code complied with no issues.

This is the working .json configuration from the platformio project.
{
  "build": {
    "arduino": {
      "ldscript": "esp32s3_out.ld",
      "partitions": "default_16MB.csv",
      "memory_type": "qio_opi"
    },
    "core": "esp32",
    "extra_flags": [
      "'-D ARDUINO_ESP32S3_DEV'",
      "'-D BOARD_HAS_PSRAM'",
      "'-D ARDUINO_USB_MODE=1'",
      "'-D ARDUINO_RUNNING_CORE=1'",
      "'-D ARDUINO_EVENT_RUNNING_CORE=1'",
      "'-D ARDUINO_USB_CDC_ON_BOOT=0'",
      "'-D ESP32_8048S043C'",
      "'-D DISPLAY_WIDTH=800'",
      "'-D DISPLAY_HEIGHT=480'",
      "'-D LVGL_BUFFER_PIXELS=(DISPLAY_WIDTH*DISPLAY_HEIGHT)'",
      "'-D LVGL_BUFFER_MALLOC_FLAGS=(MALLOC_CAP_SPIRAM|MALLOC_CAP_8BIT)'",
      "'-D GPIO_BCKL=2'",
      "'-D DISPLAY_ST7262_PAR'",
      "'-D ST7262_PANEL_CONFIG_CLK_SRC=LCD_CLK_SRC_PLL160M'",
      "'-D ST7262_PANEL_CONFIG_TIMINGS_PCLK_HZ=(12.5*1000000)'",
      "'-D ST7262_PANEL_CONFIG_TIMINGS_H_RES=DISPLAY_WIDTH'",
      "'-D ST7262_PANEL_CONFIG_TIMINGS_V_RES=DISPLAY_HEIGHT'",
      "'-D ST7262_PANEL_CONFIG_TIMINGS_HSYNC_PULSE_WIDTH=4'",
      "'-D ST7262_PANEL_CONFIG_TIMINGS_HSYNC_BACK_PORCH=8'",
      "'-D ST7262_PANEL_CONFIG_TIMINGS_HSYNC_FRONT_PORCH=8'",
      "'-D ST7262_PANEL_CONFIG_TIMINGS_VSYNC_PULSE_WIDTH=4'",
      "'-D ST7262_PANEL_CONFIG_TIMINGS_VSYNC_BACK_PORCH=8'",
      "'-D ST7262_PANEL_CONFIG_TIMINGS_VSYNC_FRONT_PORCH=8'",
      "'-D ST7262_PANEL_CONFIG_TIMINGS_FLAGS_HSYNC_IDLE_LOW=false'",
      "'-D ST7262_PANEL_CONFIG_TIMINGS_FLAGS_VSYNC_IDLE_LOW=false'",
      "'-D ST7262_PANEL_CONFIG_TIMINGS_FLAGS_DE_IDLE_HIGH=false'",
      "'-D ST7262_PANEL_CONFIG_TIMINGS_FLAGS_PCLK_ACTIVE_NEG=true'",
      "'-D ST7262_PANEL_CONFIG_TIMINGS_FLAGS_PCLK_IDLE_HIGH=false'",
      "'-D ST7262_PANEL_CONFIG_DATA_WIDTH=16'",
      "'-D ST7262_PANEL_CONFIG_SRAM_TRANS_ALIGN=4'",
      "'-D ST7262_PANEL_CONFIG_PSRAM_TRANS_ALIGN=64'",
      "'-D ST7262_PANEL_CONFIG_HSYNC_GPIO_NUM=39'",
      "'-D ST7262_PANEL_CONFIG_VSYNC_GPIO_NUM=41'",
      "'-D ST7262_PANEL_CONFIG_DE_GPIO_NUM=40'",
      "'-D ST7262_PANEL_CONFIG_PCLK_GPIO_NUM=42'",
      "'-D ST7262_PANEL_CONFIG_DATA_GPIO_R0=8'",
      "'-D ST7262_PANEL_CONFIG_DATA_GPIO_R1=3'",
      "'-D ST7262_PANEL_CONFIG_DATA_GPIO_R2=46'",
      "'-D ST7262_PANEL_CONFIG_DATA_GPIO_R3=9'",
      "'-D ST7262_PANEL_CONFIG_DATA_GPIO_R4=1'",
      "'-D ST7262_PANEL_CONFIG_DATA_GPIO_G0=5'",
      "'-D ST7262_PANEL_CONFIG_DATA_GPIO_G1=6'",
      "'-D ST7262_PANEL_CONFIG_DATA_GPIO_G2=7'",
      "'-D ST7262_PANEL_CONFIG_DATA_GPIO_G3=15'",
      "'-D ST7262_PANEL_CONFIG_DATA_GPIO_G4=16'",
      "'-D ST7262_PANEL_CONFIG_DATA_GPIO_G5=4'",
      "'-D ST7262_PANEL_CONFIG_DATA_GPIO_B0=45'",
      "'-D ST7262_PANEL_CONFIG_DATA_GPIO_B1=48'",
      "'-D ST7262_PANEL_CONFIG_DATA_GPIO_B2=47'",
      "'-D ST7262_PANEL_CONFIG_DATA_GPIO_B3=21'",
      "'-D ST7262_PANEL_CONFIG_DATA_GPIO_B4=14'",
      "'-D ST7262_PANEL_CONFIG_DISP_GPIO_NUM=GPIO_NUM_NC'",
      "'-D ST7262_PANEL_CONFIG_FLAGS_DISP_ACTIVE_LOW=false'",
      "'-D ST7262_PANEL_CONFIG_FLAGS_RELAX_ON_IDLE=false'",
      "'-D ST7262_PANEL_CONFIG_FLAGS_FB_IN_PSRAM=true'",
      "'-D DISPLAY_SWAP_XY=false'",
      "'-D DISPLAY_MIRROR_X=false'",
      "'-D DISPLAY_MIRROR_Y=false'",
      "'-D BOARD_HAS_TOUCH'",
      "'-D CONFIG_ESP_LCD_TOUCH_MAX_POINTS=1'",
      "'-D CONFIG_ESP_LCD_TOUCH_MAX_BUTTONS=0'",
      "'-D TOUCH_GT911_I2C'",
      "'-D GT911_I2C_HOST=I2C_NUM_0'",
      "'-D GT911_I2C_CONFIG_SDA_IO_NUM=19'",
      "'-D GT911_I2C_CONFIG_SCL_IO_NUM=20'",
      "'-D GT911_I2C_CONFIG_SDA_PULLUP_EN=GPIO_PULLUP_DISABLE'",
      "'-D GT911_I2C_CONFIG_SCL_PULLUP_EN=GPIO_PULLUP_DISABLE'",
      "'-D GT911_I2C_CONFIG_MASTER_CLK_SPEED=400000'",
      "'-D GT911_I2C_CONFIG_CLK_FLAGS=I2C_SCLK_SRC_FLAG_FOR_NOMAL'",
      "'-D GT911_IO_I2C_CONFIG_DEV_ADDR=GT911_IO_I2C_CONFIG_DEV_ADDRESS_5D'",
      "'-D GT911_IO_I2C_CONFIG_CONTROL_PHASE_BYTES=1'",
      "'-D GT911_IO_I2C_CONFIG_DC_BIT_OFFSET=0'",
      "'-D GT911_IO_I2C_CONFIG_LCD_CMD_BITS=16'",
      "'-D GT911_IO_I2C_CONFIG_LCD_PARAM_BITS=0'",
      "'-D GT911_IO_I2C_CONFIG_FLAGS_DC_LOW_ON_DATA=false'",
      "'-D GT911_IO_I2C_CONFIG_FLAGS_DISABLE_CONTROL_PHASE=true'",
      "'-D GT911_TOUCH_CONFIG_X_MAX=DISPLAY_WIDTH'",
      "'-D GT911_TOUCH_CONFIG_Y_MAX=DISPLAY_HEIGHT'",
      "'-D GT911_TOUCH_CONFIG_RST_GPIO_NUM=38'",
      "'-D GT911_TOUCH_CONFIG_INT_GPIO_NUM=18'",
      "'-D GT911_TOUCH_CONFIG_LEVELS_RESET=0'",
      "'-D GT911_TOUCH_CONFIG_LEVELS_INTERRUPT=0'",
      "'-D TOUCH_SWAP_XY=false'",
      "'-D TOUCH_MIRROR_X=false'",
      "'-D TOUCH_MIRROR_Y=false'",
      "'-D BOARD_HAS_TF'",
      "'-D TF_CS=10'",
      "'-D TF_SPI_MOSI=11'",
      "'-D TF_SPI_SCLK=12'",
      "'-D TF_SPI_MISO=13'"
    ],
    "f_cpu": "240000000L",
    "f_flash": "80000000L",
    "flash_mode": "qio",
    "hwids": [
      [
        "0x303A",
        "0x1001"
      ]
    ],
    "mcu": "esp32s3",
    "variant": "esp32s3"
  },
  "connectivity": [
    "wifi"
  ],
  "debug": {
    "openocd_target": "esp32s3.cfg"
  },
  "frameworks": [
    "arduino",
    "espidf"
  ],
  "name": "esp32-8048S043C",
  "upload": {
    "flash_size": "16MB",
    "maximum_ram_size": 327680,
    "maximum_size": 16777216,
    "use_1200bps_touch": true,
    "wait_for_upload_port": true,
    "require_upload_port": true,
    "speed": 460800
  },
  "url": "https://www.aliexpress.com/item/1005006110360174.html",
  "vendor": "Sunton"
}

So I edited the pin arrangement to the one in your arduino RGB sketch and it still not working, I'm sure there's still something missing in the code.

The serial monitor is continuously trying to initialize the display. This is the serial output:

OK, I checked the supported boards.
I think I have to do add a new file for the display I have esp32-8048S043C.

The serial monitor is continuously trying to initialize the display. This is the serial output:

When using RGB LCD, ESP32-S3 needs to enable PSRAM. There are some recommended configurations in Arduino IDE.

I'm still getting this error:
Arduino: 1.8.19 (Windows 10), Board: "ESP32S3 Dev Module, Disabled, OPI PSRAM, QIO 80MHz, 4MB (32Mb), Core 1, Core 1, Hardware CDC and JTAG, Disabled, Disabled, Disabled, UART0 / Hardware CDC, Default 4MB with spiffs (1.2MB APP/1.5MB SPIFFS), 240MHz (WiFi), 921600, None, Disabled, Disabled"

In file included from E:\projects_electronics_programming\tft\other sketches\GFX_Library_for_Arduino\GFX_Library_for_Arduino.ino:11:

Arduino_GFX_dev_device.h:14:1: error: 'Arduino_ESP32RGBPanel' does not name a type; did you mean 'Arduino_ESP32S2PAR8Q'?

   14 | Arduino_ESP32RGBPanel *rgbpanel = new Arduino_ESP32RGBPanel(

      | ^~~~~~~~~~~~~~~~~~~~~

      | Arduino_ESP32S2PAR8Q

Arduino_GFX_dev_device.h:22:1: error: 'Arduino_RGB_Display' does not name a type

   22 | Arduino_RGB_Display *gfx = new Arduino_RGB_Display(

      | ^~~~~~~~~~~~~~~~~~~

E:\projects_electronics_programming\tft\other sketches\GFX_Library_for_Arduino\GFX_Library_for_Arduino.ino: In function 'void setup()':

GFX_Library_for_Arduino:50:8: error: 'gfx' was not declared in this scope

   50 |   if (!gfx->begin())

      |        ^~~

GFX_Library_for_Arduino:56:7: error: 'gfx' was not declared in this scope

   56 |   w = gfx->width();

      |       ^~~

E:\projects_electronics_programming\tft\other sketches\GFX_Library_for_Arduino\GFX_Library_for_Arduino.ino: In function 'void loop()':

GFX_Library_for_Arduino:148:5: error: 'gfx' was not declared in this scope

  148 |     gfx->drawFastHLine(0, i, w, c);

      |     ^~~

GFX_Library_for_Arduino:156:3: error: 'gfx' was not declared in this scope

  156 |   gfx->setCursor(0, 0);

      |   ^~~

E:\projects_electronics_programming\tft\other sketches\GFX_Library_for_Arduino\GFX_Library_for_Arduino.ino: In function 'void serialOut(const char*, int32_t, uint32_t, bool)':

GFX_Library_for_Arduino:226:5: error: 'gfx' was not declared in this scope

  226 |     gfx->fillScreen(BLACK);

      |     ^~~

E:\projects_electronics_programming\tft\other sketches\GFX_Library_for_Arduino\GFX_Library_for_Arduino.ino: In function 'void printnice(const char*, long int)':

GFX_Library_for_Arduino:236:3: error: 'gfx' was not declared in this scope

  236 |   gfx->setTextSize(tsb);

      |   ^~~

E:\projects_electronics_programming\tft\other sketches\GFX_Library_for_Arduino\GFX_Library_for_Arduino.ino: In function 'int32_t testFillScreen()':

GFX_Library_for_Arduino:272:3: error: 'gfx' was not declared in this scope

  272 |   gfx->fillScreen(WHITE);

      |   ^~~

E:\projects_electronics_programming\tft\other sketches\GFX_Library_for_Arduino\GFX_Library_for_Arduino.ino: In function 'int32_t testText()':

GFX_Library_for_Arduino:284:3: error: 'gfx' was not declared in this scope

  284 |   gfx->setCursor(0, 0);

      |   ^~~

E:\projects_electronics_programming\tft\other sketches\GFX_Library_for_Arduino\GFX_Library_for_Arduino.ino: In function 'int32_t testPixels()':

GFX_Library_for_Arduino:377:7: error: 'gfx' was not declared in this scope

  377 |       gfx->drawPixel(x, y, gfx->color565(x << 3, y << 3, x * y));

      |       ^~~

E:\projects_electronics_programming\tft\other sketches\GFX_Library_for_Arduino\GFX_Library_for_Arduino.ino: In function 'int32_t testLines()':

GFX_Library_for_Arduino:398:5: error: 'gfx' was not declared in this scope

  398 |     gfx->drawLine(x1, y1, x2, y2, BLUE);

      |     ^~~

GFX_Library_for_Arduino:407:5: error: 'gfx' was not declared in this scope

  407 |     gfx->drawLine(x1, y1, x2, y2, BLUE);

      |     ^~~

GFX_Library_for_Arduino:418:5: error: 'gfx' was not declared in this scope

  418 |     gfx->drawLine(x1, y1, x2, y2, BLUE);

      |     ^~~

GFX_Library_for_Arduino:427:5: error: 'gfx' was not declared in this scope

  427 |     gfx->drawLine(x1, y1, x2, y2, BLUE);

      |     ^~~

GFX_Library_for_Arduino:438:5: error: 'gfx' was not declared in this scope

  438 |     gfx->drawLine(x1, y1, x2, y2, BLUE);

      |     ^~~

GFX_Library_for_Arduino:447:5: error: 'gfx' was not declared in this scope

  447 |     gfx->drawLine(x1, y1, x2, y2, BLUE);

      |     ^~~

GFX_Library_for_Arduino:458:5: error: 'gfx' was not declared in this scope

  458 |     gfx->drawLine(x1, y1, x2, y2, BLUE);

      |     ^~~

GFX_Library_for_Arduino:467:5: error: 'gfx' was not declared in this scope

  467 |     gfx->drawLine(x1, y1, x2, y2, BLUE);

      |     ^~~

E:\projects_electronics_programming\tft\other sketches\GFX_Library_for_Arduino\GFX_Library_for_Arduino.ino: In function 'int32_t testFastLines()':

GFX_Library_for_Arduino:485:5: error: 'gfx' was not declared in this scope

  485 |     gfx->drawFastHLine(0, y, w, RED);

      |     ^~~

GFX_Library_for_Arduino:489:5: error: 'gfx' was not declared in this scope

  489 |     gfx->drawFastVLine(x, 0, h, BLUE);

      |     ^~~

E:\projects_electronics_programming\tft\other sketches\GFX_Library_for_Arduino\GFX_Library_for_Arduino.ino: In function 'int32_t testFilledRects()':

GFX_Library_for_Arduino:506:5: error: 'gfx' was not declared in this scope

  506 |     gfx->fillRect(cx - i2, cy - i2, i, i, gfx->color565(i, i, 0));

      |     ^~~

E:\projects_electronics_programming\tft\other sketches\GFX_Library_for_Arduino\GFX_Library_for_Arduino.ino: In function 'int32_t testRects()':

GFX_Library_for_Arduino:521:5: error: 'gfx' was not declared in this scope

  521 |     gfx->drawRect(cx - i2, cy - i2, i, i, GREEN);

      |     ^~~

E:\projects_electronics_programming\tft\other sketches\GFX_Library_for_Arduino\GFX_Library_for_Arduino.ino: In function 'int32_t testFilledCircles(uint8_t)':

GFX_Library_for_Arduino:538:7: error: 'gfx' was not declared in this scope

  538 |       gfx->fillCircle(x, y, radius, MAGENTA);

      |       ^~~

E:\projects_electronics_programming\tft\other sketches\GFX_Library_for_Arduino\GFX_Library_for_Arduino.ino: In function 'int32_t testCircles(uint8_t)':

GFX_Library_for_Arduino:560:7: error: 'gfx' was not declared in this scope

  560 |       gfx->drawCircle(x, y, radius, WHITE);

      |       ^~~

E:\projects_electronics_programming\tft\other sketches\GFX_Library_for_Arduino\GFX_Library_for_Arduino.ino: In function 'int32_t testFillArcs()':

GFX_Library_for_Arduino:574:5: error: 'gfx' was not declared in this scope

  574 |     gfx->fillArc(cx1, cy1, i, i - 3, 0, i * r, RED);

      |     ^~~

E:\projects_electronics_programming\tft\other sketches\GFX_Library_for_Arduino\GFX_Library_for_Arduino.ino: In function 'int32_t testArcs()':

GFX_Library_for_Arduino:587:5: error: 'gfx' was not declared in this scope

  587 |     gfx->drawArc(cx1, cy1, i, i - 3, 0, i * r, WHITE);

      |     ^~~

E:\projects_electronics_programming\tft\other sketches\GFX_Library_for_Arduino\GFX_Library_for_Arduino.ino: In function 'int32_t testFilledTriangles()':

GFX_Library_for_Arduino:602:5: error: 'gfx' was not declared in this scope

  602 |     gfx->fillTriangle(cx1, cy1 - i, cx1 - i, cy1 + i, cx1 + i, cy1 + i,

      |     ^~~

E:\projects_electronics_programming\tft\other sketches\GFX_Library_for_Arduino\GFX_Library_for_Arduino.ino: In function 'int32_t testTriangles()':

GFX_Library_for_Arduino:618:5: error: 'gfx' was not declared in this scope

  618 |     gfx->drawTriangle(

      |     ^~~

E:\projects_electronics_programming\tft\other sketches\GFX_Library_for_Arduino\GFX_Library_for_Arduino.ino: In function 'int32_t testFilledRoundRects()':

GFX_Library_for_Arduino:638:5: error: 'gfx' was not declared in this scope

  638 |     gfx->fillRoundRect(cx - i2, cy - i2, i, i, i / 8, gfx->color565(0, i, 0));

      |     ^~~

E:\projects_electronics_programming\tft\other sketches\GFX_Library_for_Arduino\GFX_Library_for_Arduino.ino: In function 'int32_t testRoundRects()':

GFX_Library_for_Arduino:654:5: error: 'gfx' was not declared in this scope

  654 |     gfx->drawRoundRect(cx - i2, cy - i2, i, i, i / 8, gfx->color565(i, 0, 0));

      |     ^~~

exit status 1

'Arduino_ESP32RGBPanel' does not name a type; did you mean 'Arduino_ESP32S2PAR8Q'?

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

Sorry, I am not familiar with the Arduino_GFX library.

No, I'm sorry my mistake. I'm working on both libraries + platformio projects.
I did the PSRAM enable but still the same problem.

Okay... That's a little strange. Could you set the Core Debug Level to Debug and check the log again? It will show the PSRAM status.

OK, I think it worked.
This is the RGB example:

I have another question, if I wanted to add ST7262 source code to another arduino C++ library, how to copy the init data ? because I want to add this display to TFT_eSPI library because it helps me using GUIslice software and support our college projects.
Thanks,

Nice! However, I have no idea how to add this display to the TFT_eSPI library.


text:
Cannot open libclang.dll, LoadLibraryExW failed

I have followed all the installation instructions, making sure my enviornment variables are set and correct. I cannot build because the .dll file is not being opened and I do not know why. I've treid working at this for hours now with not much online to help.  Here is my tomls: [package]
name = "espt12"
version = "0.1.0"
authors = ["MiniMinerX jessehrupe@gmail.com"]
edition = "2021"
resolver = "2"
rust-version = "1.79"
[[bin]]
name = "espt12"
harness = false # do not use the built in cargo test harness -> resolve rust-analyzer errors
[profile.release]
opt-level = "s"
[profile.dev]
debug = true    # Symbols are nice and they don't increase the size on Flash
opt-level = "z"
[features]
default = ["std", "embassy", "esp-idf-svc/native"]
pio = ["esp-idf-svc/pio"]
std = ["alloc", "esp-idf-svc/binstart", "esp-idf-svc/std"]
alloc = ["esp-idf-svc/alloc"]
nightly = ["esp-idf-svc/nightly"]
experimental = ["esp-idf-svc/experimental"]
embassy = ["esp-idf-svc/embassy-sync", "esp-idf-svc/critical-section", "esp-idf-svc/embassy-time-driver"]
[dependencies]
log = { version = "0.4", default-features = false }
esp-idf-svc = { version = "0.49", default-features = false }
[build-dependencies]
embuild = "0.32.0" and then this toml: [toolchain]
channel = "esp" and then finally: [build]
target = "xtensa-esp32-espidf"
[target.xtensa-esp32-espidf]
linker = "ldproxy"
runner = "espflash flash --monitor" # Select this runner for espflash v3.x.x
rustflags = [ "--cfg",  "espidf_time64"] # Extending time_t for ESP IDF 5: https://github.com/esp-rs/rust/issues/110
[unstable]
build-std = ["std", "panic_abort"]
[env]
MCU="esp32"
RUST_BACKTRACE = "full"
Note: this variable is not used by the pio builder (cargo build --features pio)
ESP_IDF_VERSION = "v5.2.2"
Workaround for https://github.com/esp-rs/esp-idf-template/issues/174
CRATE_CC_NO_DEFAULTS = "1"
I ran these commands in the terminal to source the paths: > $Env:LIBCLANG_PATH = "C:\Users\minim.rustup\toolchains\esp\xtensa-esp32-elf-clang\esp-clang\bin\libclang.dll"

$Env:PATH = "C:\Users\minim.rustup\toolchains\esp\xtensa-esp32-elf-clang\esp-clang\bin;" + $Env:PATH
$Env:PATH = "C:\Users\minim.rustup\toolchains\esp\xtensa-esp-elf\bin;" + $Env:PATH
PS C:\espt12>

Here is my output after doing cargo build --release
Note the line: Unable to find libclang: "the libclang shared library at C:\Users\minim\.rustup\toolchains\esp\xtensa-esp32-elf-clang\esp-clang\bin\libclang.dll could not be opened: LoadLibraryExW failed"
PS C:\espt12> cargo build --release
Compiling bindgen v0.69.4
Compiling embuild v0.32.0
Compiling esp-idf-sys v0.35.0
Compiling esp-idf-hal v0.44.1
Compiling esp-idf-svc v0.49.1
Compiling espt12 v0.1.0 (C:\espt12)
The following warnings were emitted during compilation:
warning: esp-idf-sys@0.35.0: Compiler family detection failed due to error: ToolNotFound: Failed to find tool. Is cc installed? (see https://docs.rs/cc/latest/cc/#compile-time-requirements for help)
warning: esp-idf-sys@0.35.0: Compiler family detection failed due to error: ToolNotFound: Failed to find tool. Is cc installed? (see https://docs.rs/cc/latest/cc/#compile-time-requirements for help)
error: failed to run custom build command for esp-idf-sys v0.35.0
Caused by:
process didn't exit successfully: C:\espt12\target\release\build\esp-idf-sys-b6269cda32b60966\build-script-build (exit code: 101)
--- stdout
cargo:rerun-if-env-changed=ESP_IDF_TOOLS_INSTALL_DIR
cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG
cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG_DEFAULTS
cargo:rerun-if-env-changed=MCU
cargo:rerun-if-env-changed=ESP_IDF_SYS_ROOT_CRATE
cargo:rerun-if-env-changed=ESP_IDF_VERSION
cargo:rerun-if-env-changed=ESP_IDF_REPOSITORY
cargo:rerun-if-env-changed=ESP_IDF_CMAKE_GENERATOR
cargo:rerun-if-env-changed=IDF_PATH
cargo:rerun-if-env-changed=EXTRA-COMPONENTS
cargo:rerun-if-env-changed=ESP_IDF_COMPONENTS
cargo:rerun-if-env-changed=ESP_IDF_COMPONENT_MANAGER
Python 3.12.4
pip 24.1.2 from C:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\Lib\site-packages\pip (python 3.12)
Requirement already satisfied: pip in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (24.1.2)
Requirement already satisfied: setuptools in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (71.0.0)
Collecting setuptools
Using cached setuptools-71.1.0-py3-none-any.whl.metadata (6.6 kB)
Using cached setuptools-71.1.0-py3-none-any.whl (2.3 MB)
Installing collected packages: setuptools
Attempting uninstall: setuptools
Found existing installation: setuptools 71.0.0
Uninstalling setuptools-71.0.0:
Successfully uninstalled setuptools-71.0.0
Successfully installed setuptools-71.1.0
Looking in indexes: https://pypi.org/simple, https://dl.espressif.com/pypi
Ignoring importlib_metadata: markers 'python_version < "3.8"' don't match your environment
Collecting setuptools (from -r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 3))
Using cached https://dl.espressif.com/pypi/setuptools/setuptools-71.0.0-py3-none-any.whl (908 kB)
Requirement already satisfied: packaging in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from -r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 4)) (24.1)
Requirement already satisfied: click in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from -r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 7)) (8.1.7)
Requirement already satisfied: pyserial in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from -r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 8)) (3.5)
Requirement already satisfied: cryptography in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from -r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 9)) (41.0.7)
Requirement already satisfied: pyparsing in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from -r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 10)) (3.1.2)
Requirement already satisfied: pyelftools in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from -r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 11)) (0.31)
Requirement already satisfied: idf-component-manager in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from -r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 12)) (1.5.3)
Requirement already satisfied: esp-coredump in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from -r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 13)) (1.11.0)
Requirement already satisfied: esptool in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from -r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 14)) (4.7.0)
Requirement already satisfied: esp-idf-kconfig in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from -r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 15)) (1.4.2)
Requirement already satisfied: esp-idf-monitor in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from -r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 16)) (1.4.0)
Requirement already satisfied: esp-idf-size in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from -r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 17)) (1.5.0)
Requirement already satisfied: esp-idf-panic-decoder in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from -r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 18)) (1.1.0)
Requirement already satisfied: pyclang in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from -r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 19)) (0.4.2)
Requirement already satisfied: construct in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from -r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 20)) (2.10.70)
Requirement already satisfied: freertos_gdb in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from -r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 23)) (1.0.3)
Requirement already satisfied: colorama in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from click->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 7)) (0.4.6)
Requirement already satisfied: cffi>=1.12 in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from cryptography->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 9)) (1.16.0)
Requirement already satisfied: requests<3 in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from idf-component-manager->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 12)) (2.32.3)
Requirement already satisfied: urllib3<2 in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from idf-component-manager->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 12)) (1.26.19)
Requirement already satisfied: requests-file<2 in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from idf-component-manager->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 12)) (1.5.1)
Requirement already satisfied: requests-toolbelt in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from idf-component-manager->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 12)) (1.0.0)
Requirement already satisfied: schema<=0.7.5 in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from idf-component-manager->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 12)) (0.7.5)
Requirement already satisfied: six in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from idf-component-manager->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 12)) (1.16.0)
Requirement already satisfied: tqdm<5 in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from idf-component-manager->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 12)) (4.66.4)
Requirement already satisfied: pyyaml>5.2 in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from idf-component-manager->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 12)) (6.0.1)
Requirement already satisfied: cachecontrol>0.12.6 in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from cachecontrol[filecache]>0.12.6; python_version >= "3.6"->idf-component-manager->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 12)) (0.14.0)
Requirement already satisfied: contextlib2>0.6.0 in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from idf-component-manager->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 12)) (21.6.0)
Requirement already satisfied: pygdbmi>=0.9.0.2 in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from esp-coredump->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 13)) (0.11.0.0)
Requirement already satisfied: bitstring>=3.1.6 in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from esptool->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 14)) (4.2.3)
Requirement already satisfied: ecdsa>=0.16.0 in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from esptool->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 14)) (0.19.0)
Requirement already satisfied: reedsolo<1.8,>=1.5.3 in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from esptool->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 14)) (1.7.0)
Requirement already satisfied: intelhex in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from esptool->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 14)) (2.3.0)
Requirement already satisfied: kconfiglib>=13.7.1 in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from esp-idf-kconfig->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 15)) (14.1.0)
Requirement already satisfied: windows-curses in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from esp-idf-kconfig->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 15)) (2.3.3)
Requirement already satisfied: rich in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from esp-idf-size->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 17)) (13.7.1)
Requirement already satisfied: bitarray<3.0.0,>=2.9.0 in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from bitstring>=3.1.6->esptool->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 14)) (2.9.2)
Requirement already satisfied: msgpack<2.0.0,>=0.5.2 in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from cachecontrol>0.12.6->cachecontrol[filecache]>0.12.6; python_version >= "3.6"->idf-component-manager->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 12)) (1.0.8)
Requirement already satisfied: filelock>=3.8.0 in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from cachecontrol[filecache]>0.12.6; python_version >= "3.6"->idf-component-manager->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 12)) (3.15.4)
Requirement already satisfied: pycparser in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from cffi>=1.12->cryptography->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 9)) (2.22)
Requirement already satisfied: charset-normalizer<4,>=2 in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from requests<3->idf-component-manager->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 12)) (3.3.2)
Requirement already satisfied: idna<4,>=2.5 in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from requests<3->idf-component-manager->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 12)) (3.7)
Requirement already satisfied: certifi>=2017.4.17 in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from requests<3->idf-component-manager->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 12)) (2024.7.4)
Requirement already satisfied: markdown-it-py>=2.2.0 in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from rich->esp-idf-size->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 17)) (3.0.0)
Requirement already satisfied: pygments<3.0.0,>=2.13.0 in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from rich->esp-idf-size->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 17)) (2.18.0)
Requirement already satisfied: mdurl~=0.1 in c:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\lib\site-packages (from markdown-it-py>=2.2.0->rich->esp-idf-size->-r C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt (line 17)) (0.1.2)
Installing collected packages: setuptools
Attempting uninstall: setuptools
Found existing installation: setuptools 71.1.0
Uninstalling setuptools-71.1.0:
Successfully uninstalled setuptools-71.1.0
Successfully installed setuptools-71.0.0
Upgrading pip and setuptools...
Skipping the download of C:\espt12.embuild\espressif\espidf.constraints.v5.2.txt because it was downloaded recently.
Installing Python packages
Constraint file: C:\espt12.embuild\espressif\espidf.constraints.v5.2.txt
Requirement files:
- C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt
cargo:rerun-if-changed=C:\espt12\sdkconfig.defaults
cargo:warning=Compiler family detection failed due to error: ToolNotFound: Failed to find tool. Is cc installed? (see https://docs.rs/cc/latest/cc/#compile-time-requirements for help)
cargo:warning=Compiler family detection failed due to error: ToolNotFound: Failed to find tool. Is cc installed? (see https://docs.rs/cc/latest/cc/#compile-time-requirements for help)
CMAKE_PREFIX_PATH_xtensa-esp32-espidf = None
CMAKE_PREFIX_PATH_xtensa_esp32_espidf = None
TARGET_CMAKE_PREFIX_PATH = None
CMAKE_PREFIX_PATH = None
CMAKE_xtensa-esp32-espidf = None
CMAKE_xtensa_esp32_espidf = None
TARGET_CMAKE = None
CMAKE = None
running: "cmake" "C:\espt12\target\xtensa-esp32-espidf\release\build\esp-idf-sys-a5fb95e86f32cad3\out" "-G" "Ninja" "-DCMAKE_TOOLCHAIN_FILE=C:\espt12\.embuild\espressif\esp-idf\v5.2.2\tools\cmake\toolchain-esp32.cmake" "-DCMAKE_BUILD_TYPE=" "-DPYTHON=C:/espt12/.embuild/espressif/python_env/idf5.2_py3.12_env/Scripts/python" "-DCMAKE_INSTALL_PREFIX=C:\espt12\target\xtensa-esp32-espidf\release\build\esp-idf-sys-a5fb95e86f32cad3\out" "-DCMAKE_C_FLAGS= -mlongcalls -Wno-frame-address -fno-builtin-memcpy -fno-builtin-memset -fno-builtin-bzero -fno-builtin-stpcpy -fno-builtin-strncpy" "-DCMAKE_CXX_FLAGS= -mlongcalls -Wno-frame-address -fno-builtin-memcpy -fno-builtin-memset -fno-builtin-bzero -fno-builtin-stpcpy -fno-builtin-strncpy" "-DCMAKE_ASM_FLAGS= -mlongcalls"
-- git describe returned 'fatal: bad revision 'HEAD''
-- Could not use 'git describe' to determine PROJECT_VER.
-- Building ESP-IDF components for target esp32
-- Checking Python dependencies...
Python requirements are satisfied.
Constraint file: C:\espt12.embuild\espressif\espidf.constraints.v5.2.txt
Requirement files:

C:\espt12.embuild\espressif\esp-idf\v5.2.2\tools\requirements\requirements.core.txt
Python being checked: C:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\Scripts\python.exe
-- Project sdkconfig file C:/espt12/target/xtensa-esp32-espidf/release/build/esp-idf-sys-a5fb95e86f32cad3/out/sdkconfig
Loading defaults file C:/espt12/target/xtensa-esp32-espidf/release/build/esp-idf-sys-a5fb95e86f32cad3/out/gen-sdkconfig.defaults...
C:/espt12/target/xtensa-esp32-espidf/release/build/esp-idf-sys-a5fb95e86f32cad3/out/gen-sdkconfig.defaults:2 CONFIG_COMPILER_OPTIMIZATION_DEFAULT was replaced with CONFIG_COMPILER_OPTIMIZATION_DEBUG
Loading defaults file C:/espt12/sdkconfig.defaults...
-- Compiler supported targets: xtensa-esp-elf
-- App "libespidf" version: 1
-- Adding linker script C:/espt12/target/xtensa-esp32-espidf/release/build/esp-idf-sys-a5fb95e86f32cad3/out/build/esp-idf/esp_system/ld/memory.ld
-- Adding linker script C:/espt12/target/xtensa-esp32-espidf/release/build/esp-idf-sys-a5fb95e86f32cad3/out/build/esp-idf/esp_system/ld/sections.ld.in
-- Adding linker script C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_rom/esp32/ld/esp32.rom.ld
-- Adding linker script C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_rom/esp32/ld/esp32.rom.api.ld
-- Adding linker script C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_rom/esp32/ld/esp32.rom.libgcc.ld
-- Adding linker script C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_rom/esp32/ld/esp32.rom.newlib-data.ld
-- Adding linker script C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_rom/esp32/ld/esp32.rom.syscalls.ld
-- Adding linker script C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_rom/esp32/ld/esp32.rom.newlib-funcs.ld
-- Adding linker script C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/soc/esp32/ld/esp32.peripherals.ld
-- Components: app_trace app_update bootloader bootloader_support bt cmock console cxx driver efuse esp-tls esp_adc esp_app_format esp_bootloader_format esp_coex esp_common esp_eth esp_event esp_gdbstub esp_hid esp_http_client esp_http_server esp_https_ota esp_https_server esp_hw_support esp_lcd esp_local_ctrl esp_mm esp_netif esp_netif_stack esp_partition esp_phy esp_pm esp_psram esp_ringbuf esp_rom esp_system esp_timer esp_wifi espcoredump esptool_py fatfs freertos hal heap http_parser idf_test ieee802154 json log lwip main mbedtls mqtt newlib nvs_flash nvs_sec_provider openthread partition_table perfmon protobuf-c protocomm pthread sdmmc soc spi_flash spiffs tcp_transport ulp unity usb vfs wear_levelling wifi_provisioning wpa_supplicant xtensa
-- Component paths: C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/app_trace C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/app_update C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/bootloader C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/bootloader_support C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/bt C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/cmock C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/console C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/cxx C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/driver C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/efuse C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp-tls C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_adc C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_app_format C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_bootloader_format C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_coex C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_common C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_eth C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_event C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_gdbstub C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_hid C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_http_client C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_http_server C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_https_ota C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_https_server C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_hw_support C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_lcd C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_local_ctrl C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_mm C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_netif C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_netif_stack C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_partition C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_phy C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_pm C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_psram C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_ringbuf C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_rom C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_system C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_timer C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_wifi C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/espcoredump C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esptool_py C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/fatfs C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/freertos C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/hal C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/heap C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/http_parser C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/idf_test C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/ieee802154 C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/json C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/log C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/lwip C:/espt12/target/xtensa-esp32-espidf/release/build/esp-idf-sys-a5fb95e86f32cad3/out/main C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/mbedtls C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/mqtt C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/newlib C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/nvs_flash C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/nvs_sec_provider C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/openthread C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/partition_table C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/perfmon C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/protobuf-c C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/protocomm C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/pthread C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/sdmmc C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/soc C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/spi_flash C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/spiffs C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/tcp_transport C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/ulp C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/unity C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/usb C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/vfs C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/wear_levelling C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/wifi_provisioning C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/wpa_supplicant C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/xtensa
-- Configuring done
-- Generating done
-- Build files have been written to: C:/espt12/target/xtensa-esp32-espidf/release/build/esp-idf-sys-a5fb95e86f32cad3/out/build
running: "cmake" "--build" "." "--config" "MinSizeRel" "--parallel" "32"
[1/7] Generating ld/sections.ld
[2/7] Linking CXX executable libespidf.elf
[3/7] Generating binary image from built executable
esptool.py v4.7.0
Creating esp32 image...
Merged 2 ELF sections
Successfully created esp32 image.
Generated C:/espt12/target/xtensa-esp32-espidf/release/build/esp-idf-sys-a5fb95e86f32cad3/out/build/libespidf.bin
[4/7] cmd.exe /C "cd /D C:\espt12\target\xtensa-esp32-espidf\release\build\esp-idf-sys-a5fb95e86f32cad3\out\build\esp-idf\esptool_py && C:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\Scripts\python C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/partition_table/check_sizes.py --offset 0x8000 partition --type app C:/espt12/target/xtensa-esp32-espidf/release/build/esp-idf-sys-a5fb95e86f32cad3/out/build/partition_table/partition-table.bin C:/espt12/target/xtensa-esp32-espidf/release/build/esp-idf-sys-a5fb95e86f32cad3/out/build/libespidf.bin"
libespidf.bin binary size 0x27930 bytes. Smallest app partition is 0x100000 bytes. 0xd86d0 bytes (85%) free.
[5/7] Performing build step for 'bootloader'
-- Building ESP-IDF components for target esp32
-- Project sdkconfig file C:/espt12/target/xtensa-esp32-espidf/release/build/esp-idf-sys-a5fb95e86f32cad3/out/sdkconfig
-- Compiler supported targets: xtensa-esp-elf
-- Adding linker script C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/soc/esp32/ld/esp32.peripherals.ld
-- Bootloader project name: "bootloader" version: 1
-- Adding linker script C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_rom/esp32/ld/esp32.rom.ld
-- Adding linker script C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_rom/esp32/ld/esp32.rom.api.ld
-- Adding linker script C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_rom/esp32/ld/esp32.rom.libgcc.ld
-- Adding linker script C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_rom/esp32/ld/esp32.rom.newlib-funcs.ld
-- Adding linker script C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/bootloader/subproject/main/ld/esp32/bootloader.ld
-- Adding linker script C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/bootloader/subproject/main/ld/esp32/bootloader.rom.ld
-- Components: bootloader bootloader_support efuse esp_app_format esp_bootloader_format esp_common esp_hw_support esp_rom esp_system esptool_py freertos hal log main micro-ecc newlib partition_table soc spi_flash xtensa
-- Component paths: C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/bootloader C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/bootloader_support C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/efuse C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_app_format C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_bootloader_format C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_common C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_hw_support C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_rom C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esp_system C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/esptool_py C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/freertos C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/hal C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/log C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/bootloader/subproject/main C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/bootloader/subproject/components/micro-ecc C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/newlib C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/partition_table C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/soc C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/spi_flash C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/xtensa
-- Configuring done
-- Generating done
-- Build files have been written to: C:/espt12/target/xtensa-esp32-espidf/release/build/esp-idf-sys-a5fb95e86f32cad3/out/build/bootloader
[0/1] Re-running CMake...
[1/1] cmd.exe /C "cd /D C:\espt12\target\xtensa-esp32-espidf\release\build\esp-idf-sys-a5fb95e86f32cad3\out\build\bootloader\esp-idf\esptool_py && C:\espt12.embuild\espressif\python_env\idf5.2_py3.12_env\Scripts\python C:/espt12/.embuild/espressif/esp-idf/v5.2.2/components/partition_table/check_sizes.py --offset 0x8000 bootloader 0x1000 C:/espt12/target/xtensa-esp32-espidf/release/build/esp-idf-sys-a5fb95e86f32cad3/out/build/bootloader/bootloader.bin"
Bootloader binary size 0x6860 bytes. 0x7a0 bytes (7%) free.
cargo:root=C:\espt12\target\xtensa-esp32-espidf\release\build\esp-idf-sys-a5fb95e86f32cad3\out
cargo:rerun-if-changed=C:\Users\minim.cargo\registry\src\index.crates.io-6f17d22bba15001f\esp-idf-sys-0.35.0\src\include\esp-idf\bindings.h
cargo:rustc-env=EMBUILD_GENERATED_BINDINGS_FILE=C:\espt12\target\xtensa-esp32-espidf\release\build\esp-idf-sys-a5fb95e86f32cad3\out\bindings.rs

--- stderr
Build configuration: BuildConfig {
esp_idf_tools_install_dir: None,
esp_idf_sdkconfig: None,
esp_idf_sdkconfig_defaults: None,
mcu: Some(
"esp32",
),
native: NativeConfig {
esp_idf_version: Some(
Tag(
"v5.2.2",
),
),
esp_idf_repository: None,
esp_idf_cmake_generator: None,
idf_path: None,
extra_components: [],
esp_idf_components: None,
esp_idf_component_manager: None,
},
esp_idf_sys_root_crate: None,
}
Using managed esp-idf repository: RemoteSdk { repo_url: None, git_ref: Tag("v5.2.2") }
Using esp-idf v5.2.2 at 'C:\espt12.embuild\espressif\esp-idf\v5.2.2'
Built components: xtensa, esp_ringbuf, efuse, esp_mm, driver, esp_pm, mbedtls, esp_bootloader_format, esp_app_format, bootloader_support, bootloader, esptool_py, partition_table, esp_partition, app_update, spi_flash, pthread, esp_system, esp_rom, hal, log, heap, soc, esp_hw_support, freertos, newlib, cxx, esp_common, esp_timer, app_trace, esp_event, nvs_flash, esp_phy, vfs, lwip, esp_netif_stack, esp_netif, wpa_supplicant, esp_coex, esp_wifi, bt, unity, cmock, console, http_parser, esp-tls, esp_adc, esp_eth, esp_gdbstub, esp_hid, tcp_transport, esp_http_client, esp_http_server, esp_https_ota, esp_https_server, esp_psram, esp_lcd, protobuf-c, protocomm, esp_local_ctrl, espcoredump, wear_levelling, sdmmc, fatfs, idf_test, ieee802154, json, mqtt, nvs_sec_provider, openthread, perfmon, spiffs, ulp, usb, wifi_provisioning, main
thread 'main' panicked at C:\Users\minim.cargo\registry\src\index.crates.io-6f17d22bba15001f\bindgen-0.69.4\lib.rs:622:31:
Unable to find libclang: "the libclang shared library at C:\Users\minim\.rustup\toolchains\esp\xtensa-esp32-elf-clang\esp-clang\bin\libclang.dll could not be opened: LoadLibraryExW failed"
stack backtrace:
0:     0x7ff683a94ffb - std::backtrace_rs::backtrace::trace_unsynchronized::h46a05f2575fa14d7
1:     0x7ff683a967b1 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h9f0fdb41129a842b
2:     0x7ff683acd01a - core::fmt::write::h9e11dfc6d17d1c07
3:     0x7ff683abb621 - std::io::Write::write_fmt::h33efa9e475fc91de
4:     0x7ff683a9658f - std::process::exit::h5e3cc61667c84915
5:     0x7ff683a976ca - std::panicking::default_hook::hf90ac8f8a78f6f7b
6:     0x7ff683a97353 - std::panicking::default_hook::hf90ac8f8a78f6f7b
7:     0x7ff683a98218 - std::panicking::rust_panic_with_hook::h62023a0c4fd17305
8:     0x7ff683a980f7 - <std::panicking::begin_panic_handler::StaticStrPayload as core::panic::PanicPayload>::take_box::h7d0d2bfc46d23547
9:     0x7ff683a96c6f - std::sys_common::backtrace::__rust_begin_short_backtrace::hde6d43922da5914c
10:     0x7ff683a97e18 - rust_begin_unwind
11:     0x7ff683adc1b4 - core::panicking::panic_fmt::hc019ac27196d215d
12:     0x7ff683adc7b0 - core::result::unwrap_failed::h6552edba637263b2
13:     0x7ff6834bf604 - core::result::Result<T,E>::expect::hb3309c3a1c3c3291
14:     0x7ff6834752bc - core::ops::function::FnOnce::call_once::h5d7cdaa71849ee6d
15:     0x7ff6834f7c3b - lazy_static::lazy::Lazy::get::{{closure}}::h703506b50d675ab2
16:     0x7ff683517c40 - std::sync::once::Once::call_once::{{closure}}::hb294324ebc6a8bd5
17:     0x7ff683adb3b4 - std::sys::sync::once::queue::Once::call::h6b6b7976e380e78c
18:     0x7ff683517ae0 - std::sync::once::Once::call_once::hc09c69e5243b26ad
19:     0x7ff683515ff4 - <bindgen::ensure_libclang_is_loaded::LIBCLANG as core::ops::deref::Deref>::deref::h7a23bd74ad345d54
20:     0x7ff68350ece9 - bindgen::deprecated_target_diagnostic::hf7152a9482ceb835
21:     0x7ff68350fdbe - <bindgen::BindgenError as core::fmt::Display>::fmt::h3e8cdbf0341aa52e
22:     0x7ff68350e3c9 - bindgen::Builder::generate::h1c3ad78b548d2a94
23:     0x7ff68318671c - <build_script_build::BindgenCallbacks as bindgen::callbacks::ParseCallbacks>::int_macro::{{closure}}::ha64a0ff38e86e3d0
24:     0x7ff6831b2696 - core::ops::function::FnOnce::call_once::h6d0f87376d070dbb
25:     0x7ff6831e5779 - std::sys_common::backtrace::__rust_begin_short_backtrace::he5abf919a1dafae7
26:     0x7ff6831a5a2c - std::rt::lang_start::{{closure}}::h832a9944a0b32cb9
27:     0x7ff683a97afe - std::panicking::try::h224dfc5b82599353
28:     0x7ff683aa7f4e - std::rt::lang_start_internal::h243ea0028ca15fb1
29:     0x7ff6831a5a07 - std::rt::lang_start::h01c8cabd9d0af738
30:     0x7ff683188ba9 - main
31:     0x7ff683ad9650 - invoke_main
at D:\a_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
32:     0x7ff683ad9650 - __scrt_common_main_seh
at D:\a_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
33:     0x7ffc39f8257d - BaseThreadInitThunk
34:     0x7ffc3b1eaf28 - RtlUserThreadStart
PS C:\espt12>,

That may be a espup problem. We have similar reports from other uses and they could resolve it by downgrading to espup version 11 and installing the toolchain with that espup version. There is an open issue here

That makes sense. I'll try that today. For now I gave up on rancid windows and am running Ubuntu inside of vmware workstation. The Linux setup of esp32 for me was a breeze, so I've been developing on that. I also tried wsl, but my esp32 needed the ch341 drivers, so I had to recompile the wsl kernel with them enabled. Then I broke wsl usbipd for good it seems, so vmware is my savior.

That makes sense. I'll try that today. For now I gave up on rancid windows and am running Ubuntu inside of vmware workstation. The Linux setup of esp32 for me was a breeze, so I've been developing on that. I also tried wsl, but my esp32 needed the ch341 drivers, so I had to recompile the wsl kernel with them enabled. Then I broke wsl usbipd for good it seems, so vmware is my savior.

When I used to work with WSL, I used to do all development from Linux, but then for flashing I just copied the resulting ELF to the Windows partition and then used the espflash utility natively compiled for Windows (with cargo install espflash). This way I did not have to deal with obscure usb drivers on the Linux level.

If I remember correctly, I think you can call native windows binaries from the Linux shell, so with some bash scripting you can further automate calling the Windows-compiled espflash from WSL.

source: gharchive/issue

authors: MiniMinerX Vollbrecht ivmarkov

repo: esp-rs/esp-idf-hal

license_type: permissive

license_source: github-api


text:
cargo-espflash not picking up partitions.csv?

I cloned the repo and ran:
MCU=esp32c3 cargo espflash flash --target riscv32imc-esp-espidf --example wifi --monitor

And I got this error:
Error: espflash::image_too_big (link)

  × Supplied ELF image of 1799664B is too big, and doesn't fit configured app partition of 1048576B
  help: Reduce the size of the binary or increase the size of the app partition.

This is the current partitions.csv:
# Name,   Type, SubType, Offset,  Size, Flags
# Note: if you have increased the bootloader size, make sure to update the offsets to avoid overlap
nvs,      data, nvs,     ,        0x6000,
phy_init, data, phy,     ,        0x1000,
factory,  app,  factory, ,        3M,

The app partition seems to be set to 3M. And no matter how I change partitions.csv, I keep getting the same error.

I solved the issue by generating my own partitions-table.bin:
espflash partition-table --to-binary --output partition-table.bin partitions.csv

Then:
MCU=esp32c3 cargo espflash flash --target riscv32imc-esp-espidf --example wifi --monitor --partition-table="partition-table.bin"

If you are using espflash than this is not a problem, but cargo espflash works a bit different. Because they made changes in the respected versions 3 of espflash and cargo espflash we now provide the partitions.csv in the root. Though with the extra espflash.toml file it should automatically pick it up.
What version of espflash are you using? It should working with a csv file and if not it may indicate a bug in espflash

Ah, I updated espflash and cargo-espflash. The error is gone. Sorry, I should have done that before opening this issue.

My espflash is 3.1.1 but the issue is still there

 My espflash is 3.1.1 but the issue is still there

No it is not a problem. Please read the comments carefully. You are using espflash where you have to provide the partiton-table as an argument. Only cargo espflash has the capability to pick it up for you.

authors: Vollbrecht vult0306 weiying-chen

repo: esp-rs/esp-idf-svc


text:
Avoid blank pages, omit desc tab instead

Closes #44
These changes allow packages with Markdown (README) serialization failures to show up in the web hub instead of having a blank page. ATM the description tab is simply omitted if a serialization error occurs. Additionally, a log error is added so we can better track which packages fails at build time.
I also refactored some code to simplify stuff around the get static props by eliminating FP jargon. Moreover, if something brutal happens (eg. we get fetch the index) the entire build should fails to avoid deployment of a basically empty hub.
As a test, I took some packages listed in #43 and other discussions and check out locally that they show up in the web hub.

espanso-pinyin-tones
vim-digraphs
arrows
portuguese-accents
flutter-snippets
tholzschuh-maths
alt-codes
med-expansions
better-typography
discord-snippets

Here's some screenshots

This table arranges the four images in a 2x2 grid, with two images in each row.

Oh, we could show the desc tab with a placeholder pointing to the Github repo (if available)

Oh, we could show the desc tab with a placeholder pointing to the Github repo (if available)

Whatever suits you better. We can merge this as is and worry about that later, o make an extra push and resolve that. I'm happy with both!

Thank you!

source: gharchive/pull-request

authors: AucaCoyan arabello

repo: espanso/hub-frontend

license: MIT


text:
Possible copyright infringement if include ”Alexa” as a wake word in a commercial product?

Slightly off-tanget, but wondering if you think it could possibly count as copyright infringement if one included ”Alexa” or ”Siri” and other already commercially used wakewords in your own commercial product?
No problems if individuals build DIY devices for personal use I am sure as then it is provably fair use, but to play it safe it would probably be a good idea to not include aleeady commercially used wake words like ”Alexa”, ”Siri”, ”Cortana”, and ”Bixby”, etc. In your own products that you plan to sell.
I am thinking of example Home Assistent’s upcoming voice-kit hardware as well as other thind-party hardware products that will use this framework as a platform.

The Alexa model is the worst performing of the four available, so that alone makes it not suitable for our satellite hardware. I have no idea what the legal implications are.

authors: Hedda kahrendt

repo: esphome/micro-wake-word-models


text:
error when building ext-template

I have a get a strange error when issuing the build per the readMe.
node build --all
Fetching EspoCRM repository...
Downloading EspoCRM archive from Github...
Unzipping...
Installing EspoCRM instance...
Creating config...
Npm install...
npm ERR! code EUSAGE
npm ERR!
npm ERR! npm ci can only install packages when your package.json and package-lock.json or npm-shrinkwrap.json are in sync. Please update your lock file with npm install before continuing.
npm ERR!
npm ERR! Missing: minimist@0.0.10 from lock file

Fixed by changing branch from "stable" to "master" in config.json  and re-running command.
"espocrm": {
"repository": "https://github.com/espocrm/espocrm.git",
"branch": "master"
},

repo: espocrm/ext-template


text:
Are the ESP-IDF peripherals API for SPI and I2C compatible with interrupt reading? (IDFGH-10899)

Answers checklist.

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

General issue report
Is it possible to have a performant interrupt read with I2C and SPI?
By reading the ESP32/ESP32S3 technical references, I see that this could be done by handling registers, but I hoped that there would be a way to do that with the driver/HAL/LL libraries from ESP-IDF. My expectation and the reality (as I currently understand) are as follows:
EXPECTATION: When recording data from a sensor, I'd like to do this interrupt read pattern:

mcu waits for sensor
sensor sets interrupt line high
mcu gpio interrupt triggers start of I2C/SPI transaction
end of transaction interrupt triggers data handling by a task

REALITY: I can't do that with the peripherals API. What I can do is:

have a dedicated task, t1, to perform transactions when notified (waiting with ulTaskNotifyTake)
mcu waits for sensor
sensor sets interrupt line high
mcu gpio interrupt notifies t1 (vTaskNotifyGiveFromISR)
t1 runs blocking and triggers data handling when it's done

which is not as performant as the expectation.
With I2C, the only way to start a transaction is with i2c_master_cmd_begin(...), but it is always blocking:

Send all the queued commands on the I2C bus, in master mode. The task will be blocked until all the commands have been sent out. The I2C port is protected by mutex, so this function is thread-safe. This function shall only be called in I2C master mode.

With SPI, I tried calling spi_device_queue_trans from the GPIO interrupt while calling spi_device_get_trans_result from the data handling task, but calling spi_device_get_trans_result before the first spi_device_queue_trans gives out an error (example code here).
Is there anything I can do to make this work?

Hello @herculanodavi ,
If I understand correctly, you want the minimum latency between the moment the external sensor pulls the GPIO high and the master (ESP32/S3) initiates a transfer.
The way you did is the proper way to do: have a Task that waits on a notification, have a GPIO interrupt handler that notifies that Task, which is scheduled right after and will initiate the I2C transfer. As you know, the I2C transfers on ESP-IDF are blocking, but this would not help since that would not make the transfer happen any earlier.
One thing you can make sure of is that the I2C/SPI Task has a higher priority than the other tasks.
If you want something more efficient, with less latency, I can think of the following:

Use the ULP (low-power core), as a co-processor that will handle the sensor GPIO and initiate the I2C transfers, the received data will ened to be saved in RTC RAM, so that it can be accessed by the main core too. Since it doesn't have any RTOS on it, it's just bare-metal, you will have no latency.
Use the I2C HAL/LL layer directly within your GPIO interrupt handler so that you can schedule and initiate a transfer from the interrupt handler. If you choose this route, do not use the default ESP-IDF I2C driver, else you may encounter some incompatible behaviors (because the driver may expect the I2C hardware registers to be in a certain state when making a transfer)
Implement a high priority interrupt in assembly. You may not have access to the whole IDF API here, so you might want to notify your task with something simple like a shared variable: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/hlinterrupts.html
Implement a high priority interrupt in assembly which will prepare the I2C hardware registers to initiate a transfer

Hi @o-marshmallow,
What I really want is something similar to what you said -- I'd like to offload as much work from the MCU as possible to the peripherals. Maybe I'm wrong, but the blocking API calls spend a lot of CPU cycles constantly checking if the operation is done.
There's are no big issues with the current latency, but I want to perform calculations (like doing DSP with a ping-pong buffer) while performing the transactions and this polling behaviour generates a bottleneck.
I've seen that for I2C there is this new driver API, I2C Master. This would be more in the path of what I wanted to achieve. I see it was not released in version 5.1.1, so would it be released in 5.1.2 or only in 5.2?
As for SPI, would you have any suggestions? I tried doing this but it fails since I'm calling spi_device_get_trans_result first. I hoped that I could use this API in a similar way than FreeRTOS' Queue Receive/Send.
typedef struct transaction_args {
  spi_device_handle_t spi;
  spi_transaction_t *trans;
} transaction_args_t;

static void IRAM_ATTR gpio_isr_handler(void *arg) {
  transaction_args_t *trans_args = (transaction_args_t *)arg;
  ESP_ERROR_CHECK(
      spi_device_queue_trans(trans_args->spi, trans_args->trans, 0));
}

void data_handler_task(void *args) {
  transaction_args_t *trans_args = (transaction_args_t *)args;
  spi_transaction_t *received_trans_args = NULL;

  for (;;) {
    spi_device_get_trans_result(trans_args->spi, &received_trans_args,
                                portMAX_DELAY);
  }
}

@o-marshmallow
@igrr
I have a very similar situation as the above, except mine is (currently) I2C specific.
We have 16x GPIO inputs on 2x PCF8574 I2C devices, with the PCF8574 IRQ pins tied to GPIO's configured for interrupts on the falling edge only. But due to the nature of the PCF8574 it generates interrupt for both 1->0 as well as 0->1 changes. Unfortunately. determine which of the 2 cases the interrupt is for, we have to read the device for both interrupts.
In our GPIO interrupt handler we add an entry into a queue that feeds a dedicated I2C task. Majority of the time the I2C task can cope with the incoming requests, but when the water meters are busy we run into problems with the I2C task not being able to handle the requests, we suspect due to the blocking nature.
Very recently we noticed the message suggesting we change to the new I2C driver mentioned above but we have not been able to find any documentation on this new driver anywhere. We had a look at the source code and the API's are very different, far simpler than the current/old driver and APIs.
Before we start the reasonably complex process of rewriting our I2C support subsystem it will be of great value if we can have a detailed writeup on the new driver and API, including....

How do the 2 drivers architecturally compare?
What problems in the old/current driver is fixed in the new driver?
How do the 2 drivers compare form a performance/blocking point of view?
Are the I2C peripherals in the ESP32[S2/S3] exactly the same that the drivers will behave exactly the same or is there a recommended rule for choosing the driver based on the ESP32 version?

Your soonest assistance with information addressing the above would be highly appreciated.
Thanks

Hello @herculanodavi ,

the blocking API calls spend a lot of CPU cycles constantly checking if the operation is done.

This isn't true, the CPU will not poll the I2C peripheral until it is finished. It will prepare and start the I2C transfer and then wait for a a completion interrupt from the I2C peripheral to occur to resume the Task's code. You can see this here: https://github.com/espressif/esp-idf/blob/master/components/driver/i2c/i2c.c#L1542
While this Task is waiting for the I2C to be completed, FreeRTOS will schedule other Tasks of your system, if none is ready, Idle task will run. In all cases, there will be no polling and so your CPU will never "waste" time or cycles waiting for the I2C transfer to finish.
The new I2C driver will offer the possibility to have asynchronous I2C transfers, which means that the I2C start transaction will not block and will let you continue executing the code of the current Task. I insist on "the current Task": if you currently have a Task that only performs I2C transfers and another one that does calculations unrelated to I2C, having the possibility to have asynchronous I2C transfers won't be more useful in your case since FreeRTOS can already schedule the secodn task while the I2C one is waiting (as I said above).
Regarding SPI, spi_device_queue_trans cannot be called from an ISR. The solutions are the same as the one listed above for the I2C. For example, you can have a Task of higher priority than your main Task that will wait for a notification from your SPI interrupt handler, as soon as it is schedule by FreeRTOS, you can start a new transfer.

Hello @ammaree,
Do you know at which point your program starts having problem? Does your queue become full at one point? Does the Task that initiates the I2C transfer take too much time to process the queue? Does the Task that initiates the I2C transfer get seldom shceduled by FreeRTOS?
In your case, it seems to me that you don't need a queue, but simply a notification. If you get an interrupt on your GPIO, it means that the state of a pin has changed, so you notify the I2C Task that a transfer is required. It will be scheduled by FreeRTOS as soon as you call the portYIELD_FROM_ISR() macro after xTaskNotifyFromISR  (check the last parameter).
If you still want to keep track of the number of notifications to your ISR Task (e.g. three GPIO interrupts must trigger three I2C transfer), you can use a counting semaphore.
The new I2C driver was written from scratch, it is more efficient than the former one:

Simpler API
Supports synchronous and asynchronous transfers (user callback called upon transfer completion)
No more dynamic memory allocations for synchronous transfers
Takes advantage of the hardware command list to have the least amount of interrupts

Overall, it is more performant, requires less CPU power to initiate and perform transfers and gets interrupt less frequently by filling the hardware commands beforehand.

Thanks @o-marshmallow for all the info. The issue can be closed from my side, but I'm not sure about @ammaree.

@o-marshmallow
We have over the weekend burned the midnight oil and converted our I2C task and supporting routines to the new I2C driver. So far testing is not positive. We can initialise the bus and send a General Reset, but probing addresses 0x8 to 0x78 ALL return ESP_OK on a platform that has a single device at 0x20.
Regarding the proposal to use an event flag, not sure how workable this is. ON most of our hardware platforms we have multiple I2C devices. The majority of those are NOT IRQ driven but polled and hence use the mechanism to add entries into the queue, each sensor or actuator on its own predetermined schedule.
Adding event flag functionality and getting the task to wait on either of:
a) an item from the queue (current scenario); and/or
b) an event from the PCF8574
seems like complicating since, not even sure if FreeRTOS can be configured to simultaneously wait for either of those?
If we can resolve the i2c_master_probe() problem that will help a lot towards testing.

@ammaree

but probing addresses 0x8 to 0x78 ALL return ESP_OK on a platform that has a single device at 0x20.

That sounds like a bug from the new driver, it must be reported. Would you mind creating a new issue for that?
If I understand your situation, you have several I2C devices that msut be polled at their own pace, so you have a FIFO where you enqueue the devices to read. Then the PCF8574 is not related to these devices, right? It's just yet another I2C device that would generate an interrupt where you enqueue its I2C device/address.
FreeRTOS doesn't have the possibility to wait on several "objects" at the same time, you still need two Tasks for that.

@o-marshmallow
@igrr
I have created a new issue with basic example code.
If somebody can please ASAP have a look and fix, we can proceed with testing the new driver.
Right now we are at a standstill....

This Issue can be closed from our side, provided new issue gets some attention please

authors: ammaree herculanodavi o-marshmallow

repo: espressif/esp-idf


text:
Thread safety of multiple devices on a single SPI bus (IDFGH-3570)

Development Kit:      none
Module or chip used:  ESP32D0WDQ6 (revision 1)
IDF version: v4.2-dev-1905-g625bd5eb1
Build System:        make
Compiler version: esp-2020r2-8.2.0
Operating System:     Linux
Using an IDE?: No
Power Supply:         external 5V

I'm having issues with this assertion triggering intermittently.
I have 2 SPI devices on the same bus (SPI3). In the warning here, it says I have to just add a mutex lock around the shared Device using xSemaphoreCreateMutex, which is exactly what I'm doing, but the app breaks. The way I'm doing it is by not locking all spi transactions behind a single universal mutex, but rather having a mutex for each SPI device, and locking the one linked to that specific device.
So for example, instead of this:
SemaphoreHandle_t spi_semphr;

void spi_trans( spi_device_handle_t spi_device, uint8_t *buf_w, uint8_t *buf_r, uint8_t len )
{
	xSemaphoreTake( spi_semphr, portMAX_DELAY );

	ESP_ERROR_CHECK( spi_device_polling_transmit( spi_device,
		&( spi_transaction_t ){ .length = 8 * len, .tx_buffer = buf_w, .rx_buffer = buf_r } ) );

	xSemaphoreGive( spi_semphr );
}

I'd do something like this:
SemaphoreHandle_t spi_dev1_semphr;
SemaphoreHandle_t spi_dev2_semphr;

spi_device_handle_t spi_dev1;
spi_device_handle_t spi_dev2;

void spi_trans_dev1( uint8_t *buf_w, uint8_t *buf_r, uint8_t len )
{
	xSemaphoreTake( spi_dev1_semphr, portMAX_DELAY );

	ESP_ERROR_CHECK( spi_device_polling_transmit( spi_dev1,
		&( spi_transaction_t ){ .length = 8 * len, .tx_buffer = buf_w, .rx_buffer = buf_r } ) );

	xSemaphoreGive( spi_dev1_semphr );
}

void spi_trans_dev2( uint8_t *buf_w, uint8_t *buf_r, uint8_t len )
{
	xSemaphoreTake( spi_dev2_semphr, portMAX_DELAY );

	ESP_ERROR_CHECK( spi_device_polling_transmit( spi_dev2,
		&( spi_transaction_t ){ .length = 8 * len, .tx_buffer = buf_w, .rx_buffer = buf_r } ) );

	xSemaphoreGive( spi_dev2_semphr );
}

I can avoid this issue by reverting to use one global mutex for all transactions, which brings me to the questions: what's going on? Am I missing something? How thread-safe is the spi master library really?

you should use only 1 mutex for each spi bus, not device. the mutex prevent you to access the bus when it is busy. if you have 2 mutex, then device 1 and device 2 can access the bus at the same time and you get your assertion.

you should use only 1 mutex for each spi bus, not device. the mutex prevent you to access the bus when it is busy. if you have 2 mutex, then device 1 and device 2 can access the bus at the same time and you get your assertion.

Reading must be difficult, so no worries

I think the concept you are missing ismutex. Here is a short explaination https://www.webopedia.com/TERM/M/mutex.html

Thanks, I guess? In return, could you do me a favor and actually read what I wrote beyond the title and presume the rest? Thanks in advance.

@igrr I don't like tagging anyone but as it seems to be a trivial thing, its importance to me isn't. If the docs are right, I could avoid redundantly locking the entire SPI bus, but I also wouldn't have the assert triggering on me. Just throw me a bone or something.

@ginkgm Can you take a look at this? Is lyris85 right? In that case, the doc printed above is wrong because it means 1 task per SPI device, not 1 task per SPI bus, and it should be reworded to "... As long as all devices on the same bus are accessed by only one task ... if multiple tasks try to access any of the SPI devices...".
Or the docs are correct and the spi_master component has always been bugged because it doesn't implicitly handle the 1 task/device approach.
Btw, if my first hypothesis is correct, why is that the case? Why doesn't spi_master offers a way to implicitly handle concurrent accesses to the same bus, through the spi_device_polling_transmit and spi_device_transmit wrappers or similar? They fulfill this role of being the simplest and easiest APIs for SPI transactions anyway.

Answered here. I'll close it, even though the suggestion for improving the documentation remains.

I'm probably slow but I'm not sure I understand the conclusion. I'm having that same problem https://github.com/espressif/esp-idf/issues/8179 but my understanding of the doc is that you can access multiple devices (for simplification I mean one device = a peripheral with its own CS line, represented by a handle obtained by spi_bus_add_device) without worrying as long as each device is accessed by a single task.
In other words, the driver does not handle for you concurrent accesses to the same handle that you obtained from spi_bus_add_device() which seems reasonable to me, as it is purely under the control of the user's application.
Now, what I'm observing is that I need to put a global mutex on the SPI host (SPI0..3) for it to work. That sounds counter-intuitive to me because that means, for example, that SPI-to-ethernet devices cannot coexist with anything, unless I patch esp-idf's spi_device_polling_transmit

@philippe44 conclusion is that I'm right. @Spritetm cleared it up. The wording in the docs section I posted the print of is wrong, and "Device" really means bus there, not actually each of the up to 3 devices on the same bus. So it's either using a bus-wide mutex, or a single task governing each bus, or rolling up your own spi_master with actual device-wide mutual exclusion.

@KaeLL thanks for answering. What puzzles me is that all SPI-Ethernet driver are problematic then because they require exclusive usage of an SPI bus, and when you use SPIRAM @ 80MHz, there is only one left. It sounds to me like a big flaw. Of course, I can (and this is what I did) change spi_master to include a mutex per host (if I understand the concept :smile:)
Now, consider the following code
#include <string.h>
#include <stdlib.h>
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "freertos/timers.h"
#include "esp_task.h"
#include "esp_log.h"
#include "esp_heap_caps.h"
#include "driver/spi_master.h"

static char TAG[] = "spi-bug";

spi_device_interface_config_t config;
spi_device_handle_t handle1 = NULL, handle2 = NULL;

bool inTask;
int taskCount, timerCount;

static esp_err_t spi_write(spi_device_handle_t handle, size_t len) {
    spi_transaction_t transaction = { };
	uint8_t *buffer = heap_caps_malloc(len, MALLOC_CAP_SPIRAM);

	transaction.tx_buffer = buffer;
	transaction.length = len*8;

	esp_err_t ret = spi_device_polling_transmit(handle, &transaction);
	free(buffer);
	return ret;
}

static void task(void *arg) {
	while (1) {
		taskCount++;
		inTask = true;
		spi_write(handle2, 1024);
		inTask = false;
	}
}

static void timer(void *arg) {
	static int count = 0;
	if (inTask) {
		//ESP_LOGI(TAG, "Timer (likely) interrupting task");
	}
	timerCount++;
	spi_write(handle1, 128);
}

void app_main()
{
	spi_bus_config_t spi_config = {
		.mosi_io_num = 23,
		.miso_io_num = 19,
		.sclk_io_num = 18,
		.quadwp_io_num = -1,
        .quadhd_io_num = -1
	};

	esp_err_t err = spi_bus_initialize( SPI2_HOST, &spi_config, 1 );
	ESP_LOGI(TAG, "SPI host %d init %d", SPI2_HOST, err);

	memset(&config, 0, sizeof(spi_device_interface_config_t));
    config.clock_speed_hz = SPI_MASTER_FREQ_8M;
	config.clock_speed_hz = 1*1000*1000;
    config.spics_io_num = 22;
    config.queue_size = 10;
	config.flags = SPI_DEVICE_NO_DUMMY;
	err = spi_bus_add_device(SPI2_HOST, &config, &handle1);
	ESP_LOGI(TAG, "SPI device %p %d", handle1, err);

	memset(&config, 0, sizeof(spi_device_interface_config_t));
	config.clock_speed_hz = SPI_MASTER_FREQ_8M;
	config.clock_speed_hz = 1*1000*1000;
    config.spics_io_num = 22;
    config.queue_size = 1;
	config.flags = SPI_DEVICE_NO_DUMMY;
	err = spi_bus_add_device(SPI2_HOST, &config, &handle2);
	ESP_LOGI(TAG, "SPI device %p %d", handle2, err);

	xTaskCreate(task, "task", 4096, NULL, ESP_TASK_PRIO_MIN + 1, NULL);
    xTimerStart(xTimerCreate("timer", pdMS_TO_TICKS(10), pdTRUE, NULL, timer), portMAX_DELAY);

	while(1) {
		ESP_LOGI(TAG, "TaskCount %d TimerCount %d", taskCount, timerCount);
		vTaskDelay(pdMS_TO_TICKS(2000));
    }
}

It's not supposed to be pretty but, knowing that timer task is @ priority 10, shouldn't it fail very often? The low-priority task is saturating the bus with "long" transfers and the timer is interrupting it as frequently as possible. That has been running for a day w/o any issue where the real app with the w5500 driver and a SPI display fails after a few seconds.

@philippe44 conclusion is that I'm right. @Spritetm cleared it up. The wording in the docs section I posted the print of is wrong, and "Device" really means bus there, not actually each of the up to 3 devices on the same bus. So it's either using a bus-wide mutex, or a single task governing each bus, or rolling up your own spi_master with actual device-wide mutual exclusion.

How do you read that in my response there? I'm actually saying the exact opposite: the API is supposed to be threadsafe as long as you keep each one of the 3 devices in the same thread.

That makes sense to me but I was not sure anymore what to think. So yes, I absolutely have a case https://github.com/espressif/esp-idf/issues/8179 where 2 threads access 2 different devices but on the same bus and randomly, after a few seconds, one thinks that it as acquired the lock but if you check right when exiting the spi_bus_lock_acquire_start(), you're not the acquiring device. There is only one call to spi_device_polling_transmit() in my code, the other ones are made by w5500 which have a mutex. Just to be sure, I've traces that there is no re-entrance in my own call to spi_device_polling_transmit(). As long as I put a per-host mutex inside spi_device_polling_transmit() then it will work for hours.

@Spritetm

How do you read that in my response there?

You know what? I have no idea. I'm actually asking myself that same question right now. That's me being stupid again. Thanks for pointing it out and sorry about that. It'll probably happen again.

If you have a case where it's not, that is a bug and it should be fixed.

Great, because I've had it for a year and half now, and I do recall assuming the docs were wrong because, well, I had no reason to believe otherwise, but had suggestions to believe it so.
No one else was complaining about, @lyris85 was the only one who bothered commenting and he reinforced the idea of a bus-wide mutex; the chip runs code, not documentation, so I'm inclined to believe the former rather than the latter, especially regarding a behavior that isn't necessarily a bug by itself, but an inefficiency. So I guess you can see where I'm coming from.