19010: bootloaders/riotboot: add tinyUSB DFU support r=benpicco a=gschorcht
### Contribution description
This PR provides
- the tinyUSB DFU and DFU Runtime support and
- the `riotboot_tinyusb_dfu` bootloader that uses the tinyUSB DFU mode to flash new application images.
~This PR includes PR #18983 for now to be compilable.~
### Testing procedure
1. Use any board that supports the `riotboot´ and `tinyusb_device` features and flash the bootloader first, for example
```
BOARD=nucleo-f767zi make -C bootloaders/riotboot_tinyusb_dfu flash
```
and check that the `riotboot_tinyusb_dfu` bootloader is in DFU mode:
```
dfu-util --list
```
3. Flash a first application using the following command:
```
FEATURES_REQUIRED=riotboot USEMODULE=tinyusb_dfu BOARD=nucleo-f767zi \
make -C tests/saul PROGRAMMER=dfu-util riotboot/flash-slot0
```
and check that the application starts and is seen as upgradable:
```
dfu-util --list
```
4. Restart the node in bootloader DFU mode by:
```
dfu-util -e
```
Flash a second application, for example
```
FEATURES_REQUIRED=riotboot USEMODULE=tinyusb_dfu BOARD=nucleo-f767zi \
make -C tests/shell PROGRAMMER=dfu-util riotboot/flash-slot1
```
and check that the second application starts and is seen as upgradable:
```
dfu-util --list
```
### Issues/PRs references
~Depends on PR #18983~
19149: SECURITY: Describe that declassification is an option r=benpicco a=chrysn
### Contribution description
Our security policy does not contain provisions for the case when what is reported is not what we consider an actual security issue. As it is described now, everything reported through security@ would go through the full treatment, including a point release.
I'm not sure it belongs into the text itself (as it's more about how security reporters interact with the project than internals), but declassification should IMO be backed at least by 3 maintainers, and no strong NACK.
### Issues/PRs references
#19141 followed that procedure after some chat on it on the maintainers channel. (In the discussion, I proposed declassification, with 2.5 people supporting it and one "I was about to, but can we be sure nobody is using it?" voice).
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: chrysn <chrysn@fsfe.org>
17066: sys/irq: Add C++ wrapper using RAII r=maribu a=jenswet
### Contribution description
This adds a C++ wrapper around the `irq.h` API. The wrapper uses RAII to accomplish a convenient and bug resistent use.
A little background: I'm currently writing my master thesis on using C++ for embedded development, at the working group that `@maribu` is part of. For that I will try to add better C++ support to several parts of RIOT and then do some benchmarking and metrics to compare it with the C implementation. For example, I also plan to add a wrapper around i2c, a std::cout drop-in replacement and probably some more about networks or threads.
### Testing procedure
I've added a unit test to verify that the IRQ wrapper calls the original `irq` functions as expected. As C++ and wrapper testing isn't done much so far in this project, I've added two additional headers to ease testing:
1. #17076 - fake functions framework, already merged
2. As there is no framework for C++ unit tests yet, I've added something for this too. Unfortunately the existing frameworks like GoogleTest, CppUTest or CppUnit don't easily compile for embedded or are difficult to integrate in to the RIOT build process. That's why I wrote some (simple) helper functions and macros inspired by the above frameworks. That allows to create C++ tests based on a fixture class with set up and tear down methods. It also allows some simple assertions and is easily extendable for other use cases. It wraps some of the fff functionality too.
Both of this is obviously not required for the initial reason of this PR. But I'd like to provide unit tests for the features that I suggest to introduce where possible. So I'd appreciate some feedback on that too. If you'd prefer a PR without or different tests please let me know.
You can run the test `irq_cpp` locally or on the CI to test the implementation.
Please feel free to give feedback or suggest improvements!
Co-authored-by: Jens Wetterich <jens@wetterich-net.de>
17460: pkg/arduino_adafruit_sensor: add Adafruit Unified Sensor Driver as package r=benpicco a=gschorcht
### Contribution description
This PR provides the [Adafruit Unified Sensor Driver](https://github.com/adafruit/Adafruit_Sensor) as package.
There are a number of Adafruit sensor drivers which all use a common base class `Adafruit_Sensor` from the [Adafruit Unified Sensor Driver](https://github.com/adafruit/Adafruit_Sensor). To support such drivers, the Adafruit Unified Sensor Driver is provided as package.
Adafruit sensor driver for ST LSM9DS0 will be provided as separat PR as package for demonstration and testing.
PR #12518 will be rebased for testing to have an Adafruit sensor driver for a sensor for which there is a native driver in RIOT.
### Testing procedure
Use a board that provides the `arduino` feature and flash
```
BOARD=... make -C tests/pkg_arduino_adafruit_sensor flash test
```
PR #12518 can be used as a more complex test for using the package.
### Issues/PRs references
Prerequisite for PR #12518
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
18763: sys/tiny_strerror: add missing error codes r=benpicco a=maribu
### Contribution description
When double-checking the error codes provided by newlib by default (without magic defines, such as `__LINUX_ERRNO_EXTENSIONS__` or `__CYGWIN__`), some where still missing in `tiny_strerror()`. This adds the missing ones.
This in turn showed that three errno codes were missing in the avr-libc compat `errno.h`, which are added as well.
### Testing procedure
Murdock should double check that the added errno codes indeed are defined by default.
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
19146: cpu/esp32: fix and improve UART initialization r=benpicco a=gschorcht
### Contribution description
This PR fixes issue #19138 that was introduced with PR #19100. It contains the following changes to fix the problems and to improve the UART initialization:
- If `LOG_LEVEL` is greater or equal 4, such as in `tests/log_printfnoformat`, the ESP-IDF config function called for the GPIO pins of the UART will output the configuration with `printf` before the `_GLOBAL_REENT` structure is initialized. This causes a crash during system startup. Therefore the initialization by `syscalls_init` must be called by `earlier in the startup procedure.
- Since PR #19100 it is possible to define:
- other pins for `UART_DEV(0)` than the default pins
- different `UART_DEV(0)` pins for the bootloader and RIOT
To allow correct reinitialization of the UART pins used by the bootloader as well as their usage for other purposes, the pin usage for the default UART0 pins and the UART pinsused by the bootloader are reset to `_GPIO`. This is done in `uart_system_init` which has to be called earlier in the startup procedure.
- To avoid garbage on reconfiguring the UART console pins, e.g. in initialization of the `arduino` module, pins that are already configured as UART pins must not be initialized.
- To avoid a several msec long LOW pulse resulting in some garbage during the UART initialization, the TX line is set to HIGH and temporarily configured as a pull-up open-drain output before configuring it as a push-pull output.
The PR requires a backport to 2023.1
### Testing procedure
The following tests should work with this PR:
- [ ] `tests/log_color`
- [ ] `tests/log_printfnoformat`
- [ ] `tests/sys_arduino`
### Issues/PRs references
Fixes#19138
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19071: boards/rpi-pico-w: initial support for rpi pico W board r=maribu a=krzysztof-cabaj
### Contribution description
This PR adds initial RIOT OS support for the Raspberry Pico W - the Raspberry Pico with a Wifi/Bluetooth Infineon CYW 43439 module (*).
The code is based on PR #15822 and contains changes associated with small differences between RPi Pico and Pico W. The most important is that LED0 is connected to the CYW 43439 module and without PIO (PR #17425) cannot be used (RP2040 and CYW 43439 are connected together using SPI and Pico SDK utilize PIO to program SPI). Current LED0 implementation is similar to one for `native` board and prints appropriate texts on STDIO.
(*) Currently network connectivity not implemented.
### Testing procedure
Flash sample program and look at doc:
```
make doc
xdg-open doc/doxygen/html/group__boards__rpi__pico__w.html
```
### Issues/PRs references
Based on PR #15822.
Needs PR #17425.
Additional doc:
[Raspberry Pi Pico and Pico W](https://www.raspberrypi.com/documentation/microcontrollers/raspberry-pi-pico.html)
Co-authored-by: krzysztof-cabaj <kcabaj@gmail.com>
To avoid garbage on reconfiguring the UART console pins, e.g. in initialization of the `arduino` module, pins that are already configured as UART pins must not be initialized.
The TX line is set and temporarily configured as a pull-up open-drain output before configuring it as a push-pull output to avoid a several msec long LOW pulse resulting in some garbage.
Since PR #19100 it is possible to define:
- other pins for `UART_DEV(0)` than the default pins
- different `UART_DEV(0)` pins for the bootloader and RIOT
To allow correct reinitialization of the UART pins used by the bootloader as well as their usage for other purposes, the pin usage for the default UART0 pins and the UART pins used by the bootloader are reset to `_GPIO`. This is done in `uart_system_init` which has to be called earlier in the startup procedure.
If LOG_LEVEL >= 4, such as in `tests/log_printfnoformat`, the ESP-IDF config function called for the GPIO pins of the UART will output the configuration with `printf` before the `_GLOBAL_REENT` structure is initialized. This causes a crash during system startup. Therefore the initialization by `syscalls_init` must be called earlier in the startup procedure.
19141: shell/rtc: Fix out of bounds access; document error behavior r=maribu a=chrysn
### Contribution description
### Testing procedure
Should be trivial enough, especially as the difference is hard to spot interactively.
On native, run the default example (and wait for the traffic to settle).
Then, run
```
> rtc poweron
> rtc settime 2022-01-01 00:00:00
> rtc settime 2022-99-01 00:00:00
```
Both still work, but the latter doesn't access unassigned memory any more
### Issues/PRs references
This fixes an issue that was submitted anonymously.
Co-authored-by: chrysn <chrysn@fsfe.org>
With b30efeeb65 a warning was introduced when using `make term` without
the proper toolchain installed (e.g. when using BUILD_IN_DOCKER, but
`term` outside of the docker). This removes this warning
19050: boards/common/cc26xx cc13xx: clean up and fix flash configs r=benpicco a=maribu
### Contribution description
- Add support for XDS110 debugger via `OPENOCD_DEBUG_ADAPTER=xds110`
- Clean up OpenOCD configs in `boards/common/cc26xx_cc13xx`
- No longer hardcode the debugger to xds110, but use `OPENOCD_DEBUG_ADATER ?= xds110`
- Add support for cc13x0, cc13x2, cc26x0
- `boards/cc2650*`: drop custom OpenOCD config in favor of shared one
- add variables needed to support flashing with `PROGRAMMER=jlink`
- allow specifying a custom OpenOCD command to bring the device to a halt state, as the default `reset halt` (which causes a second reset) is causing issues with the ICEPick JTAG routers in the CC26xx - CC13xx devices
- Use `halt` instead of `reset halt` for CC26xx / CC13xx boards in OpenOCD to avoid issues in flashing
### Testing procedure
```
make BOARD=cc2650-launchpad -C examples/default flash
```
Should now work. The same should still work for other cc26xx cc13xx boards.
### Issues/PRs references
Partially fixes: https://github.com/RIOT-OS/RIOT/issues/18750
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
19102: gh-actions: report release-tests result to Matrix r=maribu a=miri64
19128: boards: common: stdio_cdc_acm: let tests wait a bit for serial port r=miri64 a=miri64
19133: makefiles/utils/strings.mk: Fix version_is_greater_or_equal r=maribu a=maribu
### Contribution description
The Makefile function `version_is_greater_or_equal` is used to check if a version of GNU Make is at least the required one. However, it has the built-in assumption the version numbers have to format x.y.z, but Alpine Linux currently ships GNU Make 4.4. This results in `$(call _pad_number,3,)` which runs `printf '$03d' ''` in the shell, which is not valid.
This fixes the issue by making `_pad_number` more robust by fall back to printing `0` with the given padding, if the number given to print is empty.
### Testing procedure
Append
```Makefile
$(info A=$(call version_is_greater_or_equal,4.2.0,4.2.0))
$(info B=$(call version_is_greater_or_equal,4.2,4.2.0))
$(info C=$(call version_is_greater_or_equal,4.1,4.2.0))
$(info D=$(call version_is_greater_or_equal,4.1.9,4.2.0))
$(info E=$(call version_is_greater_or_equal,5.1.9,4.2.0))
$(info F=$(call version_is_greater_or_equal,5.0.0,4.2.0))
$(info G=$(call version_is_greater_or_equal,4.2.1,4.2.0))
$(info H=$(call version_is_greater_or_equal,4.3.1,4.2.0))
```
e.g. to `makefiles/utils/strings.mk`, build something and observe the info output.
This yields
```
A=1
B=1
C=
D=
E=1
F=1
G=1
H=1
```
for me and does not complain about invalid `printf` invocations.
### Issues/PRs references
None
Co-authored-by: Martine Lenders <m.lenders@fu-berlin.de>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
The Makefile function `version_is_greater_or_equal` is used to check if
a version of GNU Make is at least the required one. However, it has
the built-in assumption the version numbers have to format x.y.z,
but Alpine Linux currently ships GNU Make 4.4. This results in
`$(call _pad_number,3,)` which runs `printf '$03d' ''` in the shell,
which is not valid.
This fixes the issue by making `_pad_number` more robust by fall back to
printing `0` with the given padding, if the number given to print is
empty.
When double-checking the error codes provided by newlib by default
(without magic defines, such as `__LINUX_ERRNO_EXTENSIONS__` or
`__CYGWIN__`), some where still missing in `tiny_strerror()`. This
adds the missing ones.
