The comments still claim STM32F1 support is missing, but this was
recently added.
Also, drop an empty line to fix `too many consecutive empty lines`
nitpick of the CI.
19455: usbus/msc: fixes for synopsys dwc2 driver r=gschorcht a=dylad
### Contribution description
This PR provides two fixes for USBUS MSC driver.
9e88db7 removes a call to `usbdev_control_slicer_ready()` as this function is called by USBUS stack right after so remove this call to avoid duplication.
608d49c moves the call to `usbdev_ep_xmit()`, which prepares the bulk MSC OUT endpoint to receives data, from the `_init()` function to `USB_MSC_SETUP_REQ_GML` control request. The issue was that this endpoint was prepare to early and an USB reset might reset this setting. (This is the case for the `usbdev_synopsys_dwc2` driver) Thus the endpoint is not ready to receive data when the host send it.
### Testing procedure
Test this PR with `tests/usbus_msc` on any board using the `usbdev_synopsys_dwc2` driver **with a FS PHY**
There is another issue with HS PHY that should be fix too.
### Issues/PRs references
None.
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
This function should not be called by the driver as USBUS will handle it already. So remove this call to prevent duplication
Signed-off-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
19453: README.md: Remove HiL Badge r=aabadie a=MrKevinWeiss
### Contribution description
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.
### Testing procedure
Before this PR: click on it and be sad
After PR: Forget your sorrows
### Issues/PRs references
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
19446: cpu/stm32: Fix periph_gpio_ll_irq r=MrKevinWeiss a=maribu
### Contribution description
This fixes a high impact typo that broke GPIO LL IRQ support on a bunch of STM32 families.
### Testing procedure
```
make BOARD=nucleo-f429zi flash test-with-config -j16 -C tests/periph_gpio_ll
[...]
TEST SUCCEEDED
```
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
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.
The commit moves the header files from `boards/common/esp32s3/include` that can be used for all types of ESP32x SoCs to a new common ESP32x board module.
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>
