Since the HAW-Hamburg hack and change to the RIOT community server
the HiL is not operating. We should remove it until it is brought
back. likely with some improvements and with different links.
19444: makefiles/tools/serial.inc.mk: Handle new miniterm versions r=maribu a=MrKevinWeiss
### Contribution description
While testing examples/micropython I notice that the default of miniterm.py is actually miniterm. To simplify user setups, this checks for miniterm.py first then falls back to miniterm.
### Testing procedure
Take any board with any newish version of Ubuntu and run
```
make -C flash test examples/micropython
```
If you have `miniterm.py` in `PATH` or if it is `miniterm` both should work.
### Issues/PRs references
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
While testing examples/micropython I notice that the default of miniterm.py is actually miniterm.
To simplify user setups, this checks for miniterm.py first then falls back to miniterm.
19431: cpu/stm32: Fix periph_spi operation in non-DMA mode r=MrKevinWeiss a=maribu
### Contribution description
The driver previously failed to reliably clear the RXNE bit, resulting in the next transfer to incorrectly read a stale register value. This was noticed with the SD card SPI driver on an STM32F4, in which the 0xff byte of the previous byte transfer was returned instead of the actual status byte, throwing the SD card driver off the rails.
### Testing procedure
Connecting an SD card via SPI to a Nucleo-2F429ZI should now result is almost reliable operation.
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
19438: usbus: Add support for full speed with high speed phy r=miri64 a=bergzand
### Contribution description
This adds infrastructure around usbus and usbdev to query the speed of the USB link after enumeration. This as the maximum speed of the link might be slower than the maximum speed of the peripheral. This is the case with the stm32f429i-disco board that has a full speed phy coupled with the high speed peripheral.
This also adds the necessary code to the cdc_ecm code to use the correct packet size. The allocated buffer size is not modified with this PR unfortunately.
### Testing procedure
The `cdc_ecm` handler should work with a HS peripheral coupled with a FS phy.
### Issues/PRs references
Fixes an issue caused by #19358
Co-authored-by: Koen Zandberg <koen@bergzand.net>
19437: boards: fix USB configuration for stm32f429i-disco r=bergzand a=gschorcht
### Contribution description
This PR fixes the problem that CDC ECM is not working for `stm32f429i-disco`.
With PR #19358, the EP data size for CDC ECM bulk endpoints was increased to 512 byte to fix the problem that CDC ECM was not working for boards with USB High-Speed peripherals. Module `periph_usbdev_hs` was introduced to indicate whether a high-speed peripheral is used.
However, the `stm32f429i-disco` board uses a mixture of USB OTG HS peripheral together with the on-hip FS PHY. Using the USB OTG HS peripheral together with a FS-PHY and increasing the EP data size for the CDC ECM bulk endpoint to 512 bytes doesn't work. Therefore, module `periph_usbdev_hs` is not used for now to workaround the problem. Thus, the maximum number of EPs used is that of the USB OTG FS peripheral, which is only 4. This is not sufficient for this test application since the board uses `stdio_cdc_acm`. The board is therefore blacklisted.
### Testing procedure
Use a `stm32f429i-disc1` or a `stm32f429i-disco` board and flash the test app:
```
USEMODULE=stdio_uart BOARD=stm32f429i-disco make -j8 -C tests/usbus_cdc_ecm flash
```
With this PR it should be possible to ping the board.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
The board no longer uses the `periph_usbdev_hs` module. Therefore, the maximum number of EPs used is that of the USB OTG FS peripheral, which is only 4. This is not sufficient for this test application since the board uses `stdio_cdc_acm`.
The board uses the USB OTG HS peripheral together with the on-hip FS PHY. Using the `periph_usbdev_hs` module increases the EP data size for the CDC ECM bulk endpoint to 512 bytes, which does not work for the FS interface. Module `periph_usbdev_hs` is therefore not used.
19417: boards/esp32c3-wemos-mini: add support for Wemos ESP32-C3 mini r=benpicco a=gschorcht
### Contribution description
This PR provides the support for the [Wemos ESP32-C3 mini](https://www.wemos.cc/en/latest/c3/c3_mini.html) board.
### Testing procedure
The board should work for provided features.
The board was already tested with:
- [x] `tests/driver_sht3x` using I2C
- [x] `tests/driver_l3gxxxx` using SPI
- [x] `tests/periph_adc`
- [x] `tests/periph_pwm`
- [ ] `tests/driver_ws281x`
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
The driver previously failed to reliably clear the RXNE bit, resulting
in the next transfer to incorrectly read a stale register value. This
was noticed with the SD card SPI driver on an STM32F4, in which the
0xff byte of the previous byte transfer was returned instead of the
actual status byte, throwing the SD card driver off the rails.
19424: drivers/ws281x: add RMT hardware support for ESP32x SoCs r=maribu a=gschorcht
### Contribution description
This PR provides support for ESP32x RMT that is used to generate WS2812B signals.
All ESP32x SoCs have a [Remote Control Peripheral (RMT)](https://docs.espressif.com/projects/esp-idf/en/v4.4.4/esp32/api-reference/peripherals/rmt.html) that can be used to generate digital waveforms, such as NEC remote control signals or WS2812B RGB LED signals. Each RMT peripheral has either 4 or 8 channels. Some ESP32x SoCs support configuring the clock sources used for each channel separately, while other ESP32x SoCs can only use a single clock source for all channels.
The advantages using the RMT are that the CPU is not busy when generating the WS218x signal and the phase times are accurate to nanoseconds. The disadvantage is that the configuration of the RMT is so complex due to its flexibility that the [ESP-IDF high-level driver for RMT](https://docs.espressif.com/projects/esp-idf/en/v4.4.4/esp32c3/api-reference/peripherals/rmt.html) is used.This requires about 6 kBytes more ROM, about 3 kBytes more IRAM, and 88 bytes more RAM.
Therefore, either the RMT hardware implementation (module `ws2812x_esp32_hw`) as well as the bit-banging software implementation (module `ws2812x_esp32_hw`) can be used. RMT hardware implementation (module `ws2812x_esp32_hw`) is used by default.
Timing with hardware implementation:
### Testing procedure
`tests/driver_ws281x` should still work, for example:
```
CFLAGS='-DWS281X_PARAM_PIN=GPIO45 -DWS281X_PARAM_NUMOF=47' BOARD=esp32s3-devkit make -j8 -C tests/driver_ws281x flash
```
Test Output:
https://user-images.githubusercontent.com/31932013/227791753-e6d2924e-3364-4387-870f-a56d3a9a8a80.mp4
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19425: drivers/servo: Fix typo in comment r=benpicco a=maribu
### Contribution description
As the title says
### Testing procedure
Not needed; code review will confirm that this is a comment only change.
### Issues/PRs references
None
19426: cpu/esp32: cleanup of ESP-IDF interface API (module `esp_idf_api`) r=benpicco a=gschorcht
### Contribution description
This PR cleans up the wrapper library (module `esp_idf_api`) that is used to interface to ESP-IDF driver modules.
A number of ESP-IDF header files needed to compile RIOT include the ESP-IDF header file `driver/gpio.h` only because of the definition of the type `gpio_num_t`. However, `driver/gpio.h` does not only define `gpio_num_t` but the complete ESP-IDF GPIO API which conflicts with that in RIOT. The solution was to use a wrapper library when compiling the RIOT code that does not need to include the ESP-IDF header file `driver/gpio.h`. The disadvantage of this approach was that for each ESP-IDF function to be used in RIOT, a corresponding function in the wrapper library had to be defined which does nothing else than calling the corresponding ESP-IDF function.
This PR provides another approach which does not require such a wrapper library in most cases and allows to clean up the wrapper library (module `esp_idf_api`). It just provides its own `driver/gpio.h` that is included by ESP-IDF header files instead of the original ESP-IDF header file `driver/gpio.h`. It defines only the required `gpio_num_t` when RIOT code is compiled but includes the original ESP-IDF header file `driver/gpio.h` when ESP-IDF code is compiled. As a result. most of the functions in the wrapper library could be eliminated. A further advantage is that further ESP-IDF API functions can be used without defining corresponding wrapper functions.
### Testing procedure
Green CI
### Issues/PRs references
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19369: sys/cpp11-compat: Remove xtimer deps r=MrKevinWeiss a=MrKevinWeiss
### Contribution description
This replaces the `xtimer` calls with explicit `ztimer64` calls, since `xtimer` is somewhat deprecated.
### Testing procedure
- Green murdock
- I suppose the following `tests/`
```
c11_atomics_cpp_compat
cpp11_condition_variable
cpp11_mutex
cpp11_thread
cpp_ctors
cpp_exclude
cpp_ext
irq_cpp
rmutex_cp
```
- run `compile_and_test_for_board.py` and `compile_like_murdock.py` for the subset of tests.
### Issues/PRs references
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
19370: Fix `compile_like_murdock.py` when board is empty r=MrKevinWeiss a=MrKevinWeiss
### Contribution description
Turns out we didn't test the simplest case, board being empty.
I added some automatic testing to check that and we can build when needed...
### Testing procedure
Green `tools-test` action
### Issues/PRs references
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
A number of ESP-IDF header files that are needed to compile RIOT include the header file `driver/gpio.h` only because of the definition of the type `gpio_num_t`. However, this header file contains the entire GPIO API definition of the ESP-IDF, which conflicts with that of RIOT.
The solution was to use a wrapper library that does not need to include the `driver/gpio.h` file of the ESP-IDF during compilation of RIOT code.
This commit provides another approach which does not require such a wrapper library. It just provides its own `driver/gpio.h` in RIOT that is included by ESP-IDF header files instead of the original `driver/gpio.h` in ESP-IDF. It defines only the required `gpio_num_t` if RIOT code is compiled but includes the original `driver/gpio.h` of ESP-IDF if ESP-IDF code is compiled. This avoids to create a wrapper library for each module.
19422: drivers/ws281x: improve timing for ESP32x r=maribu a=gschorcht
### Contribution description
This PR provides a small change which improves the timing for ESP32x SoCs.
If overhead like the loop control or the calculation of the waiting times for the next bit are performed while waiting for the end of the LOW phase, the time required for such operations is included in the LOW phase. This makes both the LOW phase and the period more precise.
According to the definitions
```c
#define WS281X_T_DATA_NS (1250U)
#define WS281X_T_DATA_ONE_NS (650U)
#define WS281X_T_DATA_ZERO_NS (325U)
```
the following timing is used:
| Parameter | Value | Master | this PR |
|:-------------|------:|-------:|--------:|
| 1-Bit Period | 1250 | 1820 | 1400 |
| 1-Bit HIGH | 650 | 690 | 710 |
| 1-Bit LOW | 600 | 1130 | 690 |
| | | | |
| 0-Bit Period | 1250 | 1880 | 1400 |
| 0-Bit HIGH | 350 | 380 | 400 |
| 0-Bit LOW | 900 | 1500 | 1000 |
Timing with current master:
Timing with this PR:
### Testing procedure
`tests/driver_ws281x` should still work.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
If overhead like the loop control or the calculation of the waiting times for the next bit are performed while waiting for the end of the LOW phase, the time required for such operations is included in the LOW phase. This makes both the LOW phase and the period more precise.
19420: cpu/esp32: use ets_printf instead of puts in startup r=maribu a=gschorcht
### Contribution description
This PR provides a workaround that fixes the problem that restarting an application automatically after flashing it in download mode via USB Serial/JTAG doesn't work and requires a hard reset by pressing the RESET button before it starts.
The reason that the application doesn't restart automatically after flashing it is that an exception occurs if `puts` or `printf` is called during startup before the first interrupt driven context switch in `thread_yield_higher`. The console seems to hange after bootloader:
```
EESP-ROM:esp32c3-api1-20210207
Build:Feb 7 2021
rst:0x15 (USB_UART_CHIP_RESET),boot:0xd (SPI_FAST_FLASH_BOOT)
Saved PC:0x40380786
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6100,len:0x6c
load:0x403ce000,len:0x7ec
load:0x403d0000,len:0x2170
entry 0x403ce000
Pro cpu up.
```
However, the system stucks in a exception/printf loop. ESP32-C3 and ESP32-S3 are affected.
### Testing procedure
Flash a ESP32-C3 or ESP32-S3 board that don't have a USB-to-UART chip with reset logic on board, for example
```
BOARD=hip-badge make -j8 -C tests/shell flash
```
or
```
BOARD=esp32s3-pros3 make -j8 -C tests/shell flash
```
Connect a terminal to the the board. Without the PR, the console doesn't seem to work and the RESET button has to pressed explicitly to get it working. With the PR, the console should work.
The problem can also be caused when using
```
dist/tools/esptools/espreset.py -p /dev/ttyACM0
```
while connected with a terminal to the board. Without the PR, the console output stops after
```
ESP-ROM:esp32c3-api1-20210207
Build:Feb 7 2021
rst:0x15 (USB_UART_CHIP_RESET),boot:0xd (SPI_FAST_FLASH_BOOT)
Saved PC:0x40380786
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6100,len:0x6c
load:0x403ce000,len:0x7ec
load:0x403d0000,len:0x2170
entry 0x403ce000
Pro cpu up.
```
while it continues with the PR as following:
```
main(): This is RIOT! (Version: 2023.04-devel-713-gcb721-boards/
test_shell.
>
```
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
