Failing to provide any of the required features can provide a message
such as:
There are unsatisfied feature requirements: periph_uart|periph_lpuart
This can be confusing and may hide the actual. E.g. above message
was generated when using SPI on the `msb-430` and `stdio_uart`. However,
the MSB-430 board *does* provide `periph_uart`, so this looks like a bug
in the feature resolution. This changes the failure mode of
`FEATURES_REQUIRED_ANY` to just pick the first of the alternatives
given if none of the alternative is usable, which gives in the example
the following message instead:
The following features may conflict: periph_spi periph_uart
Rationale: Both SPI and UART are provided by the same USART
peripheral
The output is less surprising and can provide non-obvious reasons
why `FEATURES_REQUIRED_ANY` failed to pick a feature. The downside is
that the alternatives are no longer visible. However, that output
likely was so confusing this might be for the best.
Co-authored-by: mguetschow <mikolai.guetschow@tu-dresden.de>
Before we disabled the warning about RWX segments only for picolibc,
but this issue is popping up on more and more toolchains (looking
at MSP430 and RISC-V). Other than on `native`/`native64`, there is no
MMU to enforce whatever permissions the segments contain anyway.
(And writing to ROM with regular store instructions will not be possible
even without the need for an MMU.)
So let's just globally disable this warning, unless building for
`native` and `native64`.
The legacy `riscv-none-embed` target triple is incorrect and the
toolchain using it has long been obsolete. With our CI no longer
using the obsolete toolchain, there is no need to handle that one
anymore.
The CI now uses `riscv-none-elf` over the previous (and technically
incorrect) `riscv-none-embed`. In addition, we no longer probe for
host toolchains with the incorrect target triple, as the source
providing it has long declared the toolchain with the incorrect
triple as obsolete.
This adds mspdebug as package, similar to EDBG, so that the
programmer/debugger is build from source.
This has the advantage that we can indeed provide patches of our own.
The first patch fixes a bug with the CPU detection of `mspdebug` in
combination with the Olimex MSP430-JTAG-TINY-V2. The second adds the
`--expect-id <CPU_NAME>` argument.
The RIOT integration is updated to directly make use of the
`--expect-id` parameter. No more spending time debugging why firmware
the firmware for the `olimex-msp430-h2618` doesn't run when flashed on
the `olimex-msp430h1611` hardware :D
Adds a separate board for native64 instead of the `NATIVE_64BIT` workaround.
The files in `boards/native64` are more or less dummy files and just include
the `boards/native` logic (similar to `openlabs-kw41z-mini-256kib`).
The main logic for native is in `makefiles/arch/native.inc.mk`, `cpu/native`
and `boards/native`.
The remaining changes concern the build system, and change native board checks
to native CPU checks to cover both boards.
This target allows one to check if a test-input-hash is there and if it differs from
a new one, adding basic support to skip tests if nothing needs to be run.
RIOT_TEST_HASH_DIR represents the dir to generate the test-input-hash.sha1 file for
checking if a test has changed, uses BINDIR by default.
Since it defaults to BINDIR it should have no effect on running systems.
This allows a bit more fine grain control, especially when using
the compile_and_test_for_board.py script.
The checks would print their prominently colored warnings and confuse
users, and the comments are more geared to those editing the Makefiles
than to those watching which commands get executed.
Back when specific control of the Rust version used with RIOT was
needed, CARGO_CHANNEL was added to explicitly set the Rust version with
consideration for CI special cases.
Rust's mechansims of selecting a toolchain can be used instead now.
When `stdio_cdc_acm` is used, prefer selecting the USB devices with
vendor `RIOT-os.org` and model `$(BOARD)` and only fall back
to `$(TTY_BOARD_FILTER)` if no such TTY was found.
This makes it possible to add a TTY board filter matching only an
integrated USB to UART bridge, but still do the right thing when
the user explicitly uses `stdio_cdc_acm` instead of the default
`stdio_uart`.
Allow setting `OPENOCD_TRANSPORT` to `default` for when a transport to
not explicitly set the transport. This is useful when the target or
interface script already specify the transport.
If external boards defined in one of the EXTERNAL_BOARD_DIRS folders
pulls in a header file external to the RIOT tree and added to the build
via the INCLUDES macro, the build will fail to find the header.
This patch adds the INCLUDES macro to the bootloader build step so that
the headers can be found.
Allow accessing supported timer frequencies with a dedicated API.
This API needs to be implemented per platform and is available with
the feature periph_timer_query_freqs.
This fixes issues with `make compile-commands`, as this by default
generates clangd/LLVM compatible flags. Without `TARGET_ARCH_LLVM`
exported, this will fall back to `TARGET_ARCH`, which is different
for LLVM and GCC.
18547: sys: PSA Crypto API implementation r=MrKevinWeiss a=Einhornhool
### Contribution description
This adds an implementation of the ARM [PSA Crypto API](https://armmbed.github.io/mbed-crypto/html/index.html) specification to RIOT.
It is a cryptographic API that supports software and hardware backends as well as the use of multiple secure elements, which can be configured with Kconfig.
It integrates indirect, identifier based key management to support persistent storage of key material in local memory and devices with protected key storage.
A description of the implementation design and an evaluation of the processing time and memory overhead in RIOT has been published here: [Usable Security for an IoT OS: Integrating the Zoo of Embedded Crypto Components Below a Common API](https://arxiv.org/abs/2208.09281)
#### Implementation status
So far this implementation supports the following operations:
- Volatile key storage
- AES in CBC mode
- Hashes (MD5, SHA1, SHA224, SHA256)
- HMAC SHA256
- ECDSA with NIST P192 and P256 curves
The following backends are supported so far:
- RIOT Cipher Module
- RIOT Hash Module
- Micro ECC library package
- Cryptocell 310 hardware accelerator on the Nordic NRF52840dk
- Microchip ATECC608A secure element
Other operations and backends as well as persistent key storage can and will be implemented by me and anyone who wants to contribute in the future.
### Testing procedure
So far there is a show case application in `examples/psa_crypto` to demonstrate the usage and configuration of different backends of the API (refer to the application README for more information).
Co-authored-by: Lena Boeckmann <lena.boeckmann@haw-hamburg.de>
19885: drivers/stmpe811: changes for interrupt-driven touch handling and gesture recognition r=aabadie a=gschorcht
### Contribution description
This PR contains changes needed for the purely interrupt-driven handling of the touch position as `touch_dev` device, which is a prerequisite for the realization of gesture recognition. (PR #19884).
The interrupt-driven approach of `touch_dev` devices (PR #19882) and the gesture recognition (PR #19884) need continuous reporting of the touch position as long as there is at least one touch. Since the driver so far only uses the _Touch Detect_ interrupt, only the position at the beginning of a touch is available. All further positions must be polled.
Therefore, the changes in this PR additionally enable the _FIFO Threshold_ interrupt when the `touch_dev` module is enabled. However, since the _Touch Detect_ interrupt does not work reliably when the _FIFO Threshold_ interrupt is enabled and the FIFO Threshold is 1, the FIFO Threshold is set to 2 by default when the `touch_dev` module is enabled.
Furthermore, the FIFO queue has to be reset after reading one touch position. Otherwise new touch positions are processed with a delay if the rate of calling the function to read the FIFO is slower than the rate at which the FIFO is filled. The reason for this is that with each call of this function only the oldest touch position is read value by value from the FIFO. Gestures can't be implemented with such a behavior.
### Testing procedure
1. `tests/drivers/stmpe811` should work as before (only a single position is shown):
```
BOARD=stm32f429i-disco make -j8 -C tests/drivers/stmpe811 flash
```
```
main(): This is RIOT! (Version: 2023.10-devel-120-g848d1-
drivers/stmpe811_touch_dev_gestures)
STMPE811 test application
+------------Initializing------------+
Initialization successful
Pressed!
X: 135, Y:131
Released!
```
2. `tests/drivers/stmpe811` should work on top of PR #19882 with continuous outputs of touch positions:
```
BOARD=stm32f429i-disco make -j8 -C tests/drivers/touch_dev flash
```
```
main(): This is RIOT! (Version: 2023.10-devel-121-g38d3db-drivers/stmpe811_touch_dev_gestures)
Event: pressed!
X: 131, Y:145
X: 133, Y:141
X: 135, Y:138
X: 138, Y:133
X: 141, Y:128
X: 146, Y:122
X: 151, Y:117
Event: released!
```
3. `tests/driver/touch_dev_gestures` of PR #19884 should work on top of this PR:
```
BOARD=stm32f429i-disco make -j8 -C tests/drivers/touch_dev_gestures flash
```
```
main(): This is RIOT! (Version: 2023.10-devel-128-g05f690-drivers/touch_dev_gestures_work)
Swipe right
Swipe left
Swipe down
Swipe up
Single Tap X: 246, Y:148
Single Tap X: 256, Y:139
Double Tap X: 247, Y:136
Pressed X: 246, Y:131
Moving X: 248, Y:132
Moving X: 250, Y:133
Moving X: 258, Y:135
Moving X: 270, Y:136
Moving X: 285, Y:132
Moving X: 300, Y:126
Moving X: 309, Y:122
Moving X: 310, Y:119
Released X: 310, Y:119
```
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19876: sys/net/ipv4/addr: fix typos r=benpicco a=Enoch247
### Contribution description
This patch fixes some typos in the doxygen doc.
### Testing procedure
Nothing to test. No change to code.
### Issues/PRs references
- None known
19878: makefiles/usb_board_reset.mk: declare term-delay target with test target r=benpicco a=aabadie
19888: boards/sltb009a: complete and fix documentation r=benpicco a=gschorcht
### Contribution description
This PR completes and fixes the documentation which was still in the state as generated automatically by `efm2riot`.
The PR also includes a fix of the configuration of the second UART device that was find out while completing the documentation.
### Testing procedure
Green CI
### Issues/PRs references
Co-authored-by: Joshua DeWeese <jdeweese@primecontrols.com>
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
There are new pseudomodules for this driver:
- atwinc15x0_static_connect: Should behave as before, by trying to connect to an AP
by specified WIFI_SSIS and WIFI_PASS
- atwinc15x0_dynamic_connect: takes connection request via NETOPT_CONNECT
and provides the connection result via callback
- atwinc15x0_dynamic_scan: takes network scan requests via NETOPT_SCAN
and provides the scan result as a sorted list via callback
Designated initializers make the code much more readable and are part
of the C standard since C99. C++ with C++20 finally caught up.
Until we switch to that C++ version, let's disable the annoying
warning rather than reducing the code quality for the sake of
strict C++ compatibility of our headers.
With GCC, the C++ compiler knows all builtin C include paths *and*
all builtin C++ include paths, but the C compiler only knows the
C include paths. Hence, let's use the C++ compiler to collect
the include paths.
19764: drivers/shield_w5100: add module for the W5100 Ethernet Shield r=benpicco a=maribu
### Contribution description
This module provides no more than the correct configuration parameters for the `w5100` driver using the Arduino I/O mapping features. But by doing so, it will work out of the box with every mechanically and electrically compatible board for which the Arduino I/O mapping features are implemented.
19781: cpu/nrf{53,9160}: add pwm support r=benpicco a=dylad
### Contribution description
This PR moves the nRF52 PWM driver to `cpu/nrf5x_common` to allow nRF9160 and nRF53 to use this driver.
IP is identical on these families.
I didn't test on nRF9160DK and I didn't test if there is any regression on nRF52-based board as I don't have any so tests are welcome !
However it works fine on nRF53-based board.
### Testing procedure
Flash the `tests/periph/pwm` test application on `nrf5340dk` or `nrf9160dk`.
You can then use the `osci` command to make the onboard LEDs "breath".
You can also attach an oscilloscope and/or logic analyzer to watch the signal.
### Issues/PRs references
~~Based on #19769~~
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Co-authored-by: dylad <dylan.laduranty@mesotic.com>
This module provides no more than the correct configuration parameters
for the `w5100` driver using the Arduino I/O mapping features. But
by doing so, it will work out of the box with every mechanically and
electrically compatible board for which the Arduino I/O mapping
features are implemented.
19791: makefiles/arch/riscv.inc.mk: speed up toolchain detection r=benpicco a=maribu
### Contribution description
- Use a sane (a.k.a. simply expanded) variable for the `$(TARGET_ARCH)` instead of an insane (a.k.a. recursive expended) variable - The toolchain detection will now happen only once, rather than each and every time `$(TARGET_ARCH)` is referenced
- Use a single call to `which` rather than one per possible target triple
Fixes https://github.com/RIOT-OS/RIOT/issues/19788
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
19733: cpu/msp430: reorganize code r=maribu a=maribu
### Contribution description
RIOT supports two distinct families of the MSP430: The [MSP430 x1xx] MCU family and the [MSP430 F2xx/G2xx] MCU family. For both incompatible MCU families the code was located in the msp430fxyz folder, resulting in case of the UART driver in particularly bizarre code looking roughly like this:
```C
#ifndef UART_USE_USCI
/* implementation of x1xx peripheral ... */
#else
/* implementation of F2xx/G2xx peripheral ... */
#endif
/* zero shared code between both variants */
```
This moves peripheral drivers shared between the two families to msp430_common and splits the SPI and UART driver into two MCU families.
In addition, it cleans up the `msp430_regs.h` by dropping most of it and using the macros and symbols provided by the vendor header files. There is little reason for us to maintain constants when TI is already doing that.
[MSP430 x1xx]: https://www.ti.com/lit/ug/slau049f/slau049f.pdf
[MSP430 F2xx/G2xx]: https://www.ti.com/lit/ug/slau144k/slau144k.pdf
19747: gnrc/ipv6/nib: reset rs_sent counter also for not-6LN interfaces r=maribu a=fabian18
19769: cpu/nrf53: add initial support with nRF5340DK-APP board r=maribu a=dylad
### Contribution description
This PR adds support for nRF5340 MCU and its associated Nordic development board, nRF5340DK.
This MCU provides a dual Cortex-M33, one application core running at up to 128MHz, and one network core running at up to 64MHz.
Peripherals are inherited from others Nordic MCUs families so it shouldn't be hard to add more of them in followup PRs.
For now, only the minimal set of peripherals is supported:
- GPIO / GPIO_IRQ
- UART
- TIMER
### Testing procedure
Build the usual test application for the supported peripherals and flash the board.
nRF5340DK provides two serial ports on its embedded debugger. RIOT's shell should be available on the first one (/dev/ttyACM0)
### Issues/PRs references
#18576#19267
19782: cpu/msp430: fix for ti's msp430-gcc-opensource package ld version r=maribu a=hugueslarrive
### Contribution description
My msp430 toolchain (https://www.ti.com/tool/MSP430-GCC-OPENSOURCE) was broken by #19484:
```
hugues@p700:~/github/cpu_msp430_common/RIOT$ BOARD=msb-430 make -j64 -C examples/hello-world
make : on entre dans le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
Building application "hello-world" for "msb-430" with MCU "msp430fxyz".
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core/lib
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers/periph_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/auto_init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/div
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/libc
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/malloc_thread_safe
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/newlib_syscalls_default
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz/periph
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/preprocessor
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/stdio_uart
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common/periph
/opt/ti/msp430-gcc/bin/../lib/gcc/msp430-elf/9.3.1/../../../../msp430-elf/bin/ld: .rodata not found for insert
collect2: error: ld returned 1 exit status
make: *** [/home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world/../../Makefile.include:761 : /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world/bin/msb-430/hello-world.elf] Erreur 1
make : on quitte le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
hugues@p700:~/github/cpu_msp430_common/RIOT$ /opt/ti/msp430-gcc/msp430-elf/bin/ld --version
GNU ld (Mitto Systems Limited - msp430-gcc 9.3.1.11) 2.34
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
hugues@p700:~/github/cpu_msp430_common/RIOT$ /opt/ti/msp430-gcc/msp430-elf/bin/ld --version | grep -Eo '[0-9]\.[0-9]+'
9.3
1.11
2.34
hugues@p700:~/github/cpu_msp430_common/RIOT$ /opt/ti/msp430-gcc/msp430-elf/bin/ld --version | grep -Eo '[0-9]\.[0-9]+$'
2.34
```
### Testing procedure
```
hugues@p700:~/github/cpu_msp430_common/RIOT$ BOARD=msb-430 make -j64 -C examples/hello-world
make : on entre dans le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
Building application "hello-world" for "msb-430" with MCU "msp430fxyz".
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core/lib
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers/periph_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/auto_init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/div
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/libc
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/malloc_thread_safe
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/newlib_syscalls_default
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/preprocessor
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/stdio_uart
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz/periph
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common/periph
text data bss dec hex filename
8612 722 866 10200 27d8 /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world/bin/msb-430/hello-world.elf
make : on quitte le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
```
### Issues/PRs references
Introduced by #19484, highlighted in #16727.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
Co-authored-by: Fabian Hüßler <fabian.huessler@ml-pa.com>
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Co-authored-by: Hugues Larrive <hlarrive@pm.me>
