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`.
Assertions for uninitialized locks must not be triggered as long as the scheduler is not running. Furthemore, the handling of the __malloc_static_object lock is only necessary for ESP8266.
The directory `dist/tools/esptool` already contains a couple of ESP tools and not only esptool.py. As the location for a couple of ESP related tools, it is more clear to call it `esptools` instead of `esptool`.
Module `esp_idf_nvs_flash` uses C++ code. Since `esp_idf_nvs_flash` module is always enabled on ESP8266, the permanent dependency on `cpp` is correct. But on ESP32, the `esp_idf_nvs_flash` module is only enabled if `esp_wifi_any` is used. Only in that case the compilation should depend on module `cpp`.
The vendor binary libraries of ESP-IDF are provided as a separate GIT repository. These libraries are defined as separate package for two reasons: 1. RIOT packages don't support to clone GIT repositories recursively; 2. ESP-IDF pulls a lot of other GIT repositories that are not needed when it is cloned recursively.
Previously, a default value for ESP_WIFI_PASS was intentionally defined only if DOXYGEN was also defined, to allow ESP_WIFI_PASS to be left undefined for using APs without authentication. With PR #17415 the definition was changed to always define a default value for EPS_WIFI_PASS. This made it impossible to use APs without authentication. The commit reverts this change.
The semantics of defining an SSID prefix that overrides the already defined SSID exactly when and only when it is set, and then enabling dynamic SSID generation with that prefix, made handling the parameter definition unnecessarily difficult and hard to understand.
Defining a boolean option that enables dynamic SSID generation, which then simply reuses the defined SSID as a prefix, makes it much more understandable and easier to handle, especially with respect to Kconfig.
On the ESP32 it is often not possible with the I2C software implementation to communicate with an AIP31068 based LCD module. Therefore, the I2C hardware implementation is enabled when the AIP31068 driver is used, but it is more buggy than stable. The timing of the two implementations seems to be almost identical. The only difference is that the hardware implementation clears the bus before each access by sending 10 clock pulses on the SCL line while SDA is LOW. Using the same mechanism during I2C initialization for the software implementation solves the communication problem with the AIP31068.
The same software implementation works reliably with the AIP31068 on the ESP8266.
cpu/esp_common/syscalls.c💯 error (memleak): Memory leak: mtx
cpu/esp_common/syscalls.c:131: error (memleak): Memory leak: rmtx
cpu/esp_common/syscalls.c:365: error (comparePointers): Subtracting pointers that point to different objects
cpu/esp_common/thread_arch.c:355: error (comparePointers): Comparing pointers that point to different objects
cpu/esp8266/startup.c:59: error (comparePointers): Subtracting pointers that point to different objects
RIOT-OS uses part of Espressif ESP8266 RTOS SDK to build support for
this CPU. The SDK includes some vendor-provided closed source
pre-compiled libraries that we need to modify to adapt to RIOT-OS
usage. This library modifications was done once and uploaded to a fork
of the vendor repository and was provided as an environment variable.
This patch changes two things:
1. It installs the SDK as a RIOT PKG from the new pkg/esp8266_sdk
directory instead of requiring the user to download it separately.
2. It performs the library modifications (symbol renames) on the pkg
Makefile removing the need to use a fork with the modifications applied
and simplifying the SDK update and future modifications.
This change sets the SDK package version (git SHA) to the same one that
our fork was using as a parent in the vendor repository, meaning that
the output libraries are exactly the same as before.
Tested with
```
ESP8266_RTOS_SDK_DIR=/dev/null USEMODULE=esp_log_startup make -C tests/shell BOARD=esp8266-esp-12x flash
```
and verified that the program works. The boot message now includes:
```
ESP8266-RTOS-SDK Version v3.1-51-g913a06a9
```
confirming the SDK version used.
`/dev/null` in the test is just to make sure that no evaluation of
`ESP8266_RTOS_SDK_DIR` in make is affected by the environment variable
value which would be set to the SDK for people who followed the set up
instructions before this change.
Tested the checkout size:
```bash
$ du -hs build/pkg/esp8266_sdk/
124M build/pkg/esp8266_sdk/
```
If esp_idf_heap is not used, implement calloc through a custom wrapper
function on top of malloc to add overflow detection, which is not
present in the newlib forks with xtensa support yet.
