To allow CPU specific definitions in `cpu.h`, `riscv_common/cpu.h` is renamed to ``riscv_common/cpu_common.h` and included in new `cpu.h` files for FE310 and GD32V.
19450: cpu/esp32: fix compilation issues with GCC 12.2 r=benpicco a=gschorcht
### Contribution description
This PR provides the changes in `cpu/esp32` and `cpu/esp_common` to fix the compilation issues with GCC v12.2. It is required as the first step in the preparation of the upgrade to ESP-IDF version 5.1.
**Please note**: Insead of fixing the ESP-IDF 4.4 code itself by a big bunch of patches to fix the compilation problems with GCC v12.2, it temporarily disables some warnings. The reason is that the ESP-IDF 5.1 requires GCC v12.2 and should be fixed for this compiler version by the vendor.
### Testing procedure
Green CI
The change were already tested with all ESP-specific modules like `esp_now`, `esp_wifi`, `esp_spi` and `esp_ble` for all supported ESP platforms.
### Issues/PRs references
Prerequisite for https://github.com/RIOT-OS/riotdocker/pull/227
Fixes issue #19421
19476: native/syscalls: rename real_clock_gettime to clock_gettime r=benpicco a=Teufelchen1
### Contribution description
When compiling RIOT for native using a recent LLVM and enabling ASAN, one might encounter "Duplicated symbol".
This is due to a name clash with `real_clock_gettime()` in compiler-rt from [LLVM](f50246da65), I renamed RIOTs `real_clock_gettime` and just default to the posix function `clock_gettime`. The wrapper existed, most likely, for consistency only.
(The best solution would probably to convince the LLVM folks to declare their symbol as `static` and refactor a bit)
### Testing procedure
Passing CI should be enough.
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Teufelchen1 <bennet.blischke@haw-hamburg.de>
Since the USB OTG FIFO sizes are partly defined in 32-bit words and partly in bytes, the documentation of the of the USB OTG FIFO size definitions is extended by the respective unit.
Since the USB OTG FIFO sizes are partly defined in 32-bit words and partly in bytes, the documentation of the of the USB OTG FIFO size definitions is extended by the respective unit.
Since the USB OTG FIFO sizes are partly defined in 32-bit words and partly in bytes, the documentation of the of the USB OTG FIFO size definitions is extended by the respective unit.
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>
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>
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.
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.
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.
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>
19397: drivers/usbdev_synopsys_dwc2: fix and reenable DMA mode r=benpicco a=gschorcht
### Contribution description
This PR fixes the DMA mode for all STM32 USB OTG HS cores (including that for STM32F4xx CID 1.xxx) and reenables it. It fixes remaining problems in issue #19359.
This PR includes also includes some changes that are needed to use the DMA mode:
- EP number is used as defined in CMSIS (if defined) for STM32
- `periph_usbdev_hs` feature is added in Kconfig
- `periph_usbdev_hs` feature is added in board definition of `stm32f429i-disc1`
- largest number of available EPs is used for STM32 instead of the smallest number (to be able to use all EPs of HS peripheral)
- `stm32f429i-disco` is removed from blacklist in `tests/usbus_cdc_ecm` since it uses the HS peripheral
### Testing procedure
The following tests should work
```python
USEMODULE=stdio_cdc_acm BOARD=stm32f429i-disc1 make -j8 -C tests/usbus_cdc_ecm flash
```
<details>
<summary>Test results</summary>
```python
[526755.875691] usb 1-2.2: new full-speed USB device number 106 using xhci_hcd
[526755.977853] usb 1-2.2: config 1 interface 3 altsetting 1 endpoint 0x84 has invalid maxpacket 512, setting to 64
[526755.977856] usb 1-2.2: config 1 interface 3 altsetting 1 endpoint 0x2 has invalid maxpacket 512, setting to 64
[526755.978762] usb 1-2.2: New USB device found, idVendor=1209, idProduct=7d01, bcdDevice= 1.00
[526755.978764] usb 1-2.2: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[526755.978766] usb 1-2.2: Product: stm32f429i-disc1
[526755.978768] usb 1-2.2: Manufacturer: RIOT-os.org
[526755.978769] usb 1-2.2: SerialNumber: 7C156425A950A8EB
[526755.991190] cdc_acm 1-2.2:1.0: ttyACM1: USB ACM device
[526755.998131] cdc_ether 1-2.2:1.2 usb0: register 'cdc_ether' at usb-0000:00:14.0-2.2, CDC Ethernet Device, a6:f6:4a:85:1d:c9
[526756.044150] cdc_ether 1-2.2:1.2 enp0s20f0u2u2i2: renamed from usb0
```
</details>
```python
USEMODULE='stdio_cdc_acm periph_usbdev_hs_utmi' BOARD=stm32f723e-disco make -j8 -C tests/usbus_cdc_ecm flash
```
<details>
<summary>Test results</summary>
```python
[528733.480207] usb 1-4.3.4: reset high-speed USB device number 32 using xhci_hcd
[528733.707800] usb 1-4.4: new high-speed USB device number 111 using xhci_hcd
[528733.808257] usb 1-4.4: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11
[528733.808260] usb 1-4.4: config 1 interface 1 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64
[528733.808263] usb 1-4.4: config 1 interface 1 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
[528733.808642] usb 1-4.4: New USB device found, idVendor=1209, idProduct=7d01, bcdDevice= 1.00
[528733.808645] usb 1-4.4: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[528733.808647] usb 1-4.4: Product: stm32f723e-disco
[528733.808649] usb 1-4.4: Manufacturer: RIOT-os.org
[528733.808651] usb 1-4.4: SerialNumber: A6BAC4E1B1E0806B
[528733.811988] cdc_acm 1-4.4:1.0: ttyACM1: USB ACM device
[528733.814456] cdc_ether 1-4.4:1.2 usb0: register 'cdc_ether' at usb-0000:00:14.0-4.4, CDC Ethernet Device, e6:75:97:3a:74:ba
[528733.854371] cdc_ether 1-4.4:1.2 enp0s20f0u4u4i2: renamed from usb0
```
</details>
```python
USEMODULE='stdio_cdc_acm periph_usbdev_hs_ulpi' BOARD=stm32f746g-disco make -j8 -C tests/usbus_cdc_ecm flash
```
<details>
<summary>Test results</summary>
```python
[529000.944482] usb 1-4.3.4: reset high-speed USB device number 32 using xhci_hcd
[529003.728260] usb 1-4.4: new high-speed USB device number 114 using xhci_hcd
[529003.833107] usb 1-4.4: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11
[529003.833111] usb 1-4.4: config 1 interface 1 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64
[529003.833113] usb 1-4.4: config 1 interface 1 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
[529003.833743] usb 1-4.4: New USB device found, idVendor=1209, idProduct=7d00, bcdDevice= 1.00
[529003.833747] usb 1-4.4: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[529003.833749] usb 1-4.4: Product: stm32f746g-disco
[529003.833751] usb 1-4.4: Manufacturer: RIOT-os.org
[529003.833753] usb 1-4.4: SerialNumber: 66FE8934D1A363E0
[529003.837143] cdc_acm 1-4.4:1.0: ttyACM1: USB ACM device
[529003.839755] cdc_ether 1-4.4:1.2 usb0: register 'cdc_ether' at usb-0000:00:14.0-4.4, CDC Ethernet Device, 6a:88:1f:1f:b1:f0
[529003.879025] cdc_ether 1-4.4:1.2 enp0s20f0u4u4i2: renamed from usb0```
```
</details>
### Issues/PRs references
Fixes#19359
19416: cpu/rpx0xx/cmsis: Update vendor header files r=benpicco a=maribu
### Contribution description
Generated new vendor header files from upstream SVD files using:
./SVDConv "$PICO_SDK_DIR"/src/rp2040/hardware_regs/rp2040.svd \
--generate=header --fields=macro --fields=enum
Note: The missing `--fields=struct` flag resulted in the header no longer containing bit-fields to represent different fields within registers. While this would generally ease writing code, the RP2040 has the unpleasant feature of corrupting the remaining bits of the register when a write access that is not word-sized occurs in the memory mapped I/O area. This could happen e.g. when a bit field is byte-sized and byte-aligned.
### Testing procedure
No binary changes (hopefully).
### Issues/PRs references
This adds a few additional vendor defines, notably for USB. If anyone were to implement USB, this would be a requirement.
19418: cpu/gd32v: fix gpio_read in periph_gpio r=benpicco a=gschorcht
### Contribution description
This PR fixes a bug in `gpio_read` which made `gpio_read` completely unusable!
A small bug with big consequences. In `gpio_read` the combined port | pin_num parameter `pin` was used instead of the pin number `pin_num` for the call of `_pin_is_input`. This caused the problem that for example instead of accessing GPIOA->CTL0 with address 0x40010800, address 0x60018c00 was accessed. As a result, a pin was randomly detected as input or output and thus a result was arbitrarily returned. Approx. 50% of all inputs always returned LOW.
I found this error by coincidence when I tried to find out why the BOOT0 button on a Sipeed Longan Nano is not usable as a button in RIOT.
### Testing procedure
Flash `tests/periph_gpio`
```
BOARD=sipeed-longan-nano make -j8 -C tests/periph_gpio flash
```
and use commands
```
init_in 0 8
read 0 8
```
Without this PR, the pin is always LOW. With the PR, the pin should be HIGH when the BOOT button is pressed.
### Issues/PRs references
19419: boards/sipeed-longan-nano: add BOOT as user button r=benpicco a=gschorcht
### Contribution description
This PR makes the BOOT button usable as a user button.
### Testing procedure
The test requires PR #19418 to work.
Flash and test:
```
BOARD=sipeed-longan-nano make -j8 -C tests/saul flash term
```
The output
```
Dev: BOOT Type: SENSE_BTN
Data: 0
```
should change to
```
Dev: BOOT Type: SENSE_BTN
Data: 1
```
when the BOOT button is pressed.
### Issues/PRs references
Depends on PR #19418
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Generated new vendor header files from upstream SVD files using:
./SVDConv "$PICO_SDK_DIR"/src/rp2040/hardware_regs/rp2040.svd \
--generate=header --fields=macro --fields=enum
Note: The missing `--fields=struct` flag resulted in the header no
longer containing bit-fields to represent different fields
within registers. While this would generally ease writing code,
the RP2040 has the unpleasant feature of corrupting the
remaining bits of the register when a write access that is not
word-sized occurs in the memory mapped I/O area. This could
happen e.g. when a bit field is byte-sized and byte-aligned.
19407: cpu/stm32/periph: Implement GPIO LL for STM32F1 without IRQ support (yet) r=gschorcht a=maribu
### Contribution description
This implements GPIO LL support for the STM32F1 in the first commit. IRQ support is added with https://github.com/RIOT-OS/RIOT/pull/19412.
This sneaks in a second commit replacing the `expect()` calls in `tests/periph_gpio_ll` with a trivial five-liner that doesn't `panic()`, so that stdio output will still be delivered on high level stdio implementations. The tests provides a lot of useful output to aid debugging, so its a great usability improvement if the test makes sure to actually deliver that output.
### Testing procedure
<details><summary><code>make -C tests/periph_gpio_ll BOARD=nucleo-f103rb flash term</code></summary>
```
2023-03-17 18:55:09,188 # Help: Press s to start test, r to print it is ready
s
2023-03-17 18:55:10,299 # START
2023-03-17 18:55:10,307 # main(): This is RIOT! (Version: 2023.04-devel-683-g9c3812-cpu/stm32/periph/gpio_ll)
2023-03-17 18:55:10,309 # Test / Hardware Details:
2023-03-17 18:55:10,310 # ========================
2023-03-17 18:55:10,311 # Cabling:
2023-03-17 18:55:10,313 # (INPUT -- OUTPUT)
2023-03-17 18:55:10,315 # P2.10 (PC10) -- P2.2 (PC2)
2023-03-17 18:55:10,318 # P2.12 (PC12) -- P2.3 (PC3)
2023-03-17 18:55:10,322 # Number of pull resistor values supported: 1
2023-03-17 18:55:10,325 # Number of drive strengths supported: 1
2023-03-17 18:55:10,328 # Number of slew rates supported: 3
2023-03-17 18:55:10,330 # Valid GPIO ports:
2023-03-17 18:55:10,332 # - PORT 0 (PORT A)
2023-03-17 18:55:10,333 # - PORT 1 (PORT B)
2023-03-17 18:55:10,335 # - PORT 2 (PORT C)
2023-03-17 18:55:10,336 # - PORT 3 (PORT D)
2023-03-17 18:55:10,338 # - PORT 4 (PORT E)
2023-03-17 18:55:10,338 #
2023-03-17 18:55:10,341 # Testing gpio_port_pack_addr()
2023-03-17 18:55:10,343 # =============================
2023-03-17 18:55:10,343 #
2023-03-17 18:55:10,344 # All OK
2023-03-17 18:55:10,344 #
2023-03-17 18:55:10,346 # Testing gpip_ng_init()
2023-03-17 18:55:10,348 # ======================
2023-03-17 18:55:10,348 #
2023-03-17 18:55:10,354 # Testing is_gpio_port_num_valid() is true for PORT_OUT and PORT_IN:
2023-03-17 18:55:10,354 #
2023-03-17 18:55:10,358 # Testing input configurations for PIN_IN_0:
2023-03-17 18:55:10,361 # Support for input with pull up: yes
2023-03-17 18:55:10,366 # state: in, pull: up, schmitt trigger: off, value: on
2023-03-17 18:55:10,369 # Support for input with pull down: yes
2023-03-17 18:55:10,374 # state: in, pull: down, schmitt trigger: off, value: off
2023-03-17 18:55:10,378 # Support for input with pull to bus level: no
2023-03-17 18:55:10,383 # Support for floating input (no pull resistors): yes
2023-03-17 18:55:10,388 # state: in, pull: none, schmitt trigger: off, value: off
2023-03-17 18:55:10,388 #
2023-03-17 18:55:10,392 # Testing output configurations for PIN_OUT_0:
2023-03-17 18:55:10,397 # Support for output (push-pull) with initial value of LOW: yes
2023-03-17 18:55:10,401 # state: out-pp, slew: slowest, value: off
2023-03-17 18:55:10,404 # Output is indeed LOW: yes
2023-03-17 18:55:10,408 # state: out-pp, slew: slowest, value: on
2023-03-17 18:55:10,411 # Output can be pushed HIGH: yes
2023-03-17 18:55:10,417 # Support for output (push-pull) with initial value of HIGH: yes
2023-03-17 18:55:10,420 # state: out-pp, slew: slowest, value: on
2023-03-17 18:55:10,424 # Output is indeed HIGH: yes
2023-03-17 18:55:10,430 # Support for output (open drain with pull up) with initial value of LOW: no
2023-03-17 18:55:10,437 # Support for output (open drain with pull up) with initial value of HIGH: no
2023-03-17 18:55:10,443 # Support for output (open drain) with initial value of LOW: yes
2023-03-17 18:55:10,449 # state: out-od, slew: slowest, pull: none, schmitt trigger: off, value: off
2023-03-17 18:55:10,452 # Output is indeed LOW: yes
2023-03-17 18:55:10,458 # Support for output (open drain) with initial value of HIGH: yes
2023-03-17 18:55:10,465 # state: out-od, slew: slowest, pull: none, schmitt trigger: off, value: on
2023-03-17 18:55:10,470 # state: in, pull: down, schmitt trigger: off, value: off
2023-03-17 18:55:10,474 # Output can indeed be pulled LOW: yes
2023-03-17 18:55:10,478 # state: in, pull: up, schmitt trigger: off, value: on
2023-03-17 18:55:10,483 # Output can indeed be pulled HIGH: yes
2023-03-17 18:55:10,488 # Support for output (open source) with initial value of LOW: no
2023-03-17 18:55:10,494 # Support for output (open source) with initial value of HIGH: no
2023-03-17 18:55:10,501 # Support for output (open source with pull up) with initial value of HIGH: no
2023-03-17 18:55:10,508 # Support for output (open source with pull up) with initial value of LOW: no
2023-03-17 18:55:10,511 # Support for disconnecting GPIO: yes
2023-03-17 18:55:10,515 # Output can indeed be pulled LOW: yes
2023-03-17 18:55:10,519 # Output can indeed be pulled HIGH: yes
2023-03-17 18:55:10,519 #
2023-03-17 18:55:10,523 # Testing Reading/Writing GPIO Ports
2023-03-17 18:55:10,526 # ==================================
2023-03-17 18:55:10,526 #
2023-03-17 18:55:10,529 # testing initial value of 0 after init
2023-03-17 18:55:10,531 # ...OK
2023-03-17 18:55:10,535 # testing setting both outputs_optional simultaneously
2023-03-17 18:55:10,537 # ...OK
2023-03-17 18:55:10,541 # testing clearing both outputs_optional simultaneously
2023-03-17 18:55:10,543 # ...OK
2023-03-17 18:55:10,547 # testing toggling first output (0 --> 1)
2023-03-17 18:55:10,548 # ...OK
2023-03-17 18:55:10,552 # testing toggling first output (1 --> 0)
2023-03-17 18:55:10,553 # ...OK
2023-03-17 18:55:10,557 # testing toggling second output (0 --> 1)
2023-03-17 18:55:10,558 # ...OK
2023-03-17 18:55:10,562 # testing toggling second output (1 --> 0)
2023-03-17 18:55:10,563 # ...OK
2023-03-17 18:55:10,569 # testing setting first output and clearing second with write
2023-03-17 18:55:10,570 # ...OK
2023-03-17 18:55:10,575 # testing setting second output and clearing first with write
2023-03-17 18:55:10,576 # ...OK
2023-03-17 18:55:10,580 # All input/output operations worked as expected
2023-03-17 18:55:10,580 #
2023-03-17 18:55:10,580 #
2023-03-17 18:55:10,582 # TEST SUCCEEDED
2023-03-17 18:55:10,588 # { "threads": [{ "name": "main", "stack_size": 1536, "stack_used": 456 }]}
```
</details>
<details><summary><code>make -C tests/bench_periph_gpio_ll BOARD=nucleo-f103rb flash term</code></summary>
```
2023-03-17 18:55:42,192 # Help: Press s to start test, r to print it is ready
s
2023-03-17 18:55:44,616 # START
2023-03-17 18:55:44,624 # main(): This is RIOT! (Version: 2023.04-devel-683-g9c3812-cpu/stm32/periph/gpio_ll)
2023-03-17 18:55:44,624 #
2023-03-17 18:55:44,626 # Benchmarking GPIO APIs
2023-03-17 18:55:44,628 # ======================
2023-03-17 18:55:44,628 #
2023-03-17 18:55:44,632 # estimating loop overhead for compensation
2023-03-17 18:55:44,635 # -----------------------------------------
2023-03-17 18:55:44,642 # 4168 us for 50000 iterations
2023-03-17 18:55:44,642 #
2023-03-17 18:55:44,647 # periph/gpio: Using 2x gpio_set() and 2x gpio_clear()
2023-03-17 18:55:44,651 # ---------------------------------------------------
2023-03-17 18:55:44,706 # 50000 iterations took 45840 us (50008 us uncompensated)
2023-03-17 18:55:44,713 # Two square waves pins at 1090750 Hz ( 999840 Hz uncompensated)
2023-03-17 18:55:44,719 # ~66 CPU cycles per square wave period (~72 cycles uncompensated)
2023-03-17 18:55:44,719 # :'-(
2023-03-17 18:55:44,719 #
2023-03-17 18:55:44,724 # periph/gpio_ll: Using gpio_ll_set() and gpio_ll_clear()
2023-03-17 18:55:44,729 # -------------------------------------------------------
2023-03-17 18:55:44,738 # 50000 iterations took 695 us (4863 us uncompensated)
2023-03-17 18:55:44,745 # Two square waves pins at 71942446 Hz ( 10281719 Hz uncompensated)
2023-03-17 18:55:44,750 # ~1 CPU cycles per square wave period (~7 cycles uncompensated)
2023-03-17 18:55:44,751 # :-D
2023-03-17 18:55:44,751 #
2023-03-17 18:55:44,755 # periph/gpio: Using 4x gpio_toggle()
2023-03-17 18:55:44,757 # -----------------------------------
2023-03-17 18:55:44,965 # 50000 iterations took 198646 us (202814 us uncompensated)
2023-03-17 18:55:44,972 # Two square waves pins at 251704 Hz ( 246531 Hz uncompensated)
2023-03-17 18:55:44,977 # ~286 CPU cycles per square wave period (~292 cycles uncompensated)
2023-03-17 18:55:44,978 # :'-(
2023-03-17 18:55:44,978 #
2023-03-17 18:55:44,982 # periph/gpio_ll: Using 2x gpio_ll_toggle()
2023-03-17 18:55:44,985 # -----------------------------------------
2023-03-17 18:55:45,010 # 50000 iterations took 15972 us (20140 us uncompensated)
2023-03-17 18:55:45,017 # Two square waves pins at 3130478 Hz ( 2482621 Hz uncompensated)
2023-03-17 18:55:45,023 # ~23 CPU cycles per square wave period (~29 cycles uncompensated)
2023-03-17 18:55:45,023 # :'-(
2023-03-17 18:55:45,023 #
2023-03-17 18:55:45,026 # periph/gpio: Using 4x gpio_write()
2023-03-17 18:55:45,029 # ----------------------------------
2023-03-17 18:55:45,097 # 50000 iterations took 58345 us (62513 us uncompensated)
2023-03-17 18:55:45,103 # Two square waves pins at 856971 Hz ( 799833 Hz uncompensated)
2023-03-17 18:55:45,109 # ~84 CPU cycles per square wave period (~90 cycles uncompensated)
2023-03-17 18:55:45,109 # :'-(
2023-03-17 18:55:45,110 #
2023-03-17 18:55:45,113 # periph/gpio_ll: Using 2x gpio_ll_write()
2023-03-17 18:55:45,117 # ----------------------------------------
2023-03-17 18:55:45,128 # 50000 iterations took 2777 us (6945 us uncompensated)
2023-03-17 18:55:45,135 # Two square waves pins at 18005041 Hz ( 7199424 Hz uncompensated)
2023-03-17 18:55:45,141 # ~4 CPU cycles per square wave period (~10 cycles uncompensated)
2023-03-17 18:55:45,141 # :-)
2023-03-17 18:55:45,141 #
2023-03-17 18:55:45,141 #
2023-03-17 18:55:45,142 # TEST SUCCEEDED
2023-03-17 18:55:45,149 # { "threads": [{ "name": "main", "stack_size": 1536, "stack_used": 448 }]}
```
</details>
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Use the largest instead of the smallest number of available EPs for this definition. This became necessary to be able to use all EPs of a USB OTG HS peripheral if enabled.
19371: sys/usbus: check for the number of required and provided EPs in static configurations r=dylad a=gschorcht
### Contribution description
This PR provides a static check at compile time whether the number of EPs required in a static configuration does not exceed the number of EPs provided by the USB device.
#### Background
In issue #19359 the problem was reported that `usbus_cdc_ecm` didn't work together with `stdio_cdc_acm` on some STM32 boards. The reason for some of the boards was simply that the application tried to allocate more EPs than available and simply ignored this and just didn't work.
#### Solution
Since `auto_init_usb` uses a static configuration with exactly one USBUS stack instance and one USB device, at least in case `auto_init` is used a static check can be carried out to make sure that the number of EPs required by the application doesn't exceed the number of EPs provided by the USB device. For this purpose, each `usbus_*` module defines the number of IN and OUT EPs required by that module. Each USB device driver defines the number of EPs provided by USB device if it differs from the default of 8 EPs. During the auto initialization the total number of required IN and OUT EPs is then compared with the number of EPs provided by the USB device using a static assert.
### Testing procedure
1. Green CI
2. Compilation of
```python
USEMODULE='stdio_cdc_acm' BOARD=nucleo-f439zi make -j8 -C tests/usbus_cdc_ecm
```
should lead to compilation error
```python
sys/auto_init/usb/auto_init_usb.c:81:1: error: static assertion failed: "Number of required IN endpoints exceeded"
_Static_assert(USBUS_EP_IN_REQUIRED_NUMOF <= USBDEV_NUM_ENDPOINTS,
^~~~~~~~~~~~~~
Makefile.base:146: recipe for target 'tests/usbus_cdc_ecm/bin/nucleo-f439zi/auto_init_usbus/auto_init_usb.o' failed
```
while compilation of
```
USEMODULE='stdio_cdc_acm' BOARD=nucleo-f767zi make -j8 -C tests/usbus_cdc_ecm
```
should work.
### Issues/PRs references
Fixes issue #19359 partially.
19382: tests/pkg_nanors: use static allocation r=benpicco a=benpicco
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
The STM32 periph_timer driver reads the timer's status flags, then
clears them all. It is possible that a timer interrupt could occur
between reading the flag and clearing it. This would lead to a lost
interrupt.
The timer's status flags can be cleared by software, but can only be set
by the hardware. This patch takes advantage of this by only clearing the
flags it knows are set. The rest of the flags are set, which doesn't
actually change their state.
