Repository navigation
[bsp][esp32] fix FreeRTOS include order for C3/C6 builds - #11926
BernardXiong wants to merge 2 commits into
Conversation
ESP-IDF's scons shim forwards <freertos/FreeRTOS.h> with #include_next, so RT-Thread's FreeRTOS-Wrapper must be searched after the shim but before ESP-IDF's own FreeRTOS-Kernel V11 copy. Package SConscripts are evaluated in directory order, which is not stable. When the ESP-IDF package happens to be evaluated first, #include_next resolves the V11 kernel header and the Wrapper configuration defaults are never applied, so the ESP32-C3/C6 builds fail with: #error Missing definition: configNUMBER_OF_CORES ... #error Missing definition: configMINIMAL_STACK_SIZE ... Move the Wrapper include directories back to the position right after the shim after PrepareBuilding(), in both BSPs, using a shared helper. Verified on the ESP32-C3/C6 BSPs by forcing the failing package order: drv_uart.c reports the errors above before the change and compiles after it. Co-authored-by: DeepSeek 4.1 Flash <noreply@deepseek.com>
|
👋 感谢您对 RT-Thread 的贡献!Thank you for your contribution to RT-Thread! 为确保代码符合 RT-Thread 的编码规范,请在你的仓库中执行以下步骤运行代码格式化工作流(如果格式化CI运行失败)。 🛠 操作步骤 | Steps
完成后,提交将自动更新至 如有问题欢迎联系我们,再次感谢您的贡献!💐 |
|
Wi-Fi/BLE attachconfigs add ESP-IDF's components/freertos/config/include to the include path, and it was searched before the BSP's idf_port/include/freertos. The Wrapper's FreeRTOS.h then picked ESP-IDF's FreeRTOSConfig.h, whose configTASK_NOTIFICATION_ARRAY_ENTRIES maps to CONFIG_FREERTOS_TASK_NOTIFICATION_ARRAY_ENTRIES -- a symbol the RT-Thread sdkconfig shim does not define -- and the ESP32-C3 BLE/Wi-Fi builds failed with "configTASK_NOTIFICATION_ARRAY_ENTRIES must be at least 1". Move the BSP idf_port include directories together with the Wrapper include directories, so the BSP configuration is used. Verified with the ESP32-C3 devices.ble and devices.wifi attachconfigs: idf_port/src/port.o fails before the change and compiles after it. Co-authored-by: DeepSeek 4.1 Flash <noreply@deepseek.com>
|
让 AI 把 idf 改成 scons 不就好了 |
拉取/合并请求描述:(PR description)
为什么提交这份PR (why to submit this PR)
master 上的 ESP32-C3/C6 构建当前失败,并导致所有 PR 的
RT-Thread BSP Static Build Check和MemBrowse Memory Report出现相同的红色检查(已在 master 的 run40043597502、39929831359复现)。根因是 ESP-IDF 包中的 scons shim
components/rtthread/scons/include/freertos/FreeRTOS.h使用#include_next转发<freertos/FreeRTOS.h>,要求 RT-Thread 的 FreeRTOS-Wrapper include 目录位于 shim 之后、ESP-IDF 自带的components/freertos/FreeRTOS-Kernel/include(FreeRTOS V11)之前。但两个包的 SConscript 由目录顺序决定加载顺序,而目录顺序并不稳定。当 ESP-IDF 包先被加载时,
#include_next解析到 V11 内核头,Wrapper 提供的配置默认值(configNUMBER_OF_CORES、configMINIMAL_STACK_SIZE、configUSE_PREEMPTION等)未生效,编译libraries/drivers/drv_uart.c时报:你的解决方案是什么 (what is your solution)
bsp/ESP/tools/freertos_include.py;PrepareBuilding()之后,把 FreeRTOS-Wrapper 的 include 目录移动到 ESP-IDF shim 之后、FreeRTOS-Kernel 之前;idf_port/include/idf_port/include/freertos前移。Wi-Fi/BLE attachconfig 会引入 ESP-IDF 的components/freertos/config/include,原先它排在 BSP 配置之前,会选中 ESP-IDF 的FreeRTOSConfig.h,导致configTASK_NOTIFICATION_ARRAY_ENTRIES未定义;ESP32_C3与ESP32_C6的SConstruct中调用该辅助函数。不修改 ESP-IDF 包本身,也不依赖包的加载顺序。
请提供验证的bsp和config (provide the config and bsp)
BSP: bsp/ESP/ESP32_C3, bsp/ESP/ESP32_C6
.config: 默认配置(
pkgs --update-force后构建)action: 本地复现并验证:
ESP-IDF-latest先于FreeRTOS_Wrapper-latest加载(即 CI 失败时的顺序);drv_uart.o报出与 CI 完全相同的FreeRTOSConfig.h缺失定义错误;ESP32_C3和ESP32_C6的drv_uart.o均编译通过;ESP32_C3的devices.ble和devices.wifiattachconfig:修复前idf_port/src/port.o报configTASK_NOTIFICATION_ARRAY_ENTRIES错误,修复后编译通过。同时确认修复后 include 顺序为:
当前拉取/合并请求的状态 Intent for your PR
必须选择一项 Choose one (Mandatory):
代码质量 Code Quality:
我在这个拉取/合并请求中已经考虑了 As part of this pull request, I've considered the following:
#if 0代码,不包含已经被注释了的代码 All redundant code is removed and cleaned up