19261: tests/{sys_fido2_ctap/usbus_board_reset}: fix stdio_usb_serial_jtag dependency r=gschorcht a=gschorcht
### Contribution description
This PR fixes the `stdio_usb_serial_jtag` dependency problem for `tests/sys_fido2_ctap` and `usbus_board_reset`.
- There are boards that select the STDIO backend used depending on whether `usbus` is enabled. Usually the `fido2_ctap_transport_hid` module pulls in `usbus_hid` and thus `usbus`, but since this dependency resolution is done after reading the `Makefile.dep` of the board, it may happen that the wrong STDIO backend is selected. Therefore `usbus` is selected directly in the `Makefile` of `tests/sys_fido2_ctap` .
- To improve the selection of the `stdio_usb_serial_jtag` backend in `esp32s3-pros3`, it checks for any `usbus_%` module not only `usbus`.
### Testing procedure
GreenCI
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19240: tools/doccheck: add simple exclude to doccheck r=benpicco a=kfessel
while doccheck runs for #19228 and #19220, i saw some spikes in memory consumption, turned out that was `grep -Evf dist/tools/doccheck/exclude_patterns` using about 2GB RAM. This PR changes that.
### Contribution description
add `exclude_simple` to `doccheck` drived from `exclude patterns`
`sort`ed and `uniq`ued the simple excludes
removes no longer needed patterns from `exclude patterns`
simple excludes are string rules (no patterns just strings)
how to apply these:
in this PR:
*remove the path and line number from the rule
* that made some of them doubles of each other
* sorted and uniqued them.
* this set of excludes is no longer path specific (an exception covers all paths but may of them still contain a file name)
another possible solution would be to have the excludes line number specific.
### Testing procedure
run `dist/tools/doccheck/check.sh`
compare memory consumption of
master: `grep -Evf dist/tools/doccheck/exclude_patterns`
to
this PR: `grep -Fvf dist/tools/doccheck/exclude_simple`
### Issues/PRs references
19248: cpu/gd32v: add periph_dac support r=benpicco a=gschorcht
### Contribution description
This PR provides the `periph_dac` support for GD32VF103.
### Testing procedure
`tests/periph_dac` should work on `sipeed-longan-nano` port on PA4 and PA5.
### Issues/PRs references
19255: boards/esp*: complete SD Card MTD config r=benpicco a=gschorcht
### Contribution description
This PR provides the remaining changes necessary to use the generic MTD SD Card configuration as described in PR #19216.
This includes defining the MTD offset for SD cards, since the default `MTD_0` device always uses the internal flash device, and the completion of the configuration for the ESP32 boards with a SD card interface.
### Testing procedure
`tests/vfs_default` should work now with SD Cards:
```
main(): This is RIOT! (Version: 2023.04-devel-323-gfcc07)
mount points:
/nvm0
/sd0
data dir: /sd0
> vfs df
Mountpoint Total Used Available Use%
/nvm0 3052 KiB 8 KiB 3044 KiB 0%
/sd0 7580 MiB 3632148992 B 21089792 B 99%
```
### Issues/PRs references
Co-authored-by: Karl Fessel <karl.fessel@ovgu.de>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19249: boards/gd32v: improve board definitions r=benpicco a=gschorcht
### Contribution description
This PR provides some small improvements of the existing board definitions for GD32VF103 boards for more flexibel default configurations and documentation of the board peripherals:
- Allow the remapping of SPI0 pins in SPI configuration (ae984b0bea)
- More flexible I2C configuration (0c337583b4)
The default I2C device configuration allows to define up to two I2C devices `I2C_DEV(0)` and `I2C_DEV(1)`. `I2C_DEV(0)` is always defined if the I2C peripheral is enabled by the module `periph_spi`. The second I2C device `I2C_DEV(1)` is only defined if `I2C_DEV_1_USED` is defined by the board. This allows to use the default configuration with one or two I2C devices depending on whether other peripherals are enabled that would collide with the I2C devices.
- More flexible SPI configuration (edbf59e37e)
The default SPI device configuration allows to define up to two SPI devices `SPI_DEV(0)` and `SPI_DEV(1)`. `SPI_DEV(0)` is always defined if the SPI peripheral is enabled by the module `periph_spi`. The second SPI device `SPI_DEV(1)` is only defined if `SPI_DEV_1_USED` is defined by the board. This allows to use the default configuration with one or two SPI devices depending on whether other peripherals are enabled that would collide with the SPI devices.
Furthermore, the CS signal in the SPI configuration is given by a define that can be overriden with another pin if
the default CS signal is connected to an unused hardware.
- Improve ADC config for Sipeed-Longan-Nano (c9c587ee00)
The ADC configuration was too complex. It was hard to follow when certain ADC lines are available. Furthermore, the order of ADC lines did depend on the use of other peripherals. Now, either the TFT display is not connected and all ADC lines are available or the TFT display is connected and the second SPI device is used so that only the first 4 ADC lines are available.
- Improve Kconfig for Sipeed-Longan-Nano (025f4fdf00)
Board-specific configuration not shown any longer directly in the top level menu but within a submenu.
- Improve peripherals documentation (7f0d560dd8, e24abe495a)
Available peripherals for the board are now documented in two tables ordered by RIOT peripheral names and by pins.
Although the different changes are small and mostly related to the documentation, I could split the PR if necessary.
### Testing
Green CI
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19088: boards: add esp32s3-pros3 support r=benpicco a=gschorcht
### Contribution description
This PR provides the support for [ESP32 ProS3](https://esp32s3.com/pros3.html#home) board from Unexpected Maker.
This board doesn't have a USB-to-Serial chip on board. Therefore, USB Serial/JTAG is used for STDIO and the board is flashed via the USB Seral/JTAG interface by default.
### Testing procedure
Flashing `tests/shell` should work.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
After a reset, it can take several seconds before the CDC ACM interface becomes available as serial device `ttyACMx`. This was a change that was already made for `stdio_cdc_acm` in #19128.
The ADC configuration was too complex. It was hard to follow when certain ADC lines are available. Furthermore, the order of ADC lines did depend on the use of other peripherals. Now, either the TFT display is not connected and all ADC lines are available or the TFT display is connected and the second SPI device is used so that only the first 4 ADC lines are available.
The default SPI device configuration allows to define up to two SPI devices `SPI_DEV(0)` and `SPI_DEV(1)`. `SPI_DEV(0)` is always defined if the SPI peripheral is enabled by the module `periph_spi`. The second SPI device `SPI_DEV(1)` is only defined if `SPI_DEV_1_USED` is defined by the board. This allows to use the default configuration with one or two SPI devices depending on whether other peripherals are enabled that would collide with the SPI devices.
Furthermore, the CS signal in the SPI configuration is given by a define that can be overriden with another pin if
the default CS signal is connected to an unused hardware.
The default I2C device configuration allows to define up to two I2C devices `I2C_DEV(0)` and `I2C_DEV(1)`. `I2C_DEV(0)` is always defined if the I2C peripheral is enabled by the module `periph_spi`. The second I2C device `I2C_DEV(1)` is only defined if `I2C_DEV_1_USED` is defined by the board. This allows to use the default configuration with one or two I2C devices depending on whether other peripherals are enabled that would collide with the I2C devices.
18863: boards/esp32s2-mini: add definition for ESP32 S2 Mini r=gschorcht a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
16782: drivers/mfrc522: add new driver r=benpicco a=HendrikVE
### Contribution description
This PR adds support for the MFRC522. It is quite common in the Arduino world and it is quite cheap. The driver connects to the MFRC522 via SPI and is heavily based on the Arduino driver available [here](https://github.com/miguelbalboa/rfid). Basically it was ported, but with several improvements in readability and documentation.
### Testing procedure
The given (manual) test provides single commands for some driver functions.
19201: cpu/gd32v: add periph_i2c support r=benpicco a=gschorcht
### Contribution description
This PR provides the `periph_i2c` support and is one of a bunch of PRs that complete the peripheral drivers for GD32VF103.
The driver is a modified version of the driver for STM32F1 with some changes that were necessary to get it working on GD32V. As for STM32F1, the driver is using polling instead of interrupts for now. It will be implemented interrupt-driven later.
### Testing procedure
`tests/periph_i2c` as well as a test with any I2C sensor should work. The driver was tested with `tests/driver_l3gxxxx` and `tests/driver_bmp180`.
### Issues/PRs references
Co-authored-by: Hendrik van Essen <hendrik.ve@fu-berlin.de>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
The default timer configuration has been changed so that `TIMER0` and `TIMER1` are always timer devices. `TIMER2` can only be used as timer device if it is not used for PWM devices. `TIMER3` and `TIMER4` are only available as timer devices if they are supported by the CPU model and not used for PWM devices.
19199: sys/suit: Ensure previous thread is stopped before reusing its stack r=benpicco a=chrysn
### Contribution description
Closes: https://github.com/RIOT-OS/RIOT/issues/19195
If the thread has released the mutex but the thread has not terminated (which happens in the situation that would previously have overwritten a still active thread's state), then a warning is shown and the trigger is ignored.
### Testing procedure
This should work before and after:
* `make -C examples/suit_update BOARD=native all term`
* `aiocoap-client coap://'[fe80::3c63:beff:fe85:ca96%tapbr0]'/suit/trigger -m POST --payload 'coap://[2001:db8::]/foo'`
* In parallel, on the RIOT shell, run `suit fetch coap://[2001:db8::]/foo`
* After the first download fails, the second one starts right away ("suit_worker: update failed, hdr invalid" / "suit_worker: started").
Run again with the worker thread on low priority:
```patch
diff --git a/sys/suit/transport/worker.c b/sys/suit/transport/worker.c
index a54022fb28..e26701a64c 100644
--- a/sys/suit/transport/worker.c
+++ b/sys/suit/transport/worker.c
`@@` -70 +70 `@@`
-#define SUIT_COAP_WORKER_PRIO THREAD_PRIORITY_MAIN - 1
+#define SUIT_COAP_WORKER_PRIO THREAD_PRIORITY_MAIN + 1
```
Before, this runs the download once silently (no clue why it doesn't run it twice, but then again, I claim there's concurrent memory access from two thread, so who knows what happens). After, it runs a single download and shows an error message for the second one once the first is complete ("Ignoring SUIT trigger: worker is still busy.").
### Issues/PRs references
This may be made incrementally easier by https://github.com/RIOT-OS/RIOT/pull/19197 -- that PR as it is now would spare us the zombification (because returning would do that), and having a `wait` function would allow us to turn the new error case into a success.
19205: boards/common: add common timer config for GD32VF103 boards r=benpicco a=benpicco
19207: examples/gnrc_border_router: static: use router from advertisements by default r=benpicco a=benpicco
Co-authored-by: chrysn <chrysn@fsfe.org>
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
19202: cpu/gd32v: add periph_rtt support r=benpicco a=gschorcht
### Contribution description
This PR provides the `periph_rtt` support and is one of a bunch of PRs that complete the peripheral drivers for GD32VF103.
### Testing procedure
`tests/periph_rtt` should work and give the following results:
```
Help: Press s to start test, r to print it is ready
START
main(): This is RIOT! (Version: 2023.04-devel-199-g2d429-cpu/gd32v/periph_rtt)
RIOT RTT low-level driver test
RTT configuration:
RTT_MAX_VALUE: 0xffffffff
RTT_FREQUENCY: 32768
Testing the tick conversion
Trying to convert 1 to seconds and back
Trying to convert 256 to seconds and back
Trying to convert 65536 to seconds and back
Trying to convert 16777216 to seconds and back
Trying to convert 2147483648 to seconds and back
All ok
Initializing the RTT driver
This test will now display 'Hello' every 5 seconds
RTT now: 148
Setting initial alarm to now + 5 s (163988)
rtt_get_alarm() PASSED
Done setting up the RTT, wait for many Hellos
{ "threads": [{ "name": "idle", "stack_size": 256, "stack_used": 216 }]}
{ "threads": [{ "name": "main", "stack_size": 1280, "stack_used": 480 }]}
Hello
Hello
Hello
Hello
```
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19204: boards/sipeed-longan-nano: default to flashing via DFU r=gschorcht a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
