Although ESP32 has four SPI controllers, only two of them can be effectively used (HSP and VSPI). The third one (FSPI) is used for external memory such as flash and PSRAM and can not be used for peripherals. FSPI is therefore removed from the API. In addition, the SPI0_DEV and SPI1_DEV configuration parameters are renamed SPI0_CTRL and SPI1_CTRL to better describe what they define and to avoid confusion with SPI_DEV (0) and SPI_DEV (1).
Although ESP32 has four SPI controllers, only two of them can be effectively used (HSP and VSPI). The third one (FSPI) is used for external memory such as flash and PSRAM and can not be used for peripherals. FSPI is therefore removed from the API. In addition, the SPI0_DEV and SPI1_DEV configuration parameters are renamed SPI0_CTRL and SPI1_CTRL to better describe what they define and to avoid confusion with SPI_DEV (0) and SPI_DEV (1).
cpu/esp32/include/periph_cpu.h overrides the default definition of adc_res_t from periph/adc with a definition which contains only four resolution, two new resolutions and two resolutions defined by the default definition of adc_res_t. This gives compilation errors if an application uses other resolutions. According to the documentation, adc_sample should return -1 if the resolution is not supported. All other CPUs override adc_res_t either to add new resolutions or to mark resolutions as unsupported. But they all allow to use them at the interface. Therefore, esp32 overrides now the definition of adc_res_t with all resolutions that are defined by the default definition of adc_res_t and new platform specific resolutions. It returns -1 if a resolution is used in adc_sample that is not supported.
This commit adds the ESP32 vendor libraries for WLAN to the BASELIBS variable. This avoids having to define an additional archive group in the LINKGFLAGS variable which contains these vendor libraries and again RIOT module archive files with the symbols that are refered by these vendor libraries.
Some ESP32 boards (like my SparkFun ESP32 Thing) have a main clock
crystal that runs at 26MHz, not 40MHz. RIOT appears to assume 40MHz.
The mismatch causes the UART to not sync properly, resulting in
garbage written to the terminal instead of log output.
I’ve added:
* A new board configuration constant ESP32_XTAL_FREQ that defaults
to 40, but can be overridden by a board def or at build time to
force a specific value (i.e. 26).
* Some code spliced into system_clk_init() to check this constant and
call rtc_clk_init() to set the correct frequency.
* A copy of the rtf_clk_init() function from the ESP-IDF sources.
Fixes#10272
The problem seemed to be a pipelining problem of write and read instructions when swapping the context. An isync instruction when returning from a context switch solves the potential pipelining problem.
Reason for the problem was that tast_exit function in thread_arch.c tried to release the thread a second time although it was already released in sched_task_exit. A simple check whether the thread is already released (sched_active_thread == NULL) solved the problem.
Xtensa newlib version requires pthread_setcancelstate as symbol. Therefore, the module pthread was always used, which in turn requires the module xtimer. The xtimer module, however, uses TIMER_DEV(0). Therefore, tests/timers failed for TIMER_DEV(0).
