- feat(soc_caps): Enable BT Classic and BLE in esp32s31
- Add git submodule for ESP32-S31 bt controller lib files
- changed sdkconfig.defaults and README for Bluetooth Classic examples
- change(docs): Added vendor HCI documentations for ESP32-S31
- change(Bluedroid): Adapt to ESP32-S31 due to some API differences on
Bluetooth controller from ESP32
- change(bt): Modify CMakeLists.txt to support the Bluetooth dual-mode
architecture on ESP32-S31
- change(bt): Add ECC P-192 functions to tinycrypt
Where actually building the app is not needed cmake reconfigure was introduced instead.
This should be performance upgrade especially for Windows runners, where build is quite slow
Add a check_api_compatibility CI job that uses esp-api-check to detect
breaking API changes in merge requests. The job compares API
declarations between the MR base and head commits using libclang, and
posts a discussion thread on the MR if WARNING or BREAKING changes are
found.
- Add CI job in host-test.yml with clang toolchain and allow_failure
- Add test_api_check project for CMake configuration with all
components enabled
- Define __DOXYGEN__ and IDF_DOC_BUILD so the checker can see
declarations behind these guards
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Replace the peripherals index USB entries with direct links to
ESP-USB so the generated pages are no longer redirect-only stubs.
Keep legacy USB URLs working via redirects, including the
individual USB host maintainer notes pages.
Remove the obsolete placeholder documents and stale CODEOWNERS
pattern.
Mark the moved USB examples as KNOWN_MISSING in the example
documentation checker until it can also read the ESP-USB guide.
Remove USB Host/Device content from ESP-IDF pages and keep only links to
ESP-USB documentation.
Add redirects for legacy USB pages to ESP-USB with target-aware URL
substitution in docs config.
Drop obsolete USB host notes references from docs_not_updated lists.
Initial step of migration of esp-wifi-remote to IDF
This cannot be an official component, as it would colide with the
existing managed esp_wifi_remote.
This needs to be an additional functionality of esp_wifi (subdirectory)
used in these 3 scenarios:
* Adding remote functionality esp_wifi() APIs to chips without WiFi
(esp32p4, h2,...)
* Additional WiFi interface for chips which already have WiFi
* Genuine WiFi interface for linux target host applications
The ownership of WiFi's remote functionality will be transfered back
to the wifi team after the migration and stabilization.
wangmengyang
Fu Hanxi
Linyan Liu
igor.udot
C.S.M
Island
ShenWeilong
Daniel Paul
Tomas Rohlinek
Jakub Kocka
Ma Jing Jing
Tomas Rezucha
Ivan Grokhotkov
Ivan Grokhotkov (bot)
igor.masar
Sudeep Mohanty
Marius Vikhammer
David Čermák
Roland Dobai
Frantisek Hrbata