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
