This extends support for the GET STATUS requests to support endpoints
and interfaces as recipient. It also adds the SET and CLEAR FEATURE
requests for the endpoints with support to set and clear the halt
condition on an endpoint.
Instead of directly stalling an endpoint, handlers should enable the
halt condition on an usbus endpoint to signal error condition.
This can then be cleared via a CLEAR FEATURE request from the host.
19460: cpu/stm32/usbdev_fs: fix ep registration and EP_REG assignments r=gschorcht a=dylad
### Contribution description
This PR provides two fixes for the `usbdev_fs` driver:
- Fix endpoints registration
- Fix assignment of toggleable bits in EP_REG(x) registers
These bugs were encountered with the USBUS MSC implementation.
Regarding the endpoints registration:
For the `usbdev_fs` peripheral, IN and OUT endpoints of the same index must have the same type.
For instance, if EP1 OUT is a bulk endpoint, EP1 IN must either be unused or used as bulk too but it cannot be used as interrupt or isochronous.
With the previous check, the following registration pattern (EP OUT Bulk -> EP IN Interrupt -> EP IN Bulk) would assign both EP OUT Bulk and EP IN Interrupt to same endpoint index. So the configuration would be broken.
Applying the same registration pattern with this patch would now produce EP OUT Bulk -> 1 / EP IN Interrupt -> 2 / EP IN Bulk 1. Which is a working configuration for this IP.
and for the second fix:
EP_REG(x) registers have a total of 6 toggleable bits. Those bits can only be toggled if we write a one to it, otherwise writing a zero has no effect
This commit fixes all the access to these registers to prevent from modifying these bits when not needed.
Without this patch, the endpoint status (VALID / NACK / STALL) can be erroneously modify because bits are not cleared when assigning the new content to the register and thus make the bits toggle and change values.
### Testing procedure
This can be tested with tests/usbus_msc on any board using this `usbdev_fs` driver.
It is easier to test this PR with #19443 alongside. Then the following would be enough:
`CFLAGS='-DSECTOR_COUNT=64' USEMODULE='mtd_emulated' make -j8 BOARD=p-nucleo-wb55 -C tests/usbus_msc flash`
Otherwise this can also be tested by attaching a SPI<->SDCARD adapter.
### Issues/PRs references
None.
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
19454: cpu/stm32/periph_gpio_ll: Fix misleading comments r=gschorcht a=maribu
### Contribution description
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.
### Testing procedure
This since only changes comments, this won't effect the binaries. Technically, those comments would be Doxygen compatible comments. But as only Doxygen comments in headers are parsed, these are in practice regular plain comments.
### Issues/PRs references
https://github.com/RIOT-OS/RIOT/pull/19407 added basic GPIO LL support for STM32F1, https://github.com/RIOT-OS/RIOT/pull/19412 added the IRQ support on top of that.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
EP_REG(x) registers have a total of 6 toggleable bits. Those bits can only be toggled if we write a one to it, otherwise writing a zero has no effect
This commit fixes all the access to these registers to prevent from modifying these bits when not needed
Signed-off-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
19458: sys/usbus/msc: fix EP sizes for USB HS and buffer alignment in DMA-mode r=dylad a=gschorcht
### Contribution description
This PR fixes the EP data sizes for the bulk endpoints of USB HS peripherals and the buffer alignment required in DMA mode.
The fixes are required to get USBUS MSC working with USB HS peripherals.
### Testing procedure
The test requires PR #19459.
Connect a SPI SD Card interface with a STM32 board with USB HS port and HS PHY and use `tests/usbus_msc` to test, for example:
```
USEMODULE='sdcard_spi mtd_sdcard_default periph_usbdev_hs_ulpi' \
CFLAGS='-DSDCARD_SPI_PARAM_CLK=GPIO_PIN\(PORT_I,1\) -DSDCARD_SPI_PARAM_MISO=GPIO_PIN\(PORT_B,14\) -DSDCARD_SPI_PARAM_MOSI=GPIO_PIN\(PORT_B,15\) -DSDCARD_SPI_PARAM_CS=GPIO_PIN\(PORT_A,8\)' \
BOARD=stm32f746g-disco make -j8 -C tests/usbus_msc flash
```
SD card should work with this PR.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
For the usbdev_fs peripheral, IN and OUT endpoints of the same index must have the same type.
For instance, if EP1 OUT is a bulk endpoint, EP1 IN must either be unused or used as bulk too but it cannot be used as interrupt or isochronous.
With the previous check, the following registration pattern (EP OUT Bulk -> EP IN Interrupt -> EP IN Bulk) would assign both EP OUT Bulk and EP IN Interrupt to same endpoint index. So the configuration would be broken.
Applying the same registration pattern with this patch would now produce EP OUT Bulk -> 1 / EP IN Interrupt -> 2 / EP IN Bulk 1. Which is a working configuration for this IP
Signed-off-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
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.
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:
![ws281x_esp32_rmt](https://user-images.githubusercontent.com/31932013/227791452-5cc1f95e-04ac-43bb-b11c-f131ab7ab1d5.png)
### 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>