Parsing and generating code
This folder contains scripts for parsing esp_wifi component headers and configs and generates configs, headers and sources of esp_wifi_remote.
The CI job runs the parse and generation step, after which the generated files appear locally in this folder. Then the CI jobs compares the generated files with the specific version files. In case of a mismatch (CI failure), please check if the generated file is correct. If so, update the component and create a new version. If not, update the scripts.
Parsing esp_wifi headers
Extract prototypes from the selected wifi headers
Generating Kconfig
- Kconfig -- we only replace SOC_WIFI_->SLAVE_SOC_WIFI_andIDF_TARGET_->SLAVE_IDF_TARGET_configs
- Kconfig.soc_wifi_caps.in -- we parse IDF/components/soc/$SLAVE/include/soc/Kconfig.soc_caps.infor all slaves and collectSOC_WIFI_configs, which we enclose withif SLAVE_IDF_TARGET......endif. This way the slave's WiFi capabilities become runtime available inesp_wifi_remotesubmenu
Generating headers and forwarding to esp_hosted
Based on extracted WiFi function prototypes we generate
- esp_wifi_remote_api.h-- declares all wifi APIs with- esp_wifi_remote...()prefix
- esp_wifi_with_remote.c-- defines all original wifi APIs that forward calls for- esp_wifi_remote-- This file is used only for targets with no WiFi capabilities, so the original WiFi APIs could be called the same way as on WiFi targets. (this file is not compiled for targets with WiFi caps)
- esp_wifi_remote_with_hosted.h-- defines- static inlinefunctions that directly forward calls from- esp_wifi_remoteto- esp_hosted
Generating slave's WiFi native types
- esp_wifi_types_native.h-- defines specific WiFi types based on the selected WiFI slave and its capabilities. We use the original header and only replace- CONFIG_SOC_WIFI_->- CONFIG_SLAVE_SOC_WIFI_and- CONFIG_IDF_TARGET_->- CONFIG_SLAVE_IDF_TARGET_configs
Generating test cases
This component includes a simple build-only test that exercises all APIs from esp_wifi_remote (and also from esp_wifi). The test is also generated by the same script, since we know the function prototypes, so we could tell what parameters we call the exercised APIs.
This test includes a mocked version of the esp_hosted component, so the generated files are:
- esp_hosted_mock.c-- all WiFi APIs to just return a default value (typically- ESP_OK)
- esp_hosted_mock.h-- declares all WiFi related APIs
- Kconfig-- selection of all SLAVE targets (with WiFi capabilities)
- all_wifi_calls.c-- calls all WiFi APIs (to check that targets without WiFi caps can use the original APIs)
- all_wifi_remote_calls.c-- calls all remote WiFi APIs (to check that also the targets with WiFi caps can use the remote wifi functionality)