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>
19488: usbus: remove deprecated USBUS_HANDLER_FLAG_TR_FAIL flag r=gschorcht a=dylad
### Contribution description
This PR removes the deprecated `USBUS_HANDLER_FLAG_TR_FAIL` flag.
### Testing procedure
CI should be enough.
### Issues/PRs references
Was deprecated by #17046
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
The shell_cmds module depends on the shell module. This was correctly
added to KConfig, but the Makefile dependencies missed this one. This
commit adds the missing dep.
19436: cpp11-compat: thread::sleep_for in microseconds r=benpicco a=kfessel
### Contribution description
after reviewing #19369 i found that there is a conversion to nanoseconds just to convert it to microseconds some instrunctions later for ztimer64_usec to handle it this removes one of the conversions (convert once direct to microseconds)
### Testing procedure
run the cpp tests
### Issues/PRs references
#19369
Co-authored-by: Karl Fessel <karl.fessel@ovgu.de>
Use symbol `USBDEV_SET_ADDR_AFTER_STATUS` to determine whether the device address has to be set directly after SETUP stage or after the associated STATUS stage.
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.
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>
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>
19392: ztimer: Fix doc on ztimer_remove r=benpicco a=bergzand
### Contribution description
See the subject
### Testing procedure
Read the modified docs
### Issues/PRs references
None
19398: gnrc_ipv6_static_addr: fix build with only static address r=benpicco a=benpicco
19399: drivers/usbdev_synopsys_dwc2: add ESP32x power management r=benpicco a=gschorcht
### Contribution description
This PR adds power management handling for ESP32x SoCs.
### Testing procedure
Use and ESP32-S2 or ESP32-S3 board and flash `tests/periph_pm` using the `stdio_cdc_acm`
```
USEMODULE=stdio_cdc_acm BOARD=esp32s3-devkit make -j8 -C tests/periph_pm flash
```
Connect the terminal to the board and execute command:
```
set_rtc 1 1
```
The console should continue to work after the 1-s light sleep.
### Issues/PRs references
Co-authored-by: Koen Zandberg <koen@bergzand.net>
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
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>
19386: usbus/dfu: do not create alt interface if NUM_SLOTS=1 r=benpicco a=dylad
### Contribution description
In some cases, it is really useful to build `riotboot` with `NUM_SLOTS=1`.
When use in combination with `riotboot_dfu`, there is no need to export the second slot if `riotboot` is built with `NUM_SLOTS=1`.
Thus, prevent the alt interface declaration in dfu if `NUM_SLOTS=1` so that only slot0 can be used to flash.
### Testing procedure
Add `NUM_SLOTS=1` to `bootloaders/riotboot_dfu/Makefile`
Flash the riotboot DFU bootloader to any board supported by USBUS:
`make BOARD=xxx -C bootloaders/riotboot_dfu flash`
and run
`dfu-util -l`
With NUM_SLOTS=2 you will get:
```
dfu-util -l
dfu-util 0.11
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
Found DFU: [1209:7d02] ver=0100, devnum=11, cfg=1, intf=0, path="1-4", alt=1, name="RIOT-OS Slot 1", serial="AB88DCAE80893484"
Found DFU: [1209:7d02] ver=0100, devnum=11, cfg=1, intf=0, path="1-4", alt=0, name="RIOT-OS Slot 0", serial="AB88DCAE80893484"
```
with NUM_SLOTS=1 you will get:
```
dfu-util -l
dfu-util 0.11
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
Found DFU: [1209:7d02] ver=0100, devnum=14, cfg=1, intf=0, path="1-4", alt=0, name="RIOT-OS Slot 0", serial="AB88DCAE80893484"
```
### Issues/PRs references
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
If riotboot is built with NUM_SLOTS=1, there is no reason to advertise a second slot in the bootloader
Signed-off-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
