19696: drivers/mq3: avoid use of floats r=maribu a=maribu
19698: tests/pkg/lvgl: avoid using floats r=maribu a=maribu
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
19691: drivers/bmx055: fix crazy use of FPU r=maribu a=maribu
### Contribution description
As the title says...
19694: tests/drivers/epd_bw_spi_disp_dev: fix accidental use of FPU r=maribu a=maribu
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
19686: sys/string_utils: add memchk() r=maribu a=benpicco
19687: tests/unittests: remove old workaround for SAML1X and gcc9.X bug r=maribu a=dylad
### Contribution description
This reverts #13462, this workaround is no longer needed with newer GCC version.
### Testing procedure
Try to compile tests/unittests for `saml11-xpro` or `saml10-xpro`
### Issues/PRs references
This is a revert of #13462.
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
19650: drivers/nrf24l01p: model in kconfig r=aabadie a=aabadie
19660: cpu/rpx0xx: Fix kconfig model r=aabadie a=MrKevinWeiss
### Contribution description
Broken master due to incorrect model of the periph_pio in kconfig.
### Testing procedure
Green murdock (now that the board is added to the list)
### Issues/PRs references
Look at the master CI...
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
19618: cpu/stm32: fix riotboot settings for L4 and WB r=benpicco a=gschorcht
### Contribution description
This PR fixes the `riotboot` configuration for L4 and WB.
The family is not called `stm32l4` or `stm32wb` but `l4` and `wb`. That is, the `riotboot` configuration didn't work at all. Furthermore, a minimum `RIOTBOOT_LEN` of `0x2000` is required for L4.
Found when investigating the compilation errors for `bootloaders/riotboot_serial` in PR #19576.
### Testing procedure
1. Green CI.
2. Use the following commands:
```
BOARD=nucleo-l496zg make -C tests/riotboot info-debug-variable-RIOTBOOT_HDR_LEN
BOARD=p-nucleo-wb55 make -C tests/riotboot info-debug-variable-RIOTBOOT_HDR_LEN
```
In master these commands give
```
0x400
```
With this PR these commands give
```
0x200
```
as expected.
3. Use the following commands:
```
BOARD=nucleo-l496zg make -C tests/riotboot info-debug-variable-RIOTBOOT_LEN
BOARD=p-nucleo-wb55 make -C tests/riotboot info-debug-variable-RIOTBOOT_LEN
```
In master these commands give
```
0x1000
```
With this PR these commands give
```
0x2000
```
as expected.
### Issues/PRs references
19639: tests/net/gnrc_mac_timeout: add automated test r=aabadie a=aabadie
19644: gnrc_ipv6_nib: include RIO with all subnets in downstream RA r=benpicco a=benpicco
19649: gnrc_sixlowpan_iphc: prefix bits outside context must be zero r=benpicco a=benpicco
19656: gnrc/ipv6_auto_subnets: allow to configure minimal prefix length r=benpicco a=benpicco
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
- Replace all users of `$(RIOTBASE)/build` with the already present
`$(BUILD_DIR)` variable
- Replace all users of `$(BUILD_DIR)/pkg` with the already present
`$(PKGDIRBASE)` variable
- Create a `CACHEDIR.TAG` file in the `$(BUILD_DIR)`
18056: pkg/cmsis: use unique package for CMSIS headers, DSP and NN modules r=benpicco a=aabadie
19571: cpu/stm32/periph_adc: fixes and improvements for L4 support r=benpicco a=gschorcht
### Contribution description
This PR provides the following fixes and improvements for the `periph_adc` implementation for STM32L4.
- Support STM32L496AG added.
- Instead of defining the number of ADC devices for each MCU model, the number of ADC devices is determined from ADCx definitions in CMSIS header.
- MCU specific register/value defines are valid for all L4 MCUs, model based conditional compilation is removed.
- The ADC clock disable function is fixed using a counter. The counter is incremented in `prep` and decremented in `done`. The ADC clock is disabled if the counter becomes 0.
- For boards that have not connected the V_REF+ pin to an external reference voltage, the VREFBUF peripheral can be used as V_REF+ (if supported) by setting `VREFBUF_ENABLE=1`.
- The ASCR register is available and has to be set for all STM32L471xx, STM32L475xx, STM32L476xx, STM32L485xx and STM32L486xx MCUs. Instead of using the CPU model for conditional compilation, the CPU line is used to support all MCU of that lines.
- Setting of SQR1 is fixed. Setting the SQR1 did only work before because the `ADC_SRQ_L` is set to 0 for a sequence length of 1.
- Setting the `ADC_CCR_CKMODE` did only work for the reset state. It is now cleared before it is set. Instead of using the `ADC_CCR_CKMODE_x` bits to set the mode, the mode defines are used.
- Support for V_REFINT as ADC channel added.
### Testing procedure
19589: gnrc/gnrc_netif_hdr_print: printout timestamp if enabled r=aabadie a=chudov
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: chudov <chudov@gmail.com>
19585: tests: move leftover sys related tests to test/sys + move tests/sys/candev to tests/drivers r=aabadie a=aabadie
19586: tests: move net related applications to test/net r=aabadie a=aabadie
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
19582: tests: move nimble and lwip related to test applications to tests/pkg r=aabadie a=aabadie
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
19573: cpu/stm32/periph_dac: small improvements r=maribu a=gschorcht
### Contribution description
This PR provides the following improvements for `periph_dac` on STM32
- Support for `RCC_APB1ENR1_DAC1EN` symbol added.
- For boards that have not connected the V_REF+ pin to an external reference voltage, the VREFBUF peripheral can be used as V_REF+ (if supported) by setting `VREFBUF_ENABLE=1`.
- If the DAC peripheral has a mode register (`DAC_MCR`), it is set to normal mode with buffer enabled and connected to external pin and on-chip peripherals. This allows to measure the current value of a DAC channel with an ADC channel or to use the DAC channel also for other on-chip peripherals.
### Testing procedure
- Green CI
- `tests/periph_dac` should still work for any board supporting the `periph_dac` feature.
### Issues/PRs references
19579: doc/doxygen/src/flashing.md: work around Doxygen bug r=maribu a=maribu
### Contribution description
Doxygen fails to render inline code in headers correctly in the version the CI uses. So, work around the issue by not typestetting `stm32flash` as inline code but as regular text.
19583: tests: move cpu related applications to tests/cpu r=maribu a=aabadie
19584: tests/build_system/external_board_dirs: fix broken symlinks r=maribu a=aabadie
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
19565: tests: move core related applications to their own tests/core/ folder r=maribu a=aabadie
19568: tests: move remaining driver related applications to tests/drivers r=maribu a=aabadie
19574: cpu/stm32/periph_gpio: reset PU/PD for ADC channels r=maribu a=gschorcht
### Contribution description
This PR provides a small fix that is relevant when a GPIO has been used as input/output with a pull resistor before it is initialized as an ADC channel.
The PU/PD configuration has to be `0b00` for analog outputs which is corresponds to the reset state. However, if the GPIO is not in the reset state but was used digital input/output with any pull resistor, the PU/PD configuration has also to be reset to use it as ADC channel.
### Testing procedure
- Green CI
- The `periph_adc` test application should still work for any board that supports the `periph_adc` feature.
### Issues/PRs references
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19564: tests: move all bench applications to their own tests/bench/ folder r=aabadie a=aabadie
19569: tests/lua_loader: move to tests/pkg/lua_loader r=aabadie a=aabadie
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
19552: tests: move all periph applications to their own periphs/ folder r=gschorcht a=aabadie
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
19522: tests/periph_rtt: Fix for tick conversion test r=benpicco a=chudov
### Contribution description
Type casting and `printf` formatting for the `RTT_MAX_VALUE` and `RTT_FREQUENCY` are fixed so 32-bit value is properly handled by 'avr-libc'.
The original tick conversion test assumes that `RTT_FREQUENCY` is power of 2 so forward and backward ticks to seconds conversion results in the original ticks value. To fix it the result of the forward-backward conversion is compared with `ticktest / RTT_FREQUENCY * RTT_FREQUENCY` that considers rounding errors.
Changes were tested on deRFmega256 and nrf52840dongle.
### Testing procedure
tests/periph_rtt on a board with ATmega256RFR2 shall:
* show correct RTT_MAX_VALUE
* conversion check shall report no error.
### Issues/PRs references
Fixes#15940
Co-authored-by: chudov <chudov@gmail.com>
19368: debug: add DEBUG_BREAKPOINT() macro, set breakpoint on failed assertion r=benpicco a=benpicco
19529: cpu/stm32/periph/dac: optimize setting DAC r=benpicco a=Enoch247
### Contribution description
The current implmentation right shifted the 16 bit value passed into `dac_set()` down to the 12 bits that the DAC is actually capable of. This patch drops the shift and instead writes the 16 bit value to the DAC's left aligned 12 bit wide data holding register.
### Testing procedure
do something like:
``` c
#include "perip/dac.h"
int main(void)
{
dac_set(DAC_LINE(0), 0xffff/2);
return 0;
}
```
- observe DAC's output is half of vref
### Issues/PRs references
- none known
19531: tests/unittests: allow passing `UNIT_TESTS` via env r=benpicco a=kaspar030
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
Co-authored-by: Joshua DeWeese <jdeweese@primecontrols.com>
Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
19525: semtech-loramac: extend list of supported radio with sx1261, sx1262 and sx1268 r=maribu a=aabadie
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
19346: pkg/tinydtls: allow build for AVR r=benpicco a=benpicco
19512: SUBSYSTEMS.md: add jia200x to subsystems r=benpicco a=jia200x
19513: boards/nrf52840dongle/doc: Update nrfutil pointers r=benpicco a=chrysn
### Contribution description
Nordic changed its nrfutil; this change adjust to it.
I'm not fully happy with recommending that tool at all due to its bad quality (see rambling in https://github.com/RIOT-OS/RIOT/issues/19511), but short of soldering on a debug header or touch-probing it with wires it's the only way in to the device. I may later add follow-up recommendations to switch to riotboot, but this now at least fixes the immediate issue.
### Testing procedure
* Look at the updated documentation.
### Issues/PRs references
Closes: https://github.com/RIOT-OS/RIOT/issues/19511
19514: dist/testbed-support: remove obsolete boards from iotlab archi r=benpicco a=aabadie
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Jose Alamos <jose@alamos.cc>
Co-authored-by: chrysn <chrysn@fsfe.org>
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
18620: core: add core_mutex_debug to aid debugging deadlocks r=maribu a=maribu
### Contribution description
Adding `USEMODULE += core_mutex_debug` to your `Makefile` results in
on log messages such as
[mutex] waiting for thread 1 (pc = 0x800024d)
being added whenever `mutex_lock()` blocks. This makes tracing down
deadlocks easier.
### Testing procedure
Run e.g.
```sh
USEMODULE=core_mutex_debug BOARD=nucleo-f767zi make -C tests/mutex_cancel flash test
```
which should provide output such as
```
Welcome to pyterm!
Type '/exit' to exit.
READY
s
[mutex] waiting for thread 1 (pc = 0x8000f35)
START
main(): This is RIOT! (Version: 2022.10-devel-841-g5cc02-core/mutex/debug)
Test Application for mutex_cancel / mutex_lock_cancelable
=========================================================
Test without cancellation: OK
Test early cancellation: OK
Verify no side effects on subsequent calls: [mutex] waiting for thread 1 (pc = 0x800024d)
OK
Test late cancellation: [mutex] waiting for thread 1 (pc = 0x0)
OK
TEST PASSED
```
```sh
$ arm-none-eabi-addr2line -a 0x800024d -e tests/mutex_cancel/bin/nucleo-f767zi/tests_mutex_cancel.elf
0x0800024d
/home/maribu/Repos/software/RIOT/tests/mutex_cancel/main.c:51
```
### Issues/PRs references
Depends on and includes https://github.com/RIOT-OS/RIOT/pull/18619
19296: nanocoap: allow to define CoAP resources as XFA r=maribu a=benpicco
19504: cpu/cc26xx_cc13xx: Fix bogus array-bound warning r=maribu a=maribu
### Contribution description
GCC 12 create a bogus array out of bounds warning as it assumes that because there is special handling for `uart == 0` and `uart == 1`, `uart` can indeed be `1`. There is an `assert(uart < UART_NUMOF)` above that would blow up prior to any out of bounds access.
In any case, optimizing out the special handling of `uart == 1` for when `UART_NUMOF == 1` likely improves the generated code and fixes the warning.
/home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:88:8: error: array subscript 1 is above array bounds of 'uart_isr_ctx_t[1]' [-Werror=array-bounds]
88 | ctx[uart].rx_cb = rx_cb;
| ~~~^~~~~~
/home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:52:23: note: while referencing 'ctx'
52 | static uart_isr_ctx_t ctx[UART_NUMOF];
| ^~~
/home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:89:8: error: array subscript 1 is above array bounds of 'uart_isr_ctx_t[1]' [-Werror=array-bounds]
89 | ctx[uart].arg = arg;
| ~~~^~~~~~
/home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:52:23: note: while referencing 'ctx'
52 | static uart_isr_ctx_t ctx[UART_NUMOF];
| ^~~
### Testing procedure
The actual change is a pretty obvious one-liner, so that code review and a green CI should be sufficient. If not, running any UART example app without regression should do.
### Issues/PRs references
None
19506: tools/openocd: Fix handling of OPENOCD_CMD_RESET_HALT r=maribu a=maribu
### Contribution description
The OPENOCD_CMD_RESET_HALT was not longer correctly passed to the script. This fixes the issue.
### Testing procedure
Flashing of e.g. the `cc2650-launchpad` with upstream OpenOCD should work again.
### Issues/PRs references
The change was added to https://github.com/RIOT-OS/RIOT/pull/19050 after testing the PR and before merging. I'm not sure if the fix never worked because of this, or if behavior of `target-export-variables` or GNU Make changed.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
19485: sys/shell: Fix missing dependency r=aabadie a=maribu
### Contribution description
The shell commands depend on the shell module being use. This was already the case in KConfig, but was overlooked in the shell's `Makefile.dep`.
In addition, this uncovered that `tests/memarray` had a bogus dependency on shell commands without every using the shell.
### Testing procedure
Ideally binaries should not differ (except for debug section).
### Issues/PRs references
Split out of https://github.com/RIOT-OS/RIOT/pull/19483
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
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`.
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>
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 a custom expect() that just spins in an endless loop instead of
panicking. The test isn't run automatically anyway, as it requires
connecting two GPIOs with jumper wires; but when run manually it is
helpful to not kill RIOT to also get the stdio output of the exact
point where the test fails (e.g. USB CDC ACM doesn't like panic()).
19402: sys/net/gnrc/netif: fixing no global address wait r=benpicco a=jan-mo
### Contribution description
The function `gnrc_netif_ipv6_wait_global_address()` will always return true, even if no global address is attached to the interface.
Currently the function only waits for any message and does not check if it was from the bus or not. So in `msg.content.ptr` is no valid address and therefore it returns true.
I added just the check, if the message is from the bus of any interface and then checking the address. We could also first check if the address in `msg.content.ptr` is valid, but this will just hide the bug. Also the timeout was never checked. It was just assuming that no other message will be received during the wait.
### Testing procedure
Use two devices, one works as a border router and supports the global address, the other will wait for the global address. You can call the function `gnrc_netif_ipv6_wait_global_address()` on the waiting node and see whether it returns true and finds the global address in the given time-range.
19404: sys/trickle: cleanup deps r=benpicco a=MrKevinWeiss
### Contribution description
Cleans the dependencies of the `trickle` module. This removes the deprecated xtimer and models kconfig.
### Testing procedure
Green murdock
### Issues/PRs references
19405: cpu/efm32: pwm_init errors are zeros r=benpicco a=chrysn
### Contribution description
pwm_init is documented to return 0 on errors, and has an unsigned return value.
EFM32's initialization function returned negative values, which through implicit casting become 0xffffffff or 0xfffffffe, which are successful by the documentation.
This makes all the EFM32 error paths return 0 as they should.
Also, it fixes a variable name and the corresponding error message that used to talk of "initiation" (which would be the start of a process) rather than "initialization" (which is a process that is completed before something else can happen).
### Testing procedure
* on stk3700, tests/periph_pwm, run `init 0 0 10 1000` / `set 0 0 500`
* The init used to respond with "The pwm frequency is set to 4294967294", and the set does nothing.
* The init now responds with "Error: device is not <del>initiated</del><ins>initialized</ins>". The set still does nothing, but then one doesn't expect it to any more.
(But really, looking at the patch and the docs should suffice).
### Issues/PRs references
By-catch from testing the Rust wrappers provided by `@remmirad` at https://github.com/RIOT-OS/rust-riot-wrappers/pull/38
Co-authored-by: Jan Mohr <jan.mohr@ml-pa.com>
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
Co-authored-by: chrysn <chrysn@fsfe.org>
Since the stm32f429i-disco uses the USB OTG HS instead of USB OTG FS peripheral, the number of available EPs is sufficient for this application. With the change of defining the largest number of available EPs for USBUS instead of the smallest number, the board can use all EPs of the USB OTG HS peripheral.
19394: tests/rmutex: Drop output dump from README.md r=maribu a=maribu
### Contribution description
We use test scripts to automatically classify the output of a test application as passing / failing. Users are not expected to manually compare the output with a dump of the output in a readme.
### Testing procedure
Doesn't apply
### Issues/PRs references
Fixes https://github.com/RIOT-OS/RIOT/issues/19140
Fixes https://github.com/RIOT-OS/RIOT/issues/19298
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
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>
19344: test/periph_rtc: reset struct tm time between tests r=benpicco a=kfessel
### Contribution description
while reviewing #19340 i found test/periph_rtc to be insufficient to prove rtc_set_time is working. this changes that and avoids accidental reuse of struct tm time and ms values by resetting time and ms;
### Testing procedure
run the test
### Issues/PRs references
#19340
Co-authored-by: Karl Fessel <karl.fessel@ovgu.de>
19242: usbus/msc: add initial Mass Storage Class support r=benpicco a=dylad
### Contribution description
This PR adds the initial support for Mass Storage Class in USBUS. This PR relies on the RIOT MTD implementation to implement the Mass Storage Class support. With the provided test application, a MTD device will be accessible as a normal storage device on your host computer.
Read and Write operations are allowed.
Multiple LUNs are supported so several MTD devices can be exported through USB.
The MSC relies on SCSI protocol to operate.
Currently there are some limitations:
Supported host : Linux & Windows (macOS is untested)
MSC cannot be used if MTD page size > 4096
MTD device must have at least 512 bytes of memory to be exported.
Please be aware that performance are not so great.
### Testing procedure
Flash `tests/usbus_msc` application on a board with at least one MTD device.
Once the shell has started, prepare one or several MTD devices to be exported using `add_lun` command.
Once ready, start the USB connection with `usb_attach`
All MTD exported should appear as` /dev/sdX` on Linux.
### Issues/PRs references
Supersede #15941
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
17612: pkg: add FlashDB r=benpicco a=benpicco
19332: sys/tiny_strerror: make use of flash_utils.h r=benpicco a=benpicco
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
19292: sys/phydat: Fix unit confusion r=miri64 a=maribu
### Contribution description
Previously, `UNIT_G` was used for g-force with the correct symbol `g`, `UNIT_GR` for gram (as in kilogram) with the incorrect symbol `G` (which would be correct for Gauss), and `UNIT_GS` for Gauss with symbol `Gs` (which is an alternative correct symbol).
To avoid confusion between G-Force, Gauss, and Gram the units have been renamed to `UNIT_G_FORCE`, `UNIT_GRAM`, and `UNIT_GAUSS`. In addition, gram now uses the correct symbol `g`; which sadly is the same as for g-force. But usually there is enough context to tell them apart.
### Testing procedure
Green CI
### Issues/PRs references
None
19307: nanocoap_link_format: fix off-by-one error r=miri64 a=benpicco
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
18746: sys/clif: Fixing out of bounds read under certain conditions r=maribu a=Teufelchen1
Hi 😈
This fixes a potential out of bounds read in clif_encode_link. There is no code in RIOT that can be exploited.
The fix does not break the current API but alters the behaviour slightly. Before the change, the length attributes of `clif_attr_t` where optional. If missing, the length was deduced using `strlen()`. This fix makes those parameters required and if they are `0` it operates as if the length really is `0`. This might not be ideal but it is the only non api breaking fix I could think off.
```c
typedef struct {
char *value;
unsigned value_len; NO LONGER OPTIONAL
const char *key;
unsigned key_len; NO LONGER OPTIONAL
} clif_attr_t;
```
Depends on #18744
cc `@leandrolanzieri`
19161: bors.yaml: re-activate labels check + add block_labels r=miri64 a=miri64
Co-authored-by: Teufelchen1 <bennet.blischke@haw-hamburg.de>
Co-authored-by: Martine Lenders <m.lenders@fu-berlin.de>
Previously, `UNIT_G` was used for g-force with the correct symbol `g`,
`UNIT_GR` for gram (as in kilogram) with the incorrect symbol `G` (which
would be correct for Gauss), and `UNIT_GS` for Gauss with symbol `Gs`
(which is an uncommon but correct symbol).
To avoid confusion between G-Force, Gauss, and Gram the units have been
renamed to `UNIT_G_FORCE`, `UNIT_GRAM`, and `UNIT_GAUSS`. In addition,
gram now uses the correct symbol `g` and Gauss uses `G`.
19297: tests/rmutex: clean up test and reduce stack size r=maribu a=maribu
### Contribution description
As the title says. This results in a few more boards being able to run the test.
Also, the wording in the README.md is improved to not be interpreted as generally threads with lower thread ID being preferred over threads with higher when locking a mutex.
### Testing procedure
```
make -C tests/rmutex BOARD=foo flash test
```
### Issues/PRs references
Fixes https://github.com/RIOT-OS/RIOT/issues/19140
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
18392: drivers/servo: reimplement with high level interface r=benpicco a=maribu
### Contribution description
The previous servo driver didn't provide any benefit over using PWM directly, as users controlled the servo in terms of PWM duty cycles. This changes the interface to provide a high level interface that abstracts the gory PWM details.
In addition, a SAUL layer and auto-initialization is provided.
### Testing procedure
The test application provides access to the servo driver via the `saul` shell command.
```
> saul
2022-08-02 22:12:31,826 # saul
2022-08-02 22:12:31,827 # ID Class Name
2022-08-02 22:12:31,830 # #0 ACT_SWITCH LD1(green)
2022-08-02 22:12:31,832 # #1 ACT_SWITCH LD2(blue)
2022-08-02 22:12:31,834 # #2 ACT_SWITCH LD3(red)
2022-08-02 22:12:31,837 # #3 SENSE_BTN B1(User button)
2022-08-02 22:12:31,838 # #4 ACT_SERVO servo
> saul write 4 0
2022-08-02 22:12:41,443 # saul write 4 0
2022-08-02 22:12:41,445 # Writing to device #4 - servo
2022-08-02 22:12:41,447 # Data: 0
2022-08-02 22:12:41,450 # [servo] setting 0 to 2949 (0 / 255)
2022-08-02 22:12:41,453 # data successfully written to device #4
> saul write 4 256
2022-08-02 22:12:45,343 # saul write 4 256
2022-08-02 22:12:45,346 # Writing to device #4 - servo
2022-08-02 22:12:45,347 # Data: 256
2022-08-02 22:12:45,351 # [servo] setting 0 to 6865 (255 / 255)
2022-08-02 22:12:45,354 # data successfully written to device #4
```
Each write resulted in the MG90S servo that I connected to move to the corresponding position.
### Issues/PRs references
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
The previous servo driver didn't provide any benefit over using PWM
directly, as users controlled the servo in terms of PWM duty cycles.
This changes the interface to provide a high level interface that
abstracts the gory PWM details.
In addition, a SAUL layer and auto-initialization is provided.
Co-authored-by: benpicco <benpicco@googlemail.com>
19294: sys/shell: don't include suit command by default r=benpicco a=benpicco
19295: gcoap: Finish the gcoap_get_resource_list_tl -> gcoap_get_resource_list renaming r=benpicco a=chrysn
### Contribution description
In #16688, an argument was added to the `gcoap_get_resource_list` function by creating a new function `gcoap_get_resource_list_tl` with a deprecation and roll-over plan.
This plan has not been acted on so far.
This PR shortens the original plan by just adding the argument to `gcoap_get_resource_list` and removing `gcoap_get_resource_list_tl` in a single go. The rationale for this deviation is that while it's a public API, its only two practical consumers are the (built-in) well-known/core implementation, and the (built-in) CoRE Resource Directory (cord) endpoint. Moreover, a further change to this API (switching over to `coap_block_slicer_t`) is expected to happen within this release cycle, which would take something like 4 total releases to get through otherwise, which is unrealistic for an API that there are no known external users of.
A second commit clean up ToDo items (in the changed function's documentation) that referred to a IETF draft that has long been abandoned by the CoRE WG.
### Testing procedure
Plain inspection and CI passing should suffice.
### AOB
There is a second analogous pair left over from #16688, `gcoap_req_send` / `gcoap_req_send_tl`. As that *is* expected to be used widely, I prefer not to mix these two concerns, and get the present one through without unnecessary hold-up.
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: chrysn <chrysn@fsfe.org>
This is an API change in the latter, which would typically now take an
extra argument GCOAP_SOCKET_TYPE_UNDEF.
Follow-Up-For: https://github.com/RIOT-OS/RIOT/pull/16688
19256: pkg/tinyusb: add GD32VF103 support r=gschorcht a=gschorcht
### Contribution description
This PR provides the tinyUSB support for GD32VF103 and enables the `tinyusb_device` feature as well as `stdio_tinyusb_cdc_acm` for GD32VF103 boards.
### Testing procedure
```
BOARD=sipeeed-longan-nano make -C tests/shell flash term
```
should work
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
* riot-wrappers:
* Fix infinite loop when using a Mutex
* Make ValueInThread Copy/Clone
* riot-sys:
* Export xxx_DEV (eg. I2C_DEV) C macros as functions
* Add auto_init_utils.h
19284: boards: support for the LILYGO TTGO T8 ESP32-S2 board r=benpicco a=gschorcht
### Contribution description
This PR provides the support for the LILYGO TTGO T8 ESP32-S2 board which has a OLED display (not yet supported) and a SD-Card slot on board.
The board is equipped with a USB-C connector that connects either to a USB-to-UART bridge or to the USB-OTG/JTAG interface of the ESP32-S2 via some DIP switches.
The PR includes a very small fix of printf format string in `tests/malloc`. I can split it off.
### Testing procedure
t.b.d.
### Issues/PRs references
19286: cpu/esp_common: use generic WIFI_SSID/WIFI_PASS defines r=benpicco a=benpicco
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
19258: drivers/mtd_flashpage: implement pagewise API, don't use raw addresses r=benpicco a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
