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>
19375: tools/renode: add support for target reset r=benpicco a=aabadie
19376: boards/stm32f4discovery: use default port to access stdio via cdc acm r=benpicco a=aabadie
19377: pkg/tinyusb: fix default VID/PID configuration r=benpicco a=gschorcht
### Contribution description
This PR fixes the default VID/PID configuration if tinyUSB board reset feature is used.
While reviewing PR #19086 I was wondering why `esp32s2-wemos-mini` requires to set `USB_VID`/`USB_PID` explicitly to `USB_VID_TESTING`/`USB_PID_TESTING`. The reason was that tinyUSB board reset feature wasn't declared as RIOT internal.
### Testing procedure
Flashing `esp32s2-wemos-mini` should still work.
```
BOARD=esp32s2-wemos-mini make -C tests/shell flash
```
The VID/PID should be `1209:7d00` and not `1209:7d01`.
### Issues/PRs references
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Defining the feature as RIOT internal avoids that the board has to set USB_VID and USB_PID explicit to USB_VID_TESTInG/USB_PID_TESTING if tinyUSB board reset feature is used.
- Changed user provided synchronization functions in order to completely eliminate the platform dependency from FatFs code.
- Fixed a potential error in f_mount when FF_FS_REENTRANT.
- Fixed file lock control FF_FS_LOCK is not mutal excluded when FF_FS_REENTRANT && FF_VOLUMES > 1 is true.
- Fixed f_mkfs creates broken exFAT volume when the size of volume is >= 2^32 sectors.
- Fixed string functions cannot write the unicode characters not in BMP when FF_LFN_UNICODE == 2 (UTF-8).
- Fixed a compatibility issue in identification of GPT header.
19331: pkg/tinydtls: Adjust defaults r=miri64 a=chrysn
### Contribution description
This adjusts two defaults in tinydtls:
* Default verbosity is set to warning. At the info level, this module produces way more output (several lines per new connection, and even per message) than is common in RIOT.
* If gcoap is used, the buffer size is adjusted to the gcoap buffer size plus overhead. Otherwise, CoAP-over-DTLS works fine until one happens to request larger resources.
### Testing procedure
* Run examples/gcoap_dtls
* Send a CoAP request from outside, eg. with `aiocoap-client 'coaps://[fe80::3c63:beff:fe85:ca96%tapbr0]/.well-known/core' --credentials testserver.json` (where testserver.json is `{"coaps://[fe80::3c63:beff:fe85:ca96%tapbr0]/*": {"dtls": {"psk": {"ascii": "secretPSK"}, "client-identity": {"ascii": "Client_identity"}}}}`).
Before, there are messages shown for every request; now there are none.
Modify `examples/gcoap/server.c` as follows:
```patch
diff --git a/examples/gcoap/server.c b/examples/gcoap/server.c
index bf2315cd01..28e1faac27 100644
--- a/examples/gcoap/server.c
+++ b/examples/gcoap/server.c
`@@` -68,7 +68,7 `@@` static const coap_resource_t _resources[] = {
};
static const char *_link_params[] = {
- ";ct=0;rt=\"count\";obs",
+ ";ct=0;rt=\"count\";obs;looooooooooooooooooooooong-attribute=\"loooooooooooooooooooooooooooooong\"",
NULL
};
```
The request passes; without this patch, it is stuck in retransmissions until "Network error: Retransmissions exceeded".
### Issues/PRs references
This contributes to making #19289 usable with a minimum level of security. (That module fills up the gcoap buffer to the brim). While the module handles the verbosity as well as it can (occasionally admitting that it lost bytes of output), the previous verbosity produces an infinite stream of stdout data. (But the default should be quiet immaterial of that particular PR).
Co-authored-by: chrysn <chrysn@fsfe.org>
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>
19247: pkg/tinydtls: drop libc_gettimeofday dependency r=benpicco a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
18682: pkg/lwext4: add lightweight implementation of the ext2/3/4 filesystem r=benpicco a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
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>
18903: pkg/tinyusb: add tinyUSB netdev driver r=dylad a=gschorcht
### Contribution description
This PR adds the tinyUSB netdev driver.
The tinyUSB netdev driver is part of the tinyUSB package and is enabled by module `tinyusb_netdev`. It is available for boards that provide the `tinyusb_device` feature.
**Please note** Since the tinyUSB package is distinct from (and incompatible with) the USB stack provided around USBUS in RIOT (see USB), the tinyUSB netdev driver cannot be used together with with any USBUS device class.
The tinyUSB netdev driver uses Ethernet over USB and supports the following protocols:
- CDC ECM (Ethernet Control Model)
- CDC NCM (Network Control Model)
- RNDIS (Microsoft Remote NDIS)
While Linux and macOS support all these protocols, Microsoft Windows only supports the RNDIS protocol and since Windows version 11 also the CDC NCM protocol. macOS supports the RNDIS protocol since version 10.15 (Catalina).
Which protocol is used is selected by the corresponding pseudomodules `tinyusb_class_net_cdc_ecm`, `tinyusb_class_net_cdc_ncm` and `tinyusb_class_net_rndis`.
The CDC ECM protocol (`tinyusb_class_net_cdc_ecm`) and the RNDIS protocol (`tinyusb_class_net_rndis`) can be used simultaneously to support all operating systems, for example :
```
USEMODULE='tinyusb_netdev tinyusb_class_net_rndis tinyusb_class_net_cdc_ecm' \
BOARD=... make -C ... flash
```
In this case, the CDC ECM protocol is the default protocol and the RNDIS protocol the alternative protocol defined as second device configuration. The CDC NCM protocol cannot be used together with the CDC ECM or the RNDIS protocol.
This PR includes PR #18983 for now to be compilable.
Comparison with USBUS CDC ECM (`nucleo-f767zi` board):
```
text data bss dec hex filename
65916 596 18728 85240 14cf8 tests_pkg_tinyusb_netdev.elf
```
```
text data bss dec hex filename
63120 544 15444 79108 13504 tests_usbus_cdc_ecm.elf
```
### Testing procedure
Use a board that is supported by tinyUSB. Compile and flash the test application for each protocol:
1. RNDIS
```
BOARD=... make -j8 -C tests/pkg_tinyusb_netdev flash
```
2. CDC ECM
```
CLASS=tinyusb_class_net_cdc_ecm BOARD=... make -j8 -C tests/pkg_tinyusb_netdev flash
```
3. CDC NCM
```
CLASS=tinyusb_class_net_cdc_ncm BOARD=... make -j8 -C tests/pkg_tinyusb_netdev flash
```
For each test, a network interface should be added on the host. Use command `ifconfig` on USB device and on the host and check that both have a link local address. In syslog there should be an output like the following:
<details>
```
Nov 13 18:14:46 gunny8 kernel: [4611465.480025] usb 1-2.2: new full-speed USB device number 28 using xhci_hcd
Nov 13 18:14:47 gunny8 kernel: [4611465.581641] usb 1-2.2: New USB device found, idVendor=1209, idProduct=7d01, bcdDevice= 1.00
Nov 13 18:14:47 gunny8 kernel: [4611465.581646] usb 1-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Nov 13 18:14:47 gunny8 kernel: [4611465.581650] usb 1-2.2: Product: nucleo-f767zi
Nov 13 18:14:47 gunny8 kernel: [4611465.581653] usb 1-2.2: Manufacturer: RIOT-os.org
Nov 13 18:14:47 gunny8 kernel: [4611465.581654] usb 1-2.2: SerialNumber: 6591620BCB270283
Nov 13 18:14:47 gunny8 vmnetBridge: RTM_NEWLINK: name:usb0 index:508 flags:0x00001002
Nov 13 18:14:47 gunny8 vmnet-natd: RTM_NEWLINK: name:usb0 index:508 flags:0x00001002
Nov 13 18:14:47 gunny8 NetworkManager[24229]: <info> [1668359687.1066] manager: (usb0): new Ethernet device (/org/freedesktop/NetworkManager/Devices/528)
Nov 13 18:14:47 gunny8 kernel: [4611465.594604] rndis_host 1-2.2:1.0 usb0: register 'rndis_host' at usb-0000:00:14.0-2.2, RNDIS device, fa:db:7c:1b:58:80
Nov 13 18:14:47 gunny8 mtp-probe: checking bus 1, device 28: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.2"
Nov 13 18:14:47 gunny8 mtp-probe: bus: 1, device: 28 was not an MTP device
Nov 13 18:14:47 gunny8 systemd-udevd[17796]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Nov 13 18:14:47 gunny8 vmnet-natd: RTM_NEWLINK: name:usb0 index:508 flags:0x00001002
Nov 13 18:14:47 gunny8 kernel: [4611465.643852] rndis_host 1-2.2:1.0 enp0s20f0u2u2: renamed from usb0
Nov 13 18:14:47 gunny8 vmnetBridge: RTM_NEWLINK: name:usb0 index:508 flags:0x00001002
Nov 13 18:14:47 gunny8 vmnet-natd: RTM_NEWLINK: name:enp0s20f0u2u2 index:508 flags:0x00001002
Nov 13 18:14:47 gunny8 vmnetBridge: RTM_NEWLINK: name:enp0s20f0u2u2 index:508 flags:0x00001002
Nov 13 18:14:47 gunny8 NetworkManager[24229]: <info> [1668359687.1833] device (usb0): interface index 508 renamed iface from 'usb0' to 'enp0s20f0u2u2'
Nov 13 18:14:47 gunny8 upowerd[2845]: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.2/1-2.2:1.1
Nov 13 18:14:47 gunny8 NetworkManager[24229]: <info> [1668359687.2037] device (enp0s20f0u2u2): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external')
Nov 13 18:14:47 gunny8 vmnet-natd: RTM_NEWLINK: name:enp0s20f0u2u2 index:508 flags:0x00011043
Nov 13 18:14:47 gunny8 vmnetBridge: RTM_NEWLINK: name:enp0s20f0u2u2 index:508 flags:0x00011043
Nov 13 18:14:47 gunny8 vmnetBridge: Adding interface enp0s20f0u2u2 index:508
Nov 13 18:14:47 gunny8 NetworkManager[24229]: <info> [1668359687.2075] device (enp0s20f0u2u2): carrier: link connected
Nov 13 18:14:47 gunny8 upowerd[2845]: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.2/1-2.2:1.0
Nov 13 18:14:47 gunny8 NetworkManager[24229]: <info> [1668359687.2129] settings: (enp0s20f0u2u2): created default wired connection 'Kabelgebundene Verbindung 2'
Nov 13 18:14:47 gunny8 NetworkManager[24229]: <warn> [1668359687.2142] device (enp0s20f0u2u2): connectivity: "/proc/sys/net/ipv4/conf/enp0s20f0u2u2/rp_filter" is set to "1". This might break connectivity checking for IPv4 on this device
Nov 13 18:14:47 gunny8 NetworkManager[24229]: <info> [1668359687.2151] device (enp0s20f0u2u2): state change: unavailable -> disconnected (reason 'none', sys-iface-state: 'managed')
Nov 13 18:14:47 gunny8 vmnetBridge: RTM_NEWLINK: name:enp0s20f0u2u2 index:508 flags:0x00011043
Nov 13 18:14:47 gunny8 vmnet-natd: RTM_NEWLINK: name:enp0s20f0u2u2 index:508 flags:0x00011043
Nov 13 18:14:47 gunny8 upowerd[2845]: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.2
Nov 13 18:14:47 gunny8 systemd-udevd[17796]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Nov 13 18:14:47 gunny8 NetworkManager[24229]: <info> [1668359687.2403] policy: auto-activating connection 'Kabelgebundene Verbindung 2' (0b1ae45e-c76e-3efb-a2cd-138ca2b2a59c)
Nov 13 18:14:47 gunny8 NetworkManager[24229]: <info> [1668359687.2414] device (enp0s20f0u2u2): Activation: starting connection 'Kabelgebundene Verbindung 2' (0b1ae45e-c76e-3efb-a2cd-138ca2b2a59c)
Nov 13 18:14:47 gunny8 NetworkManager[24229]: <info> [1668359687.2419] device (enp0s20f0u2u2): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Nov 13 18:14:47 gunny8 NetworkManager[24229]: <info> [1668359687.2429] device (enp0s20f0u2u2): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Nov 13 18:14:47 gunny8 NetworkManager[24229]: <info> [1668359687.2440] device (enp0s20f0u2u2): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Nov 13 18:14:47 gunny8 NetworkManager[24229]: <info> [1668359687.2445] dhcp4 (enp0s20f0u2u2): activation: beginning transaction (timeout in 45 seconds)
Nov 13 18:14:47 gunny8 vmnetBridge: RTM_NEWLINK: name:enp0s20f0u2u2 index:508 flags:0x00011043
Nov 13 18:14:47 gunny8 vmnet-natd: RTM_NEWLINK: name:enp0s20f0u2u2 index:508 flags:0x00011043
Nov 13 18:14:47 gunny8 avahi-daemon[1464]: Joining mDNS multicast group on interface enp0s20f0u2u2.IPv6 with address fe80::dba4:adb8:9ffe:d93e.
Nov 13 18:14:47 gunny8 avahi-daemon[1464]: New relevant interface enp0s20f0u2u2.IPv6 for mDNS.
Nov 13 18:14:47 gunny8 avahi-daemon[1464]: Registering new address record for fe80::dba4:adb8:9ffe:d93e on enp0s20f0u2u2.*.
Nov 13 18:14:47 gunny8 kernel: [4611465.895046] userif-1: sent link down event.
Nov 13 18:14:47 gunny8 kernel: [4611465.895052] userif-1: sent link up event.
```
</details>
Ping from and to the host.
### Issues/PRs references
Depends on PR https://github.com/RIOT-OS/RIOT/pull/18983
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19185: cpu/gd32v: add periph_gpio_irq support r=gschorcht a=gschorcht
### Contribution description
This PR provides the `periph_gpio_irq` support and is one of a bunch of follow up PRs that complete the peripheral drivers for GD32VF103.
### Testing procedure
Use a GD32VF103 board and flash `tests/periph_gpio`. Note: The Sipeed Longan Nano works also with `seeedstudio-gd32` board defintion and could be used for testing.
```
BOARD=seeedstudio-gd32 make -C tests/periph_gpio flash (until PR #19170 is merged only `seeedstudio
```
With the GPIO PB8 and PB9 connected, the following test sequence should work:
```
> init_out 1 8
> init_int 1 9 2 0
GPIO_PIN(1, 9) successfully initialized as ext int
> set 1 8
INT: external interrupt from pin 9
> clear 1 8
INT: external interrupt from pin 9
```
### Issues/PRs references
19187: cpu/gd32v: add pm_layered support in periph_pm r=gschorcht a=gschorcht
### Contribution description
This PR provides the `pm_layered` support and is one of a bunch of follow up PRs that complete the peripheral drivers for GD32VF103.
Since the configuration of the deep sleep and the standby mode require the access CSR (control and status registers) of the MCU, the Nuclei-SDK NMSIS is added as package which provides a low-level interface for Nuclei-based RISC-V MCUs.
### Testing procedure
The best way to test it is to rebase this PR onto PR #19186 and to flash `tests/periph_pm` to any GD32VF103 board. Note: The Sipeed Longan Nano works also with `seeedstudio-gd32` board definition and could be used for testing.
```
BOARD=seeedstudio-gd32 make -C tests/periph_pm flash
```
The test output should be:
```
main(): This is RIOT! (Version: 2023.04-devel-174-g7dc91-cpu/gd32v/periph_pm_test)
...
mode 0 blockers: 1
mode 1 blockers: 2
mode 2 blockers: 0
Lowest allowed mode: 2
```
Using command the `set_rtc 1 5` command should let the MCU deep sleep for 5 seconds
```
> set_rtc 1 5
Setting power mode 1 for 5 seconds.
␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀>
```
while command `set_rtc 1 5` should set the MCU into the standby mode which is left with restart.
```
> set_rtc 0 5
Setting power mode 0 for 5 seconds.
main(): This is RIOT! (Version: 2023.04-devel-174-g7dc91-cpu/gd32v/periph_pm_test)
...
mode 0 blockers: 1
mode 1 blockers: 2
mode 2 blockers: 0
Lowest allowed mode: 2
>
```
The garbage on UART interface after deep sleep is caused by the clock synchronisation that becomes necessary after deep sleep and is the same as for other boards.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19179: pkg/nanopb: bump version to 0.4.7 r=benpicco a=benpicco
19180: pkg/lz4: bump version to 1.9.4 r=benpicco a=benpicco
19183: pkg/minmea: bump version r=benpicco a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
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>
Patching a package creates a new HEAD of the package repository. Using `git describe --tag` to generate a version string used for the ESP8266 bootloader therefore generates a different version string for each new compilation, which in turn results in different hash values of the binaries for the same application in subsequent compilations in CI. To use the commit in `git describe --tag` for commit used by the package, the commit has to specified in the command.
The macros CONCAT(), MIN(), and MAX() are defined over and over again in
RIOT's code base. This de-duplicates the code by moving the macros to a
common place.
19037: sys/usb, pkg/tinyusb: move USB board reset from highlevel STDIO to CDC ACM r=dylad a=gschorcht
### Contribution description
The USB board reset function `usb_board_reset_coding_cb` can be used on any CDC-ACM interface, even if the CDC ACM interface is not used as high-level STDIO. Therefore, this PR provides the following changes:
- The call of the board reset function `usb_board_reset_coding_cb` from USBUS stack has been moved from the STDIO CDC ACM implementation to the CDC ACM implementation and is thus a feature of any USBUS CDC ACM interface which does not necessarily have to be used as highlevel STDIO.
- The call of the board reset function `usb_board_reset_coding_cb` from tinyUSB stack been moved from module `tinyusb_stdio_cdc_acm` to module `tinyusb_contrib` and is compiled in if the `tinyusb_class_cdc` module is used together the `tinyusb_device` module. Thus, it is now a feature of the tinyUSB CDC ACM interface, which does not necessarily have to be used as highlevel STDIO.
- The `usb_board_reset` module defines the `usb_board_reset_in_bootloader` function as a weak symbol to be used when reset in bootloader if no real implementation of this function is compiled in and the `riotboot_reset` module is not used. It only prints an error message that the reset in bootloader is not supported. This is necessary if the module `usb_board_reset` is used to be able to restart the board with an application via a USB CDC ACM interface, but the board's bootloader does not support the reset in bootloader feature.
- A test application has been added that either uses the highlevel STDIO `stdio_acm_cdc` or creates a CDC-ACM interface to enable board resets via USB. If the `usbus_dfu` module is used, it also initializes the DFU interface to be able to work together with the `riotboot_dfu` bootloader.
### Testing procedure
1. Use a board with a bootloader that supports the reset in bootloader via USB, but don't use the highlevel STDIO to check that it works with `usbus_cdc_acm`, for example:
```python
USEMODULE=stdio_uart BOARD=arduino-mkr1000 make -C tests/usb_board_reset flash
```
After reset in application with command
```python
stty -F /dev/ttyACM0 raw ispeed 600 ospeed 600 cs8 -cstopb ignpar eol 255 eof 255
```
command `dmesg` should give an output like the following with RIOT's test VID/PID:
```python
dmesg
[1745182.057403] usb 1-4.1.2: new full-speed USB device number 69 using xhci_hcd
[1745182.160386] usb 1-4.1.2: New USB device found, idVendor=1209, idProduct=7d01, bcdDevice= 1.00
[1745182.160390] usb 1-4.1.2: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[1745182.160392] usb 1-4.1.2: Product: arduino-mkr1000
[1745182.160393] usb 1-4.1.2: Manufacturer: RIOT-os.org
[1745182.160395] usb 1-4.1.2: SerialNumber: 6B6C2CA5229020D8
[1745182.170982] cdc_acm 1-4.1.2:1.0: ttyACM0: USB ACM device
```
After reset in bootloader with command
```python
stty -F /dev/ttyACM0 raw ispeed 1200 ospeed 1200 cs8 -cstopb ignpar eol 255 eof 255
```
command `dmesg` should give an output like the following with vendor VID/PID:
```python
[1746220.443792] usb 1-4.1.2: new full-speed USB device number 70 using xhci_hcd
[1746220.544705] usb 1-4.1.2: New USB device found, idVendor=2341, idProduct=024e, bcdDevice= 2.00
[1746220.544708] usb 1-4.1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[1746220.553471] cdc_acm 1-4.1.2:1.0: ttyACM0: USB ACM device
```
2. Test the same as in 1., but this time use the highlevel STDIO to check that there is no regression and it still works with `stdio_cdc_acm`, for example:
```python
BOARD=arduino-mkr1000 make -C tests/usb_board_reset flash
```
3. Use a board that supports `riotboot_dfu` but doesn't use the highlevel STDIO and flash the `riotboot_dfu` bootloader, for example:
```python
BOARD=stm32f429i-disc1 make -C bootloaders/riotboot_dfu flash term
```
Once the bootloader is flashed, command `dfu-util --list` should give something like the following:
```python
Found DFU: [1209:7d02] ver=0100, devnum=14, cfg=1, intf=0, path="1-2", alt=1, name="RIOT-OS Slot 1", serial="6591620BCB270283"
Found DFU: [1209:7d02] ver=0100, devnum=14, cfg=1, intf=0, path="1-2", alt=0, name="RIOT-OS Slot 0", serial="6591620BCB270283"
```
If the output gives only
```python
Found Runtime: [1209:7d00] ver=0100, devnum=123, cfg=1, intf=0, path="1-2", alt=0, name="RIOT-OS bootloader", serial="6591620BCB270283"
```
an application is already running in DFU Runtime mode. Use `dfu-util -e` to restart it in bootloader DFU mode.
Then flash the test application, for example:
```python
FEATURES_REQUIRED=riotboot USEMODULE='usbus_dfu riotboot_reset' \
BOARD=stm32f429i-disc1 make -C tests/usbus_board_reset PROGRAMMER=dfu-util riotboot/flash-slot0
```
Once the test application is flashed, command `dfu-util --list` should give:
```python
Found Runtime: [1209:7d00] ver=0100, devnum=123, cfg=1, intf=0, path="1-2", alt=0, name="RIOT-OS bootloader", serial="6591620BCB270283"
```
Now, use command
```python
stty -F /dev/ttyACM1 raw ispeed 600 ospeed 600 cs8 -cstopb ignpar eol 255 eof 255
```
to restart the board in application. Command `dfu-util --list` should give again the following:
```python
Found Runtime: [1209:7d00] ver=0100, devnum=123, cfg=1, intf=0, path="1-2", alt=0, name="RIOT-OS bootloader", serial="6591620BCB270283"
```
That is, the application is running in DFU Runtime mode. Then use command
```python
stty -F /dev/ttyACM1 raw ispeed 1200 ospeed 1200 cs8 -cstopb ignpar eol 255 eof 255
```
to restart the board in bootloader DFU mode. Command `dfu-util --list` should now give the following:
```python
Found DFU: [1209:7d02] ver=0100, devnum=50, cfg=1, intf=0, path="1-2", alt=1, name="RIOT-OS Slot 1", serial="7D156425A950A8EB"
Found DFU: [1209:7d02] ver=0100, devnum=50, cfg=1, intf=0, path="1-2", alt=0, name="RIOT-OS Slot 0", serial="7D156425A950A8EB"
```
That is, the bootloader is in DFU mode and another application can be flash.
4. After a hard reset of the board under 3., try the commands `reboot` and `bootloader`.
5. To check the same for tinyUSB, use the existing tinyUSB application with a CDC ACM interface and add module `usb_board_reset`, for example:
```python
USEMODULE=usb_board_reset BOARD=stm32f429i-disc1 make -C tests/pkg_tinyusb_cdc_msc flash term
```
After flashing, it should be possible to restart the application with command:
```python
stty -F /dev/ttyACM1 raw ispeed 600 ospeed 600 cs8 -cstopb ignpar eol 255 eof 255
```
When using command
```python
stty -F /dev/ttyACM1 raw ispeed 1200 ospeed 1200 cs8 -cstopb ignpar eol 255 eof 255
```
the following error message should be shown in terminal
```python
[cdc-acm] reset in bootloader is not supported
```
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
The board reset function can be used on any CDC ACM interface. It is not necessary that the tinyUSB CDC ACM STDIO is used. Therefore, the board reset function is now a feature of the CDC ACM interface that don't require any other functionality.
We had four versions of pre-built bootloaders for the esp8266 with
different settings of logging and color logging. These bootloaders were
manually built from the SDK and shipped with RIOT-OS source code.
However there are more settings that affect the bootloader build that
are relevant to the app or final board that uses this bootloader. In
particular, flash size and flash speed is important for the bootloader
to be able to load an app from a large partition table at the fastest
speed supported by the board layout and flash chip.
Another example is the UART baudrate of the logging output from the
bootloader. The boot ROM will normally start at a baud rate of 74880
(depending on the crystal installed), so it might make sense to keep
the UART output at the same speed so we can debug boot modes and
bootloader with the same terminal.
This patch builds the bootloader.bin file from the ESP8266 SDK source
code. The code is built as a module (esp8266_bootloader) which at the
moment doesn't generate any object code for the application and only
produces a bootloader.bin file set to the BOOTLOADER_BIN make variable
for the esptool.inc.mk to flash.
The code needs to be compiled and linked with custom rules defined in
the module's Makefile since the bootloader.bin is its own separate
application.
The `BOOTLOADER_BIN` variable is changed from a path relative to the
`$(RIOTCPU)/$(CPU)/bin/` directory to be full path. This makes it easier
for applications or board to provide their own bootloader binary if
needed.
As a result of building the bootloader from source we fixed the issue of
having a large partition table. Fixes#16402.
A number of Adafruit sensor drivers use the class Adafruit_Sensor from the Adafruit Unified Sensor Driver. To support such drivers, the Adafruit Unified Sensor Driver is imported as package.
18962: pkg/lwip: Force loglevel when using log module r=maribu a=yarrick
18999: Paho: Allow building for 8 and 16 bit platforms r=maribu a=OlegHahm
### Contribution description
Providing a patch to Paho upstream which uses fixed size integers (int32_t) instead of plain int whenever it is used to represent a size of an object.
This patch will allow to build the Paho package for platforms where an integer has a width of less than 32 bit.
This patch is also provided as a PR to the upstream version of Paho (https://github.com/eclipse/paho.mqtt.embedded-c/pull/238) but unfortunately the upstream seems to be unmaintained.
### Testing procedure
Build for a 8 or 16 bit platform that has enough memory for the example, e.g., https://api.riot-os.org/group__boards__atxmega-a1u-xpro.html:
BUILD_IN_DOCKER=1 BOARD=atxmega-a1u-xpro make clean all
Without this PR this build will fail, with the patches applied it will succeed.
### Issues/PRs references
This PR makes #18997 obsolete and thus reverts the change.
19034: boards/nucleo-l496zg: doc improvement r=maribu a=krzysztof-cabaj
### Contribution description
This PR adds to nucleo-l496zg documentation MCU table - similar to those, for example for, Nucleo F103RB, F302R8 or F446RE.
### Testing procedure
```
make doc
xdg-open doc/doxygen/html/group__boards__nucleo-l496zg.html
```
### Issues/PRs references
None
Co-authored-by: Erik Ekman <eekman@google.com>
Co-authored-by: Oleg Hahm <oleg@hobbykeller.org>
Co-authored-by: krzysztof-cabaj <kcabaj@gmail.com>
An alternative device configuration descriptor is required if multiple protocols, e.g. CDC ECM and RNDIS, should be used with same device interface. This commit is a prerequisite for the support of tinyusb netdev driver.
The commit includes the following changes:
- Remaining CONFIG_* symbols are moved to tinyusb_descriptors.h to be visible in all source files.
- Debug output is added to some descriptor callbacks.
- The conditional definitions of CFG_* symbols are changed to unconditional definitions to ensure that Kconfig CONFIG_* symbols are always used.
If the STM32 MCU does not have an internal D+ pullup and there is no dedicated GPIO on the board to simulate a USB disconnect, the D+ GPIO
has to be temporarily configured as an output and pushed down to simulate a disconnect/connect cycle to allow the host to recognize the device. This is done correctly in `cpu/stm32/periph/usbdev_fs.c` but not in tinyUSB STM32 hardware driver. That is, pressing the RESET button doesn't reset the USB connection.
fixup! pkg/tinyusb: fix reset for STM32 boards without internal D+ pullup
lwIP has already used its own log level when deciding what to print.
If we reach the LWIP_PLATFORM_DIAG message no further filtering should
happen, so set the log level to match the macro used.
This fixes the missing IP addresses from ifconfig. Before:
> ifconfig
Iface ET0 HWaddr: 24:0a:c4:e6:0e:9f Link: up State: up
Link type: wired
inet addr: mask: gw:
inet6 addr: scope: link state: valid preferred
inet6 addr: scope: global state: valid preferred
Iface ET1 HWaddr: 24:0a:c4:e6:0e:9c Link: up State: up
Link type: wireless
inet addr: mask: gw:
inet6 addr: scope: link state: valid preferred
inet6 addr: scope: global state: valid preferred
>
With this change:
> ifconfig
Iface ET0 HWaddr: 24:0a:c4:e6:0e:9f Link: up State: up
Link type: wired
inet addr: 10.4.4.81 mask: 255.255.254.0 gw: 10.4.4.1
inet6 addr: fe80:0:0:0:260a:c4ff:fee6:e9f scope: link state: valid preferred
inet6 addr: 2001:db8:0:0:260a:c4ff:fee6:e9f scope: global state: valid preferred
Iface ET1 HWaddr: 24:0a:c4:e6:0e:9c Link: up State: up
Link type: wireless
inet addr: 10.4.4.86 mask: 255.255.254.0 gw: 10.4.4.1
inet6 addr: fe80:0:0:0:260a:c4ff:fee6:e9c scope: link state: valid preferred
inet6 addr: 2001:db8:0:0:260a:c4ff:fee6:e9c scope: global state: valid preferred
>
The commit 98478e02fe removed the setting of the CFG_TUD_MAX_SPEED define to OPT_MODE_DEFAULT_SPEED. This setting is usually not required since CFG_TUD_MAX_SPEED is determined from CFG_TUSB_RHPORT{0,1}_MODE. However, this does not work for STM32F429I-DISC1 where the HS port is used via the internal FS-PHY. Therefore the default speed setting is added again.
With PR #18835, the automatic generation of descriptors for the most common device classes and their handling was introduced. The update of the documentation was forgotten.
This fixes compilation with GCC >= 12.x, which is unhappy about the use
after free:
/home/maribu/Repos/software/RIOT/build/pkg/ccn-lite/src/ccnl-core/src/ccnl-relay.c: In function 'ccnl_fib_rem_entry':
/home/maribu/Repos/software/RIOT/build/pkg/ccn-lite/src/ccnl-core/src/ccnl-relay.c:916:16: error: pointer 'fwd' used after 'free' [-Werror=use-after-free]
916 | if (fwd->face) {
| ~~~^~~~~~
In file included from /home/maribu/Repos/software/RIOT/build/pkg/ccn-lite/src/ccnl-core/src/ccnl-relay.c:33:
/home/maribu/Repos/software/RIOT/build/pkg/ccn-lite/src/ccnl-core/../ccnl-riot/include/ccn-lite-riot.h:52:41: note: call to 'free' here
52 | #define ccnl_free(p) free(p)
| ^~~~~~~
/home/maribu/Repos/software/RIOT/build/pkg/ccn-lite/src/ccnl-core/src/ccnl-relay.c:910:13: note: in expansion of macro 'ccnl_free'
910 | ccnl_free(fwd);
| ^~~~~~~~~
/home/maribu/Repos/software/RIOT/build/pkg/ccn-lite/src/ccnl-core/src/ccnl-relay.c: In function 'ccnl_fib_rem_entry':
/home/maribu/Repos/software/RIOT/build/pkg/ccn-lite/src/ccnl-core/src/ccnl-relay.c:916:16: error: pointer 'fwd' used after 'free' [-Werror=use-after-free]
916 | if (fwd->face) {
| ~~~^~~~~~
In file included from /home/maribu/Repos/software/RIOT/build/pkg/ccn-lite/src/ccnl-core/src/ccnl-relay.c:33:
/home/maribu/Repos/software/RIOT/build/pkg/ccn-lite/src/ccnl-riot/include/ccn-lite-riot.h:52:41: note: call to free' here
52 | #define ccnl_free(p) free(p)
| ^~~~~~~
/home/maribu/Repos/software/RIOT/build/pkg/ccn-lite/src/ccnl-core/src/ccnl-relay.c:910:13: note: in expansion of macro 'ccnl_free'
910 | ccnl_free(fwd);
| ^~~~~~~~~
This fixes a signature mismatch between forward declaration and
implementation, which in turn fixes the following error during
compilation:
/home/maribu/Repos/software/RIOT/build/pkg/wolfssl/wolfcrypt/src/ge_low_mem.c:179:30: error: argument 1 of type 'unsigned char[64]' with mismatched bound [-Werror=array-parameter=]
179 | void sc_reduce(unsigned char x[64])
| ~~~~~~~~~~~~~~^~~~~
In file included from /home/maribu/Repos/software/RIOT/build/pkg/wolfssl/wolfcrypt/src/ge_low_mem.c:34:
/home/maribu/Repos/software/RIOT/build/pkg/wolfssl/wolfssl/wolfcrypt/ge_operations.h:81:36: note: previously declared as 'byte *' {aka 'unsigned char *'}
81 | WOLFSSL_LOCAL void sc_reduce(byte* s);
| ~~~~~~^
There are STM32 families where all models use only the Synopsys DWC2 USB OTG core while others completely use only the USB Device FS core. For these families then either the driver `drivers/usbdev_synopsys_dwc2` or the driver `cpu/stm32/periph/usbdev` is used depending on the respective family. However, the STM32 families F1 and L4 use both cores. The correct driver must therefore be selected depending on the CPU line or CPU model.
This allows including C headers from C++. It sadly reduced the
diagnostics on C++ code as well, were there warning may make sense as
unintended side effect. We may be able to drop that later on, when more
C APIs are properly wrapped in native C++ APIs, so that C headers do no
longer need to be compatible with C++ compilers.
`CFG_TUD_MAX_SPEED` definition isn't required since tinyUSB derives it from `TUD_RHPORT_MODE` if not defined or uses the maximum speed the MCU supports by default.
The definition in `pkg/esp32_sdk/Makefile.include` was evaluated by
`make` after the include paths were already set, resulting in
`ESP32_SDK_DIR` being empty in
INCLUDES += -I$(ESP32_SDK_DIR)/components
[...]
This in turn resulted in
cc1: error: /components: No such file or directory [-Werror=missing-include-dirs]
[...]
The cpus for the sam*xpro series have some differences in make and Kconfig
Kconfig seems to be more verbose and make assumes samr34-xpro just uses saml21
