When FreeRTOS semaphores, as required by ESP-IDF, are used together with `gnrc_netif`, RIOT may crash if `STATUS_RECEIVE_BLOCKED` is used as a blocking mechanism in the FreeRTOS adaptation layer. The reason for this is that `gnrc_netif` uses thread flags since PR #16748. If the `gnrc_netif` thread is blocked because of a FreeRTOS semaphore, and is thus in `STATUS_RECEIVE_BLOCKED` state, the `_msg_send` function will cause a crash because it then assumes that `target->wait_data` contains a pointer to a message of type `msg_t`, but by using thread flags it contains the flag mask. This situation can happen if the ESP hardware is used while another thread is sending something timer controlled to the `gnrc_netif` thread.
To solve this problem `STATUS_MUTEX_LOCKED` is used instead of `STATUS_RECEIVE_BLOCKED` and `STATUS_SEND_BLOCKED`
To reduce the required RAM in default configuration, the BLE interface is used as netdev_default instead of ESP-NOW. Further network interfaces can be enabled with the modules `esp_now`, `esp_wifi` or `esp_eth`.
A if `netdev_driver_t::confirm_send()` is provided, it provides the
new netdev API. However, detecting the API at runtime and handling
both API styles comes at a cost. This can be optimized in case only
new or only old style netdevs are in use.
To do so, this adds the pseudo modules `netdev_legacy_api` and
`netdev_new_api`. As right now no netdev actually implements the new
API, all netdevs pull in `netdev_legacy_api`. If `netdev_legacy_api` is
in used but `netdev_new_api` is not, we can safely assume at compile
time that only legacy netdevs are in use. Similar, if only
`netdev_new_api` is used, only support for the new API is needed. Only
when both are in use, run time checks are needed.
This provides two helper function to check for a netif if the
corresponding netdev implements the old or the new API. (With one
being the inverse of the other.) They are suitable for constant folding
when only new or only legacy devices are in use. Consequently, dead
branches should be eliminated by the optimizer.
The former FLASH_MODE_{DOUT,DIO,QOUT,QIO} defines are replaced by the corresponding CONFIG_FLASHMODE_{DOUT,DIO,QOUT,QIO} and CONFIG_ESPTOOLPY_FLASHMODE_{DOUT,DIO,QOUT,QIO} as used by the ESP-IDF. This is also needed for the migration of defining flash mode in Kconfig.
ESP32x SoC use either Xtensa cores or RISC-V cores. The Xtensa vendor code has to be compiled only for ESP32x SoCs that are Xtensa-based. Therefore, MODULE_XTENSA has to depend on HAS_ARCH_ESP_XTENSA instead of HAS_ARCH_ESP
Fixed delay values are replaced by calculated delays measured in CPU cycles in I2C software implementation. The advantage is that for each ESP SoC only a clock calibration offset has to be specified. The delay measured in CPU cycles are then then derived from current CPU frequency for the given bus speed. The disadvantage is that the calculated delays are not as precise as the predefined fixed delays.
This commit changes periph/uart to use ESP-IDF API for ESP32x SoCs. Furthermore, the MCU_* conditionals are inverted so that they can be tested for ESP8266. In all other cases the MCU is any ESP32x SoC
To allow a platform independent implementation of exceptions for different ESP32x SoC variants, the platform specific code for Xtensa based ESP SoCs is moved to a separate platform file `exception_xtensa.c`.
To allow a platform independent implementation of irq_arch for different ESP32x SoC variants, the platform specific code for Xtensa based ESP SoCs is moved to a separate module `esp_xtensa`.
To allow a platform independent implementation of tread_arch for different ESP32x SoC variants, the platform specific code for Xtensa based ESP SoCs is moved to a separate module `esp_xtensa`.
