When it is difficult to navigate a function, it is overdue to split
it up :D
Also, no need to test for feature `gpio_ll_irq` in `test_irq()` *and*
before calling `test_irq()`.
- Move common code for USART (shared SPI / UART peripheral) to its
own file and allow sharing the USART peripheral to provide both
UART and SPI in round-robin fashion.
- Configure both UART and SPI bus via a `struct` in the board's
`periph_conf.h`
- this allows allocating the two UARTs as needed by the use case
- since both USARTs signals have a fixed connection to a single
GPIO, most configuration is moved to the CPU
- the board now only needs to decide which bus is provided by
which USART
Note: Sharing an USART used as UART requires cooperation from the app:
- If the UART is used in TX-only mode (no RX callback), the driver
will release the USART while not sending
- If the UART is used to also receive, the application needs to power
the UART down while not expecting something to send. An
`spi_acquire()` will be blocked while the UART is powered up.
The documentation on the state `GPIO_DISCONNECT` was a bit vague. The
API doc said it should disconnect the GPIO from all peripherals, the
test also tested them for being electrically disconnected.
The documentation in both the test and the API is extended to point out
that a GPIO indeed SHOULD be in high impedance state, but that user
MUST NOT expect that this requested is honored by every implementation
and for every GPIO pin.
In the test it is also pointed out that failing the test for a GPIO
in the `GPIO_DISCONNECT` state being electrically disconnected is for
some pins expected, and that the test should be just run again with
different GPIOs. The test intentionally tests for a feature not provided
by every GPIO pin rather than warning on a failure: The effort to just
flash and run the test again with different GPIOs is relatively low, but
it does confirm correct behavior of the API.
When using level triggered IRQs, a new IRQ flag may already have been
set while the IRQ callback is executed. Hence, we cannot just toggle
the output, but rather should drive it low/high for a level trigger on
high/low.
Also test `gpio_ll_query_conf()` for the disconnected state as well.
The default pin config is only a place holder anyway. But if it is
invalid at least on AVR most of the firmware is considered unreachable.
This updates the default GPIO config to something that should look
plausible to the compiler for all MCUs supporting GPIO LL, so that
ROM and RAM size in the CI start making sense.
Printing the newline after the state was printed is not optional.
This also moves the call to `gpio_ll_print_conf()` and `puts("")` to
a static function to safe enough ROM so that this still can be flashed
on `nucleo-l011k4`.
This commit optimizes the `gpio_conf_t` type in the following
regards:
- The "base" `gpio_conf_t` is stripped from members that only some
platforms support, e.g. drive strength, slew rate, and disabling of
the Schmitt Trigger are no longer universally available but
platform-specific extensions
- The `gpio_conf_t` is now crammed into a bit-field that is 8 bit or
16 bit wide. This allows for storing lots of them e.g. in
`driver_foo_params_t` or `uart_conf_t` etc.
- A `union` of the `struct` with bit-field members and a `bits` is used
to allow accessing all bits in a simple C statement and to ensure
alignment for efficient handling of the type
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Also the LF is display inside the [...].
Now it is more obvious what characters came in on the RX port of the UART.
Here is an example:
2024-01-20 20:57:41,368 # send 1 ati
2024-01-20 20:57:41,368 # UART_DEV(1) TX: ati
> 2024-01-20 20:57:41,393 # Success: UART_DEV(1) RX: [ati\r\r\n]
2024-01-20 20:57:41,398 # Success: UART_DEV(1) RX: [SARA-N310-00X-00\r\n]
2024-01-20 20:57:41,399 # Success: UART_DEV(1) RX: [\r\n]
2024-01-20 20:57:41,399 # Success: UART_DEV(1) RX: [OK\r\n]
This application uses `soft_uart` to bit-bang the name of a number of
configured GPIO pins via said pins at 9600 Bd. This way attaching an
USB UART bridge to one pin at a time easily reveals which MCU GPIO
pin a given pin on a board corresponds to. This is useful when no
schematic and no silkscreen labeling is available, or when the
information is misleading or outright incorrect (looking at the
E180-ZG120B-TB).
Reverts the type changes for the array size variables, as `size_t` is needed
in the function calls `fib_get_next_hop` and `fib_get_destination_set`.
Fixes 475a55136a
The CC2538-CC2592-DK is one of the few readily available and
affordable boards featuring a legacy CC2538 MCU. This should make
maintaining RIOT support for that legacy MCU more affordable :-)
- Added helper function to avoid 'format-truncation' warning
- Changed all `size_t` types to `unsigned`
- Changed function names from `_FIB_` to `_fib_`
- the timeout computation for the spurious IRQ test confused numerator
and denominator in a fraction
- the timeout offset between timer channels was hardcoded to 5000 from
when the timer was only tested with 1 MHz as frequency
- This resulted in slooooow test runs when running at slow
frequencies
- fix overflow handling in the spinning wait
- likely this would never overflow anyway assuming that
`timer_init()` resets the counter value, but let's not rely on
this and just fix the bug for good
If the feature periph_timer_query_freqs is provided, use the
corresponding function to iterate over all supported frequencies to
increase test coverage.
This test sporadically failed on multiple machines compiled with both
GNU and LLVM toolchains. To not waste more CI time by sporadically
failing unrelated CI runs, let's disable the test for now.
- Detect when the same timer is used by `ztimer` (pulled in as
dependency for a peripheral driver, e.g. `periph_adc` on STM32F3) and
the test application
- Try to provide a better default (e.g. `TIMER_DEV(1)` when
`ztimer_periph_timer` is in use, `TIMER_DEV(0)` otherwise)
The R-2R resistor ladder dac --> ADC test was disabled due to a bug in
the v0.1 version of the shield. Since this has been fixed in v0.2 and
v0.3 of the shield, it can be re-enabled.
The comment regarding the high accuracy of the resistor is dropped, as
v0.3 has been ordered with cost efficient resistors rather than with
accurate ones. As a result, the tolerance for error has been increased
to 10%. This quite a bit more lax than I have hoped for, but false
positives would be something to avoid.
- fix a copy-paste error (`TIMER_FREQ_UART_TEST` was used in the SPI
test, but that should be `TIMER_FREQ_SPI_TEST`)
- use 400 kHz as slow SPI frequency, as faster STM32 MCUs just cannot
divide the APB clock down to 100 kHz
- when detailed output is enabled, print the SPI clock in addition to
the SPI mode to ease figuring out what went wrong
- only have one `FAILURE` message for a too fast byte transfer per
check, rather than per transmitted byte, to reduce the noise
- work around a bug of `periph_timer` on STM32 by reducing the clock
speed of the timer for the SPI test
The test should execute only with `make test-with-config` and not with
`make test`, as boards without the shield cannot pass the test.
For some reason I accidentally added both variants, which makes no
sense. This drops the `make test` variant.
Finally, the `README.md` is updated to refer to `make test-with-config`
instead of `make test`.
This test application makes use of the RIOT Peripheral Selftest Shield,
which connects e.g. PWM to ADC or SPI MOSI to SPI MISO, UART TXD to RXD,
etc. This provides quick and fully automated self testing capabilities.
Please note that the simplicity and ease of use of the hardware comes
with a prices: There are whole classes of issues that cannot be detected
automatically. This test cannot replace other testing approaches
(such as manual testing or PHiLIP on the HiL), but only complement them.
20022: pkg/lwip: add support for slipdev r=benpicco a=benpicco
20025: tests/drivers/at: fix device table overflow r=benpicco a=krzysztof-cabaj
### Contribution description
This PR fix device table overflow in `tests/driver/at`, which could lead to device crash.
### Testing procedure
PR was tested on two nucleo boards with 2 and 3 UARTs (nucleo-l476rg and nucleo-l496zg).
Flash `tests/driver/at` with and without this PR.
Output with this PR:
```
> main(): This is RIOT! (Version: 2022.07-devel-5083-g2b9e8-tests-drivers-at)
AT command test app
> init 5 9600
Wrong UART device number - should by in range 0-2.
>
```
Output without this PR:
```
> main(): This is RIOT! (Version: 2022.07-devel-5083-g2b9e8)
AT command test app
> init 5 9600
8001afd
*** RIOT kernel panic:
FAILED ASSERTION.
*** halted.
Context before hardfault:
r0: 0x0000000a
r1: 0x00000000
. . .
```
### Issues/PRs references
None
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: krzysztof-cabaj <kcabaj@gmail.com>
- add `static` qualifiers where sensible
- drop `volatile` qualifier that was incorrectly used
- add a comment on use of shared memory for inter-thread communication
19990: sys/psa_crypto: allow repeated initialization r=benpicco a=mguetschow
### Contribution description
- simple unit test which calls `psa_crypto_init()` twice
- fix to no re-initialize key slots (which left them in a broken state)
### Testing procedure
- `make -C tests/sys/psa_crypto all test` succeeds
- `git checkout HEAD~1 && make -C tests/sys/psa_crypto all test` fails
Co-authored-by: Mikolai Gütschow <mikolai.guetschow@tu-dresden.de>
20011: tests/unittests: add a unit test for ztimer r=benpicco a=maribu
### Contribution description
This adds test coverage for removing ztimers with focus on ensuring that offsets are correctly updated on subsequent timers (e.g. not having timers fire too early).
### Testing procedure
Run the unit tests (will be done by the CI as well). Maybe also introduce a random bug in `ztimer_remove()` and check if this is indeed caught by the unit tests.
### Issues/PRs references
Prompted by https://github.com/RIOT-OS/RIOT/pull/18977#issuecomment-1764258356
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
This adds test coverage for removing ztimers with focus on ensuring that
offsets are correctly updated on subsequent timers (e.g. not having
timers fire too early).
19465: drivers/mtd: use XFA for pointers to defined MTDs r=benpicco a=gschorcht
### Contribution description
This PR provides the support to hold pointers to defined MTDs within a XFA. The XFA allows
- to access MTDs of different types (`mtd_flashpage`, `mtd_sdcard`, `mtd_emulated`, ...) by an index
- to determine the number of MTDs defined in the system.
### Testing procedure
To be defined once PR #19443 is merged because emulated MTDs will allow to test this PR on arbitrary boards.
### Porting Guide
For external boards:
- remove the `MTD_NUMOF` definition from `board.h`
- add `MTD_XFA_ADD(<mtd_dev>, <idx>);` to the definition of `<mtd_dev>`.
- `MTD_0`, `MTD_1`, … defines are no longer needed.
### Issues/PRs references
Related to PR #19443
19981: Fletcher32: Add incremental API r=benpicco a=bergzand
### Contribution description
This PR extends the current fletcher32 checksum with an incremental API mode. This way the bytes to be checksummed can be supplied via multiple successive calls and do not have to be provided in a single consecutive buffer.
I've also rephrased the warning with the original function a bit as that function uses an `unaligned_get_u16` to access the data. The data thus does not require alignment, but the length does need to be supplied as number of 16 bit words.
### Testing procedure
The test has been extended
### Issues/PRs references
None
19995: sys/psa_crypto: Fix macro for public key max size and SE example r=benpicco a=Einhornhool
### Contribution description
#### 1. Wrong public key size when using secure elements, introduced by #19954
Fixed conditions for key size macros in `crypto_sizes.h`.
#### 2. EdDSA and ECDSA examples fail when using a secure element because of unsopported changes introduced by #19954
Updated `example/psa_crypto` to use only supported functions for secure elements.
### Testing procedure
Build `example/psa_crypto` for secure elements and run application
Output on master:
```
2023-10-19 14:33:24,372 # main(): This is RIOT! (Version: 2019.07-devel-22378-gb6772)
2023-10-19 14:33:24,372 # HMAC SHA256 took 56393 us
2023-10-19 14:33:24,372 # Cipher AES 128 took 68826 us
2023-10-19 14:33:24,372 # *** RIOT kernel panic:
2023-10-19 14:33:24,373 # HARD FAULT HANDLER
2023-10-19 14:33:24,373 #
2023-10-19 14:33:24,373 # *** rebooting...
```
Output with fixes:
```
2023-10-19 13:35:24,715 # main(): This is RIOT! (Version: 2019.07-devel-22384-g8ef66-dev/psa-crypto-fixes)
2023-10-19 13:35:24,715 # HMAC SHA256 took 56374 us
2023-10-19 13:35:24,715 # Cipher AES 128 took 68805 us
2023-10-19 13:35:24,715 # ECDSA took 281164 us
2023-10-19 13:35:24,715 # All Done
```
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Koen Zandberg <koen@bergzand.net>
Co-authored-by: Lena Boeckmann <lena.boeckmann@haw-hamburg.de>
19963: sys/event/timeout: add event_timeout_is_pending() r=benpicco a=benpicco
19971: sys/shell/gnrc_netif: Fix a few blockers for sharing ifconfig shell r=benpicco a=yarrick
19974: gnrc_ipv6_ext_frag: _completed: Add comment why list head is not checked for NULL pointer dereference r=benpicco a=miri64
19975: pkg/nanocbor: Bump to latest commit r=benpicco a=bergzand
### Contribution description
Not much to see here
Important changes:
- Add stream-like interface for encoder
- Separate functions for number of items left in arrays and maps
### Testing procedure
The usual test should still work
### Issues/PRs references
None
19976: core: Express -1 as ~0 in thread_status_t cast r=benpicco a=SimonIT
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Erik Ekman <eekman@google.com>
Co-authored-by: Martine Lenders <m.lenders@fu-berlin.de>
Co-authored-by: Koen Zandberg <koen@bergzand.net>
Co-authored-by: SimonIT <simonit.orig@gmail.com>
19943: cpu/stm32: FMC used for low-level LCD parallel interface r=maribu a=gschorcht
### Contribution description
This PR provides the implementation of the LCD low-level MCU 8080 parallel interface using the FMC peripheral.
### Testing procedure
```
BOARD=stm32f723e-disco make -C tests/drivers/st77xx flash
```
and
```
BOARD=stm32l496g-disco make -C tests/drivers/st77xx flash
```
should work on top of PR #19941. Drawing operations should be much faster.
### Issues/PRs references
Depends on PR #19941
19978: treewide: fix typos to make codespell happy r=maribu a=maribu
### Contribution description
- fixes typos in comments and docs (no generated firmware changes expected)
- fixes a typo in a string in a GUI of a utility program
- add some false positives to the ignore list
### Testing procedure
- No generated binaries (except for the GUI version of the utility program to flash the MSB-A2) should change
- The diff should not look too scary
### Issues/PRs references
None
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
19941: drivers/lcd: add MCU-driven low-level parallel interface r=benpicco a=gschorcht
### Contribution description
The PR extends the LCD driver by a low-level interface for MCU-driven implementations of the MCU 8080 16-/8-bit parallel interface, allowing the MCU to use special peripherals for the interface, such as the FMC for STM32 MCUs, which is significantly faster than the integrated GPIO-driven parallel interface implementation of the LCD driver.
### Testing procedure
~Once PR #19938 and PR #19939 are merged, a PRs for these board can be pushed that allow to test this PR.~
Use either PR #19943 or PR #19944 on top of this PR to test, e.g. with PR #19943:
```
BOARD=stm32f723e-disco make -j8 -C tests/drivers/st77xx flash
```
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19825: drivers: rename st7735 to more generic st77xx r=aabadie a=gschorcht
### Contribution description
This PR provides the following changes:
- renames the driver `st7735` to `st77xx`
- renames the test `st7735` to `st77xx`
- models controller variants as pseudomodules `st7735`, `st7789` and `st7796`
- removes the buggy initialization as a workaround to use reset defaults, see issue #19818
- adds backward compatibility header files for `ST7735_PARAM_*` symbols
- adds a test board for compilation test of backward compatibility
- updates the corresponding board definitions
The PR should solve the remaining dependency issues in KConfig we had by using `st7735` module for different controller variants. The backward compatibility header files should work for boards that still use `ST7735_PARAM_*` in their board definitions so that the board defintions at user's side use shouldn't be affected.
~To be compilable, the PR includes PR #19824.~
### Testing procedure
- Green CI
- `tests/drivers/disp_dev` and `tests/drivers/st77xx` should still work for all boards using a ST77xx display.
- The PR was already tested for these tests for:
- [x] `adafruit-pybadge`
- [x] `esp32s2-lilygo-ttgo-t8`
- [x] `esp32s3-usb-otg`
- [x] `sipeed-longan-nano`
### Issues/PRs references
Workaround for issue #19818
Preqruisite for PR #19827
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
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>
19851: boards/stm32f769i-disco: enable FMC with SDRAM support r=aabadie a=gschorcht
### Contribution description
This PR enables the FMC support on the `stm32f769i-disco` board and the on-board SDRAM MT48LC4M32B2B5-6A with 16 MByte.
The PR also includes a very small documentation fix for the `stm32f746g-disco` board (commit
f761e2d616c861e4857563bae26152bc1f1699d7) and removes double empy line in the test app `tests/periph/fmc`.
### Testing procedure
1. `tests/periph/fmc` should succeed, just compile and flash the app with
```
BOARD=stm32f769i-disco make -C tests/periph/fmc flash term
```
2. `tests/sys/malloc` should also use the SDRAM. Use
```
USEMODULE=periph_fmc_sdram CFLAGS='-DCHUNK_SIZE=131072' \
BOARD=stm32f769i-disco make -C tests/sys/malloc flash term
```
and check that the heap also uses the memory in the range from `0xc0000000` to `0xc0fffffff`.
**UPDATE:** Tested with a `stm32f769i-disco` board.
<details>
<summary>Output from <b>tests/periph/fmc</b></summary>
```
Help: Press s to start test, r to print it is ready
START
main(): This is RIOT! (Version: 2023.10-devel-88-gdcecc-boards/stm32f769i_disco_fmc)
FMC HCLK freq 216 MHz
8-bit data `@0xc0000000,` 16-bit data `@0xc0000100,` 32-bit data `@0xc0ffff00`
------------------------------------------------------------------------
C0000000 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
C0000010 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
C0000020 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
C0000030 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
C0000040 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F
C0000050 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
C0000060 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F
C0000070 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
C0000080 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F
C0000090 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F
C00000A0 A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF
C00000B0 B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF
C00000C0 C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF
C00000D0 D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF
C00000E0 E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF
C00000F0 F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF
------------------------------------------------------------------------
C0000100 00 80 01 81 02 82 03 83 04 84 05 85 06 86 07 87
C0000110 08 88 09 89 0A 8A 0B 8B 0C 8C 0D 8D 0E 8E 0F 8F
C0000120 10 90 11 91 12 92 13 93 14 94 15 95 16 96 17 97
C0000130 18 98 19 99 1A 9A 1B 9B 1C 9C 1D 9D 1E 9E 1F 9F
C0000140 20 A0 21 A1 22 A2 23 A3 24 A4 25 A5 26 A6 27 A7
C0000150 28 A8 29 A9 2A AA 2B AB 2C AC 2D AD 2E AE 2F AF
C0000160 30 B0 31 B1 32 B2 33 B3 34 B4 35 B5 36 B6 37 B7
C0000170 38 B8 39 B9 3A BA 3B BB 3C BC 3D BD 3E BE 3F BF
C0000180 40 C0 41 C1 42 C2 43 C3 44 C4 45 C5 46 C6 47 C7
C0000190 48 C8 49 C9 4A CA 4B CB 4C CC 4D CD 4E CE 4F CF
C00001A0 50 D0 51 D1 52 D2 53 D3 54 D4 55 D5 56 D6 57 D7
C00001B0 58 D8 59 D9 5A DA 5B DB 5C DC 5D DD 5E DE 5F DF
C00001C0 60 E0 61 E1 62 E2 63 E3 64 E4 65 E5 66 E6 67 E7
C00001D0 68 E8 69 E9 6A EA 6B EB 6C EC 6D ED 6E EE 6F EF
C00001E0 70 F0 71 F1 72 F2 73 F3 74 F4 75 F5 76 F6 77 F7
C00001F0 78 F8 79 F9 7A FA 7B FB 7C FC 7D FD 7E FE 7F FF
------------------------------------------------------------------------
C0FFFF00 00 40 80 C0 01 41 81 C1 02 42 82 C2 03 43 83 C3
C0FFFF10 04 44 84 C4 05 45 85 C5 06 46 86 C6 07 47 87 C7
C0FFFF20 08 48 88 C8 09 49 89 C9 0A 4A 8A CA 0B 4B 8B CB
C0FFFF30 0C 4C 8C CC 0D 4D 8D CD 0E 4E 8E CE 0F 4F 8F CF
C0FFFF40 10 50 90 D0 11 51 91 D1 12 52 92 D2 13 53 93 D3
C0FFFF50 14 54 94 D4 15 55 95 D5 16 56 96 D6 17 57 97 D7
C0FFFF60 18 58 98 D8 19 59 99 D9 1A 5A 9A DA 1B 5B 9B DB
C0FFFF70 1C 5C 9C DC 1D 5D 9D DD 1E 5E 9E DE 1F 5F 9F DF
C0FFFF80 20 60 A0 E0 21 61 A1 E1 22 62 A2 E2 23 63 A3 E3
C0FFFF90 24 64 A4 E4 25 65 A5 E5 26 66 A6 E6 27 67 A7 E7
C0FFFFA0 28 68 A8 E8 29 69 A9 E9 2A 6A AA EA 2B 6B AB EB
C0FFFFB0 2C 6C AC EC 2D 6D AD ED 2E 6E AE EE 2F 6F AF EF
C0FFFFC0 30 70 B0 F0 31 71 B1 F1 32 72 B2 F2 33 73 B3 F3
C0FFFFD0 34 74 B4 F4 35 75 B5 F5 36 76 B6 F6 37 77 B7 F7
C0FFFFE0 38 78 B8 F8 39 79 B9 F9 3A 7A BA FA 3B 7B BB FB
C0FFFFF0 3C 7C BC FC 3D 7D BD FD 3E 7E BE FE 3F 7F BF FF
------------------------------------------------------------------------
fill complete memory of 16384 kByte, a . represents a 16 kByte block
................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
ready
check memory content, a + represents one 16 kByte block of matching data
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ready
------------------------------------------------------------------------
Doing some benchmarks
write 8 bit: 233018us --- 0.013us per call --- 71999656 calls per sec
write 16 bit: 116510us --- 0.013us per call --- 71999038 calls per sec
write 32 bit: 563125us --- 0.134us per call --- 7448264 calls per sec
read 8 bit: 900066us --- 0.053us per call --- 18639984 calls per sec
read 16 bit: 1165181us --- 0.138us per call --- 7199403 calls per sec
read 32 bit: 225729us --- 0.053us per call --- 18581148 calls per sec
ready
------------------------------------------------------------------------
print first and last memory block after benchmark, should be 0xaa
C0000000 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0000010 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0000020 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0000030 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0000040 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0000050 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0000060 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0000070 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0000080 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0000090 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C00000A0 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C00000B0 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C00000C0 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C00000D0 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C00000E0 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C00000F0 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFF00 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFF10 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFF20 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFF30 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFF40 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFF50 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFF60 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFF70 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFF80 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFF90 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFFA0 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFFB0 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFFC0 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFFD0 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFFE0 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFFF0 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
------------------------------------------------------------------------
[SUCCESS]
{ "threads": [{ "name": "main", "stack_size": 1536, "stack_used": 412}]}
```
</details>
<details>
<summary>Output from <b>tests/sys/malloc</b></summary>
```
Help: Press s to start test, r to print it is ready
START
main(): This is RIOT! (Version: 2023.10-devel-88-gdcecc-boards/stm32f769i_disco_fmc)
calloc(zu, zu) = 0x10000000
CHUNK_SIZE: 131072
NUMBER_OF_TESTS: 3
Allocated 131072 Bytes at 0x200013a8, total 131072
Allocated 131072 Bytes at 0x200213c0, total 262152
Allocated 131072 Bytes at 0x200413d8, total 393232
Allocated 131072 Bytes at 0xc0000008, total 524312
Allocated 131072 Bytes at 0xc0020010, total 655392
Allocated 131072 Bytes at 0xc0040018, total 786472
Allocated 131072 Bytes at 0xc0060020, total 917552
Allocated 131072 Bytes at 0xc0080028, total 1048632
Allocated 131072 Bytes at 0xc00a0030, total 1179712
Allocated 131072 Bytes at 0xc00c0038, total 1310792
Allocated 131072 Bytes at 0xc00e0040, total 1441872
Allocated 131072 Bytes at 0xc0100048, total 1572952
Allocated 131072 Bytes at 0xc0120050, total 1704032
Allocated 131072 Bytes at 0xc0140058, total 1835112
Allocated 131072 Bytes at 0xc0160060, total 1966192
Allocated 131072 Bytes at 0xc0180068, total 2097272
Allocated 131072 Bytes at 0xc01a0070, total 2228352
Allocated 131072 Bytes at 0xc01c0078, total 2359432
Allocated 131072 Bytes at 0xc01e0080, total 2490512
Allocated 131072 Bytes at 0xc0200088, total 2621592
Allocated 131072 Bytes at 0xc0220090, total 2752672
Allocated 131072 Bytes at 0xc0240098, total 2883752
Allocated 131072 Bytes at 0xc02600a0, total 3014832
Allocated 131072 Bytes at 0xc02800a8, total 3145912
Allocated 131072 Bytes at 0xc02a00b0, total 3276992
Allocated 131072 Bytes at 0xc02c00b8, total 3408072
Allocated 131072 Bytes at 0xc02e00c0, total 3539152
Allocated 131072 Bytes at 0xc03000c8, total 3670232
Allocated 131072 Bytes at 0xc03200d0, total 3801312
Allocated 131072 Bytes at 0xc03400d8, total 3932392
Allocated 131072 Bytes at 0xc03600e0, total 4063472
Allocated 131072 Bytes at 0xc03800e8, total 4194552
Allocated 131072 Bytes at 0xc03a00f0, total 4325632
Allocated 131072 Bytes at 0xc03c00f8, total 4456712
Allocated 131072 Bytes at 0xc03e0100, total 4587792
Allocated 131072 Bytes at 0xc0400108, total 4718872
Allocated 131072 Bytes at 0xc0420110, total 4849952
Allocated 131072 Bytes at 0xc0440118, total 4981032
Allocated 131072 Bytes at 0xc0460120, total 5112112
Allocated 131072 Bytes at 0xc0480128, total 5243192
Allocated 131072 Bytes at 0xc04a0130, total 5374272
Allocated 131072 Bytes at 0xc04c0138, total 5505352
Allocated 131072 Bytes at 0xc04e0140, total 5636432
Allocated 131072 Bytes at 0xc0500148, total 5767512
Allocated 131072 Bytes at 0xc0520150, total 5898592
Allocated 131072 Bytes at 0xc0540158, total 6029672
Allocated 131072 Bytes at 0xc0560160, total 6160752
Allocated 131072 Bytes at 0xc0580168, total 6291832
Allocated 131072 Bytes at 0xc05a0170, total 6422912
Allocated 131072 Bytes at 0xc05c0178, total 6553992
Allocated 131072 Bytes at 0xc05e0180, total 6685072
Allocated 131072 Bytes at 0xc0600188, total 6816152
Allocated 131072 Bytes at 0xc0620190, total 6947232
Allocated 131072 Bytes at 0xc0640198, total 7078312
Allocated 131072 Bytes at 0xc06601a0, total 7209392
Allocated 131072 Bytes at 0xc06801a8, total 7340472
Allocated 131072 Bytes at 0xc06a01b0, total 7471552
Allocated 131072 Bytes at 0xc06c01b8, total 7602632
Allocated 131072 Bytes at 0xc06e01c0, total 7733712
Allocated 131072 Bytes at 0xc07001c8, total 7864792
Allocated 131072 Bytes at 0xc07201d0, total 7995872
Allocated 131072 Bytes at 0xc07401d8, total 8126952
Allocated 131072 Bytes at 0xc07601e0, total 8258032
Allocated 131072 Bytes at 0xc07801e8, total 8389112
Allocated 131072 Bytes at 0xc07a01f0, total 8520192
Allocated 131072 Bytes at 0xc07c01f8, total 8651272
Allocated 131072 Bytes at 0xc07e0200, total 8782352
Allocated 131072 Bytes at 0xc0800208, total 8913432
Allocated 131072 Bytes at 0xc0820210, total 9044512
Allocated 131072 Bytes at 0xc0840218, total 9175592
Allocated 131072 Bytes at 0xc0860220, total 9306672
Allocated 131072 Bytes at 0xc0880228, total 9437752
Allocated 131072 Bytes at 0xc08a0230, total 9568832
Allocated 131072 Bytes at 0xc08c0238, total 9699912
Allocated 131072 Bytes at 0xc08e0240, total 9830992
Allocated 131072 Bytes at 0xc0900248, total 9962072
Allocated 131072 Bytes at 0xc0920250, total 10093152
Allocated 131072 Bytes at 0xc0940258, total 10224232
Allocated 131072 Bytes at 0xc0960260, total 10355312
Allocated 131072 Bytes at 0xc0980268, total 10486392
Allocated 131072 Bytes at 0xc09a0270, total 10617472
Allocated 131072 Bytes at 0xc09c0278, total 10748552
Allocated 131072 Bytes at 0xc09e0280, total 10879632
Allocated 131072 Bytes at 0xc0a00288, total 11010712
Allocated 131072 Bytes at 0xc0a20290, total 11141792
Allocated 131072 Bytes at 0xc0a40298, total 11272872
Allocated 131072 Bytes at 0xc0a602a0, total 11403952
Allocated 131072 Bytes at 0xc0a802a8, total 11535032
Allocated 131072 Bytes at 0xc0aa02b0, total 11666112
Allocated 131072 Bytes at 0xc0ac02b8, total 11797192
Allocated 131072 Bytes at 0xc0ae02c0, total 11928272
Allocated 131072 Bytes at 0xc0b002c8, total 12059352
Allocated 131072 Bytes at 0xc0b202d0, total 12190432
Allocated 131072 Bytes at 0xc0b402d8, total 12321512
Allocated 131072 Bytes at 0xc0b602e0, total 12452592
Allocated 131072 Bytes at 0xc0b802e8, total 12583672
Allocated 131072 Bytes at 0xc0ba02f0, total 12714752
Allocated 131072 Bytes at 0xc0bc02f8, total 12845832
Allocated 131072 Bytes at 0xc0be0300, total 12976912
Allocated 131072 Bytes at 0xc0c00308, total 13107992
Allocated 131072 Bytes at 0xc0c20310, total 13239072
Allocated 131072 Bytes at 0xc0c40318, total 13370152
Allocated 131072 Bytes at 0xc0c60320, total 13501232
Allocated 131072 Bytes at 0xc0c80328, total 13632312
Allocated 131072 Bytes at 0xc0ca0330, total 13763392
Allocated 131072 Bytes at 0xc0cc0338, total 13894472
Allocated 131072 Bytes at 0xc0ce0340, total 14025552
Allocated 131072 Bytes at 0xc0d00348, total 14156632
Allocated 131072 Bytes at 0xc0d20350, total 14287712
Allocated 131072 Bytes at 0xc0d40358, total 14418792
Allocated 131072 Bytes at 0xc0d60360, total 14549872
Allocated 131072 Bytes at 0xc0d80368, total 14680952
Allocated 131072 Bytes at 0xc0da0370, total 14812032
Allocated 131072 Bytes at 0xc0dc0378, total 14943112
Allocated 131072 Bytes at 0xc0de0380, total 15074192
Allocated 131072 Bytes at 0xc0e00388, total 15205272
Allocated 131072 Bytes at 0xc0e20390, total 15336352
Allocated 131072 Bytes at 0xc0e40398, total 15467432
Allocated 131072 Bytes at 0xc0e603a0, total 15598512
Allocated 131072 Bytes at 0xc0e803a8, total 15729592
Allocated 131072 Bytes at 0xc0ea03b0, total 15860672
Allocated 131072 Bytes at 0xc0ec03b8, total 15991752
Allocated 131072 Bytes at 0xc0ee03c0, total 16122832
Allocated 131072 Bytes at 0xc0f003c8, total 16253912
Allocated 131072 Bytes at 0xc0f203d0, total 16384992
Allocated 131072 Bytes at 0xc0f403d8, total 16516072
Allocated 131072 Bytes at 0xc0f603e0, total 16647152
Allocated 131072 Bytes at 0xc0f803e8, total 16778232
Allocated 131072 Bytes at 0xc0fa03f0, total 16909312
Allocated 131072 Bytes at 0xc0fc03f8, total 17040392
Allocations count: 130
Free 131072 Bytes at 0x200013a8, total 16909328
Free 131072 Bytes at 0x200213c0, total 16778248
Free 131072 Bytes at 0x200413d8, total 16647168
Free 131072 Bytes at 0xc0000008, total 16516088
Free 131072 Bytes at 0xc0020010, total 16385008
Free 131072 Bytes at 0xc0040018, total 16253928
Free 131072 Bytes at 0xc0060020, total 16122848
Free 131072 Bytes at 0xc0080028, total 15991768
Free 131072 Bytes at 0xc00a0030, total 15860688
Free 131072 Bytes at 0xc00c0038, total 15729608
Free 131072 Bytes at 0xc00e0040, total 15598528
Free 131072 Bytes at 0xc0100048, total 15467448
Free 131072 Bytes at 0xc0120050, total 15336368
Free 131072 Bytes at 0xc0140058, total 15205288
Free 131072 Bytes at 0xc0160060, total 15074208
Free 131072 Bytes at 0xc0180068, total 14943128
Free 131072 Bytes at 0xc01a0070, total 14812048
Free 131072 Bytes at 0xc01c0078, total 14680968
Free 131072 Bytes at 0xc01e0080, total 14549888
Free 131072 Bytes at 0xc0200088, total 14418808
Free 131072 Bytes at 0xc0220090, total 14287728
Free 131072 Bytes at 0xc0240098, total 14156648
Free 131072 Bytes at 0xc02600a0, total 14025568
Free 131072 Bytes at 0xc02800a8, total 13894488
Free 131072 Bytes at 0xc02a00b0, total 13763408
Free 131072 Bytes at 0xc02c00b8, total 13632328
Free 131072 Bytes at 0xc02e00c0, total 13501248
Free 131072 Bytes at 0xc03000c8, total 13370168
Free 131072 Bytes at 0xc03200d0, total 13239088
Free 131072 Bytes at 0xc03400d8, total 13108008
Free 131072 Bytes at 0xc03600e0, total 12976928
Free 131072 Bytes at 0xc03800e8, total 12845848
Free 131072 Bytes at 0xc03a00f0, total 12714768
Free 131072 Bytes at 0xc03c00f8, total 12583688
Free 131072 Bytes at 0xc03e0100, total 12452608
Free 131072 Bytes at 0xc0400108, total 12321528
Free 131072 Bytes at 0xc0420110, total 12190448
Free 131072 Bytes at 0xc0440118, total 12059368
Free 131072 Bytes at 0xc0460120, total 11928288
Free 131072 Bytes at 0xc0480128, total 11797208
Free 131072 Bytes at 0xc04a0130, total 11666128
Free 131072 Bytes at 0xc04c0138, total 11535048
Free 131072 Bytes at 0xc04e0140, total 11403968
Free 131072 Bytes at 0xc0500148, total 11272888
Free 131072 Bytes at 0xc0520150, total 11141808
Free 131072 Bytes at 0xc0540158, total 11010728
Free 131072 Bytes at 0xc0560160, total 10879648
Free 131072 Bytes at 0xc0580168, total 10748568
Free 131072 Bytes at 0xc05a0170, total 10617488
Free 131072 Bytes at 0xc05c0178, total 10486408
Free 131072 Bytes at 0xc05e0180, total 10355328
Free 131072 Bytes at 0xc0600188, total 10224248
Free 131072 Bytes at 0xc0620190, total 10093168
Free 131072 Bytes at 0xc0640198, total 9962088
Free 131072 Bytes at 0xc06601a0, total 9831008
Free 131072 Bytes at 0xc06801a8, total 9699928
Free 131072 Bytes at 0xc06a01b0, total 9568848
Free 131072 Bytes at 0xc06c01b8, total 9437768
Free 131072 Bytes at 0xc06e01c0, total 9306688
Free 131072 Bytes at 0xc07001c8, total 9175608
Free 131072 Bytes at 0xc07201d0, total 9044528
Free 131072 Bytes at 0xc07401d8, total 8913448
Free 131072 Bytes at 0xc07601e0, total 8782368
Free 131072 Bytes at 0xc07801e8, total 8651288
Free 131072 Bytes at 0xc07a01f0, total 8520208
Free 131072 Bytes at 0xc07c01f8, total 8389128
Free 131072 Bytes at 0xc07e0200, total 8258048
Free 131072 Bytes at 0xc0800208, total 8126968
Free 131072 Bytes at 0xc0820210, total 7995888
Free 131072 Bytes at 0xc0840218, total 7864808
Free 131072 Bytes at 0xc0860220, total 7733728
Free 131072 Bytes at 0xc0880228, total 7602648
Free 131072 Bytes at 0xc08a0230, total 7471568
Free 131072 Bytes at 0xc08c0238, total 7340488
Free 131072 Bytes at 0xc08e0240, total 7209408
Free 131072 Bytes at 0xc0900248, total 7078328
Free 131072 Bytes at 0xc0920250, total 6947248
Free 131072 Bytes at 0xc0940258, total 6816168
Free 131072 Bytes at 0xc0960260, total 6685088
Free 131072 Bytes at 0xc0980268, total 6554008
Free 131072 Bytes at 0xc09a0270, total 6422928
Free 131072 Bytes at 0xc09c0278, total 6291848
Free 131072 Bytes at 0xc09e0280, total 6160768
Free 131072 Bytes at 0xc0a00288, total 6029688
Free 131072 Bytes at 0xc0a20290, total 5898608
Free 131072 Bytes at 0xc0a40298, total 5767528
Free 131072 Bytes at 0xc0a602a0, total 5636448
Free 131072 Bytes at 0xc0a802a8, total 5505368
Free 131072 Bytes at 0xc0aa02b0, total 5374288
Free 131072 Bytes at 0xc0ac02b8, total 5243208
Free 131072 Bytes at 0xc0ae02c0, total 5112128
Free 131072 Bytes at 0xc0b002c8, total 4981048
Free 131072 Bytes at 0xc0b202d0, total 4849968
Free 131072 Bytes at 0xc0b402d8, total 4718888
Free 131072 Bytes at 0xc0b602e0, total 4587808
Free 131072 Bytes at 0xc0b802e8, total 4456728
Free 131072 Bytes at 0xc0ba02f0, total 4325648
Free 131072 Bytes at 0xc0bc02f8, total 4194568
Free 131072 Bytes at 0xc0be0300, total 4063488
Free 131072 Bytes at 0xc0c00308, total 3932408
Free 131072 Bytes at 0xc0c20310, total 3801328
Free 131072 Bytes at 0xc0c40318, total 3670248
Free 131072 Bytes at 0xc0c60320, total 3539168
Free 131072 Bytes at 0xc0c80328, total 3408088
Free 131072 Bytes at 0xc0ca0330, total 3277008
Free 131072 Bytes at 0xc0cc0338, total 3145928
Free 131072 Bytes at 0xc0ce0340, total 3014848
Free 131072 Bytes at 0xc0d00348, total 2883768
Free 131072 Bytes at 0xc0d20350, total 2752688
Free 131072 Bytes at 0xc0d40358, total 2621608
Free 131072 Bytes at 0xc0d60360, total 2490528
Free 131072 Bytes at 0xc0d80368, total 2359448
Free 131072 Bytes at 0xc0da0370, total 2228368
Free 131072 Bytes at 0xc0dc0378, total 2097288
Free 131072 Bytes at 0xc0de0380, total 1966208
Free 131072 Bytes at 0xc0e00388, total 1835128
Free 131072 Bytes at 0xc0e20390, total 1704048
Free 131072 Bytes at 0xc0e40398, total 1572968
Free 131072 Bytes at 0xc0e603a0, total 1441888
Free 131072 Bytes at 0xc0e803a8, total 1310808
Free 131072 Bytes at 0xc0ea03b0, total 1179728
Free 131072 Bytes at 0xc0ec03b8, total 1048648
Free 131072 Bytes at 0xc0ee03c0, total 917568
Free 131072 Bytes at 0xc0f003c8, total 786488
Free 131072 Bytes at 0xc0f203d0, total 655408
Free 131072 Bytes at 0xc0f403d8, total 524328
Free 131072 Bytes at 0xc0f603e0, total 393248
Free 131072 Bytes at 0xc0f803e8, total 262168
Free 131072 Bytes at 0xc0fa03f0, total 131088
Free 131072 Bytes at 0xc0fc03f8, total 8
Free count: 130
...
Free 131072 Bytes at 0xc0fc03f8, total 8
Free count: 130
[SUCCESS]
{ "threads": [{ "name": "main", "stack_size": 1536, "stack_used": 396 }]}
```
</details>
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19884: drivers/touch_dev_gestures: add gesture recognition for touch devices r=aabadie a=gschorcht
### Contribution description
This PR adds simple gesture recognition for touch devices accessed via the generic Touch Device API. It can be used in conjunction with device drivers that use either interrupts or polling mode. It supports up to two touches and the following gestures:
- Single and double tap at given position
- Long press and release given position
- Moving while pressed with current position
- Swipe left, right, up and down
- Zoom in (spread) and out (pinch)
Gesture recognition has been tested with:
- [x] `stm32f746g-disco` (works out of the box)
- [x] `stm32f723e-disco` (works out of the box)
- [x] `stm32f429i-disc1` (works on top of PR #19885)
- [x] `stm32l496g-disco` (works with my local LCD display changes waiting for PR #19825, not yet provided)
- [x] `esp32s3-wt32-sc01-plus` (new board, not yet provided)
### Testing procedure
Flash `tests/drivers/touch_dev_gestures` to a board with touch pane, for example:
```
BOARD=stm32f746g-disco make -j8 -C tests/drivers/touch_dev_gestures/ flash
```
PR #19885 is required for the `stm32f429i-disc1` board.
The output should look like this:
```
main(): This is RIOT! (Version: 2023.10-devel-121-g81c5c-drivers/touch_dev_gestures)
Single Tap X: 255, Y:154
Single Tap X: 253, Y:153
Double Tap X: 253, Y:149
Swipe right
Swipe down
Swipe left
Swipe up
Pressed X: 257, Y:155
Moving X: 257, Y:155
Moving X: 257, Y:155
Moving X: 259, Y:156
Moving X: 262, Y:157
Moving X: 266, Y:158
Moving X: 269, Y:160
Moving X: 273, Y:162
Moving X: 276, Y:165
Moving X: 278, Y:167
Moving X: 278, Y:169
Moving X: 278, Y:169
Released X: 279, Y:172
```
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19882: tests/drivers/touch_dev: allow to test a touch device in polling mode r=aabadie a=gschorcht
### Contribution description
To be able to test the touch device in polling mode, variable `TOUCH_DEV_POLLING` is introduced. It is set to 0 by default and can be overriden by 1 to use the polling mode. The polling period can be controlled by the `TOUCH_DEV_POLLING_PERIOD` variable.
To use it for `ft5x06` and `stmpe811` drivers, the polling mode has to be fixed for these touch device drivers (PR #19880 respective PR #19881).
### Testing procedure
Use any board with touch device driver that uses the generic touch device API, for example (PR #19881 is required)
```
TOUCH_DEV_POLLING_MODE=1 TOUCH_DEV_POLLING_PERIOD=100 \
BOARD=stm32f429i-disc1 make -C tests/drivers/touch_dev flash term
```
or (PR #19880 is required)
```
TOUCH_DEV_POLLING_MODE=1 TOUCH_DEV_POLLING_PERIOD=100 \
BOARD=stm32f746g-disco make -C tests/drivers/touch_dev flash term
```
### Issues/PRs references
Depends partially on PR #19880
Depends partially on PR #19881
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
To be able to test the FT5x06 device driver in polling mode, variable `FT5X06_POLLING_MODE` is introduced. It is set to 0 by default and can be overriden by 1 to use the polling mode. The polling period can be controlled by the `FT5X06_POLLING_PERIOD` variable.
19870: tests/gcoap_fileserver: only enable test with GCC r=benpicco a=benpicco
19900: gnrc_ipv6_nib: fix for border router with non-6lo interfaces r=benpicco a=benpicco
19902: tests/pkg/relic: skip CI testing with samr21-xpro and llvm toolchain 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: Alexandre Abadie <alexandre.abadie@inria.fr>
19881: drivers/stmpe811: fix initialization if callback function parameter is NULL r=benpicco a=gschorcht
### Contribution description
This PR fixes the `stmpe811` driver initialization if the callback function parameter `cb` is `NULL. This might be the case for example if the application uses the touch device in polling mode.
If the interrupt pin is initialized if the callback function parameter `cb` is `NULL`, the driver crashes the first time an interrupt is triggered. Therefore, the INT pin must be initialized only if also the callback function parameter `cb` is not `NULL`.
To be able to test the polling mode, this PR also includes a change of the `tests/drivers/stmpe811` application which introduces the environment variables `STMPE811_POLLING_MODE` `STMPE811_POLLING_PERIOD` and in the makefile.
### Testing procedure
1. Use a `stm32f429i-disc1` board and test it in polling mode:
```
STMPE811_POLLING_MODE=1 BOARD=stm32f429i-disc1 make -C tests/drivers/stmpe811 flash term
```
It should work as expected.
```
main(): This is RIOT! (Version: 2023.10-devel-119-g26e7a-drivers/stmpe811_fix_cb_null)
STMPE811 test application
+------------Initializing------------+
Initialization successful
Pressed!
X: 113, Y:135
X: 113, Y:135
X: 113, Y:136
Released!
```
2. Checkout master branch and cerry-pick commit 691a5e6308426ddc685e5a2c297238529211c258. The test application `tests/drivers/stmpe811` will crash once a touch event occur:
```
main(): This is RIOT! (Version: 2023.10-devel-117-g91441)
STMPE811 test application
+------------Initializing------------+
Initialization successful
Stack pointer corrupted, reset to top of stack
FSR/FAR:
CFSR: 0x00020000
HFSR: 0x40000000
DFSR: 0x00000008
AFSR: 0x00000000
Misc
EXC_RET: 0xfffffff1
*** RIOT kernel panic:
HARD FAULT HANDLER
```
### Issues/PRs references
19892: pkg/tinydtls: allow to set buffer size from application again r=benpicco a=leandrolanzieri
### Contribution description
Currently the buffer size on tinydtls is set in its Makefile whenever `gcoap` module is present. This limits the ability of the user to override the value. This adds a pre-check of the `CFLAGS` to see if it was set before.
### Testing procedure
Try setting `CFLAGS += -DDTLS_MAX_BUF=<some_value>` on `examples/gcoap_dtls`, you should be able to override the default value without errors.
### Issues/PRs references
Reported in #19838
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Leandro Lanzieri <leandro.lanzieri@haw-hamburg.de>
19539: drivers/periph_sdmmc: define a High-level SDIO/SD/MMC API and low-level SDMMC periperal driver interface r=benpicco a=gschorcht
### Contribution description
This PR provides a SDIO/SD/MMC Device API (SDMMC). It implements a SD host controller driver that provides a high-level functions using a low-level SDIO/SD/MMC peripheral driver for accessing
- MultiMediaCards (MMC) and Embedded MultiMediaCards (eMMC)
- SD Memory Cards (SD Cards) with Standard Capacity (SDSC), High Capacity (SDHC) or Extended Capacity (SDXC).
It supports:
- 1-bit, 4-bit and 8-bit data bus width
- Default Speed and High Speed
- Auto-CLK
The SDIO/SD/MMC device API (SDMMC) is divided into two parts:
1. The high-level API that implements the SD Host Controller driver and allows
- to inititialize and identify different types of cards,
- to access them either blockwise or bytewise,
- to get information about the used card, and
- to send single commands or application specific commands to the card.
2. The low-level SDIO/SD/MMC peripheral driver implements the low-level functions required by the high-level device API. It has to be implemented for each MCU.
### Limitations:
- Only one card per SDIO/SD/MMC device is supported.
- eMMCs specific features are not supported.
- UHS-I, UHS-II and UHS-III are not supported.
### Testing procedure
PR #19540, PR #19760 or PR #19786 is needed to test this PR.
### Issues/PRs references
Prerequisite for PR #19540
Prerequisite for PR #19760
Prerequisite for PR #19786
19815: cpu/sam0_common/periph/sdhc: busy waiting and clock fixes r=benpicco a=benpicco
19860: drivers/ft5x06: fix vendor ID for FT6xx6 and FTxxxx register addresses r=benpicco a=gschorcht
### Contribution description
This PR provides a fix of the vendor ID for FT6xx6 touch panel driver ICs and a fix of register addresses for FTxxxx.
According to the [Application Note for FT6x06 CTPM](https://cdn-shop.adafruit.com/datasheets/FT6x06_AN_public_ver0.1.3.pdf), the vendor ID of FT6x06 touch panel driver ICs is `0x11` instead of `0xcd`. Although there are no information found in the Web about the FT6x36, the FT6336U touch panel of a ESP32-S3 WT32 SC01 Plus is also working with `0x11` as vendor ID so that it seems that FT6x36 is also using `0x11` as vendor ID.
Figured out with a `stm32f723e-disco` board (revision D03). Without this PR, `tests/drivers/ft5x06` gives:
```
+------------Initializing------------+
[ft5x06] init: invalid vendor ID: '0x11' (expected: 0xcd)
[Error] Initialization failed
```
With this PR it works as expected.
```
+------------Initializing------------+
Initialization successful
main(): This is RIOT! (Version: 2023.10-devel-96-gbb9011-drivers/ft5x06_fix_vendor_id)
FT5x06 test application
+------------Initializing------------+
[ft5x06] init: configuring touchscreen interrupt
Initialization successful
1 touch detected
[ft5x06] read gesture_id '0x00'
Touch 1 - X: 151, Y:138
[ft5x06] read gesture_id '0x00'
```
Some background information found in the Web:
- According to the [STM32CubeF7](c20e6dd15b/Drivers/BSP/STM32F723E-Discovery/stm32f723e_discovery_ts.c (L24-L27)) the FRIDA LCD panel mounted on the `stm32f723e-disco` board either uses FT6x36 (prior revision D) or FT3x67 (revision D). However, the FT5x06 driver type for the card is defined as FT6x06, which does not seem correct: bb9011c3fb/boards/stm32f723e-disco/include/board.h (L59)
- According to the [STM32CubeF7](c20e6dd15b/Drivers/BSP/Components/ft6x06/ft6x06.h (L269-L270)), the vendor ID for FT6x36 should be `0xcd`. However, the FT6336U on ESP32-S3 WT32 SC01 Plus works with vendor ID `0x11`.
- The [Adafruit FT6206 library](95118cd983/Adafruit_FT6206.h (L28)) uses `0x11` as vendor id.
- The `stm32l496g-disco` board uses a FT6236 which has vendor ID `0xcd`.
So the information available on the web is confusing. Maybe, a better solution would be to accept `0x11` as well as `0xcd` as vendor ID for FT6xxx touch panels. Unfortunately, there are no documents available on the registers directly from FocalTech 😟 so it seems to be more speculation than knowledge.
### Testing procedure
### Issues/PRs references
19886: cpu/efm32: fix DAC configuration r=benpicco a=gschorcht
### Contribution description
The EFM32 MCU allows the reference voltage to be configured per DAC device, not per DAC channel. Also, the DAC reference voltage was defined in the configuration but not used anywhere.
At the moment we have only defined one board (`stwstk6220a`) that uses the DAC, so changing the configuration interface shouldn't be critical.
### Testing procedure
`tests/periph/dac` should still work for the `stwstk6220a`
```
BOARD=slwstk6220a make -j8 -C tests/periph/dac flash
```
I don't have a `stwstk6220a` board (EFM32 Series 0) so that I can't test it. I could only test it for the `sltb009a` board (EFM32 Series 1) with the change for VDAC in PR #19887.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
To be able to test the STMPE811 device driver in polling mode, variable `STMPE811_POLLING_MODE` is introduced. It is set to 0 by default and can be overriden by 1 to use the polling mode. The polling period can be controlled by the `STMPE811_POLLING_PERIOD` variable.
To be able to test the touch device in polling mode, variable `TOUCH_DEV_POLLING` is introduced. It is set to 0 by default and can be overriden by 1 to use the polling mode. The polling period can be controlled by the `TOUCH_DEV_POLLING_PERIOD` variable.
19863: pkg/flashdb: bump to 2.0.0 r=benpicco a=benpicco
19864: tests/gcoap_fileserver: add zep_dispatcher to TEST_DEPS r=benpicco a=benpicco
19865: tests/pkg/lvgl*: fix the main thread stack size for ESPs r=benpicco a=gschorcht
### Contribution description
ESPx SoC need more stack size for the main thread to avoid stack overflows.
### Testing procedure
Use any ESP32 board or any ESP32-S2 board and flash `tests/pkg/lvgl` for the `esp32-wrover-kit` respective the `esp32s2-lilygo-ttgo-t8`, for example:
```
BOARD=esp32-wrover-kit make -j8 -C tests/pkg/lvgl flash
```
Without this PR the application crashes
```
main(): This is RIOT! (Version: 2023.10-devel-106-gd512f-tests/pkg/lvgl_fix_main_stack_size)
EXCEPTION!! exccause=29 (StoreProhibitedCause) `@4008274a` excvaddr=fefffffb
heap: 310368 (used 4176, free 306192) [bytes]
register set
pc : 40082f74 ps : 00050033 exccause: 0000001d excvaddr: fefffffb
epc1 : 40082f74
a0 : 4008274a a1 : 3ffb1bd0 a2 : fefffff7 a3 : 00000000
a4 : 3ff000dc a5 : 400826e0 a6 : 00000000 a7 : 3ffb1e08
a8 : 0000000b a9 : 3ffb1df8 a10 : 3ffb1e7c a11 : 00000001
a12 : 00000000 a13 : 00000000 a14 : 00000000 a15 : 000000a3
```
with this PR the application works as expected.
### Issues/PRs references
19869: make: COMPILE_COMMANDS_PATH adapt for external apps r=benpicco a=kfessel
### Contribution description
`COMPILE_COMMANDS_PATH` currently defaults to `RIOTBASE` which may not be an parent path for external applications -> set to `APPDIR` in case
### Testing procedure
- current good will stay good
test with riot examples and or testes `$make compile-commands` should create a `compile_command.json` in `<RIOT>`
- test with external app Makefile including
`include $(RIOTBASE)/Makefile.include`
should create `compile_command.json` in `APPDIR`
### Issues/PRs references
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Karl Fessel <karl.fessel@ml-pa.com>
19856: tests/net/gcoap_fileserver: Fix failing nightlies r=benpicco a=MrKevinWeiss
### Contribution description
This test has been failing inconsistently in the nightlies and sometimes on unrelated PRs. I was able to reproduce it with murdock and as soon as I added some print statements to the test it went away. Since the issue is something to do with a failure when comparing 2 files after a node sends a file I am guessing that the comparison comes occasionally too fast and the file is not ready.
Maybe there is some more synchronization needed after a `ncput` but for now just adding a small sleep should prevent this issue.
### Testing procedure
Run murdock multiple times or try to get it failing on a local setup then apply the PR...
### Issues/PRs references
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
19854: cpu/esp_common: esp-wifi: drop assert(val) r=benpicco a=benpicco
19858: tests/drivers/shtcx: don't repeat last string on error r=benpicco a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
To detect misconfigurations of addresses and sizes, the whole memory is filled word-wise with it's addresses. If the content doesn't match, it prints the address and the content.
f
This triggers a known bug much more often than with gnu toolchains to
the point that merging this PR without disabling the test would
render the CI useless.
19487: nanocoap: implement extended tokens (RFC 8974) r=benpicco a=benpicco
19808: boards: add ESP32-S3-USB-OTG support r=benpicco a=gschorcht
### Contribution description
This PR provides the support for the [ESP32-S3-USB-OTG](https://docs.espressif.com/projects/espressif-esp-dev-kits/en/latest/esp32s3/esp32-s3-usb-otg/user_guide.html) board.
The SD card can only be used in SPI mode at the moment. As soon as PR #19786 is merged, the SD/MMC support can be enabled and the SD card can then be used in SD mode with 4-bit data bus width.
The display uses uses the ST7789 driver IC that is compatible with the ST7735. For that purpose the ST7735 driver is extended by a pseudomodule definition `st7789` for the ST7789 which is enabled by the board and enables automatically the `st7789` (e57c48a33ee2a869c15603788e5306ba066f91cf). Vise versa, board's `Makefile.dep` enables automatically the `st7789` pseudomodule if the `st7735` is used. The pseudomodule `st7789` is just used to increase the upper limit for supported lines. This change is also part of PR #19807.
~The PR includes a very small documentation fix for ESP32-S3-DevKit board that was noticed during the development of this board definition (1155b6ac1b8efa39d8a0bd7150e602095159fdc1).~
### Testing procedure
The board has been tested with all basic tests for supported hardware including `tests/driver/st3375`:
- [x] tests/drivers/st3375
- [x] tests/periph/gpio
- [x] tests/periph/pwm
- [x] tests/periph/spi
- [x] tests/periph/uart
- [x] tests/sys/usbus_cdc_ecm
### Issues/PRs references
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
Co-authored-by: Gunar Schorcht <gunar@schorcht.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>
19712: cpu/riscv: Add PMP driver r=MrKevinWeiss a=Teufelchen1
### Contribution description
Hi! 🐘
this adds a basic RISC-V physical memory protection (PMP) driver to RIOT. Well, 'driver' might be a stretched, feels more like a little utility :)
EDIT: Also added a no-execute RAM option for the hifive & a corresponding test
Since I only have an Hifive rev b, it's only enabled on this board / cpu. I also tested the code on an ESP32-C but the feature can't be enabled there, as `cpu/riscv_common/` is not used by the ESP32...
### Testing procedure
* Grab a hifive rev b
* go to `examples/hello-world`
* Add `USEMODULES += periph_pmp` to the `Makefile`
* Include `pmp.h` in `main.c`
* Add code e.g. `print_pmpcfg(0);`
* compile & flash & term
You should see something like this:
```
# Hello World!
# You are running RIOT on a(n) hifive1b board.
# This board features a(n) fe310 MCU.
# pmp00cfg: - R-X OFF 0x00000000 - 0x00000000
```
Co-authored-by: Teufelchen1 <bennet.blischke@outlook.com>
19766: core/lib: make the use of DEBUG_BREAKPOINT on assert optional r=gschorcht a=gschorcht
### Contribution description
This PR makes the use of `DEBUG_BREAKPOINT` on failed assertion optional.
The behavior of `assert` has been changed with PR #19368. Instead of printing some useful information, either a breakpoint is inserted and the execution of the MCU stops in debugger or a endless while loop is executed.
Before PR #19368 the user got on failed assertion:
```
Starting ESP32x with ID: 7cdfa1e36a34
ESP-IDF SDK Version v4.4.1-0-g1329b19fe49
...
*** RIOT kernel panic:
FAILED ASSERTION.
*** halted.
```
This was very helpful during development, especially to identify quickly the cause of problems with `DEBUG_ASSERT_VERBOSE` enabled, e.g. when misconfiguration led to failed assertions.
With PR #19368 the user gets an address in best case (or even `0` on platforms like ESP32), in worst case the MCU seems to stuck, e.g.
```
Starting ESP32x with ID: 7cdfa1e36a34
ESP-IDF SDK Version v4.4.1-0-g1329b19fe49
...
0
```
The problem with the new behavior is that
- a user doesn't get a quick indication of what happened
- there is not always an easy way to attach a debugger
This PR therefore makes the use of `DEBUG_BREAKPOINT` optional using `DEBUG_ASSERT_BREAKPOINT` define.
### Testing procedure
Add `assert(0)` in `examples/hello-world/main.c` and compile with and w/o `CFLAGS='-DDEBUG_ASSERT_BREAKPOINT'`.
With `DEBUG_ASSERT_BREAKPOINT` the execution should stop in `assert_failue`. Without `DEBUG_ASSERT_BREAKPOINT`, the information as generated before PR #19368 and the execution should stop in `panic_arch`.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
- Rename all `arduino_pinmap.h` to `arduino_iomap.h`
- An empty `arduino_pinmap.h` that just includes `arduino_iomap.h`
is provided for backward compatibility
- Move all info from `arduino_board.h` into the new file as trivial
macros, so that they can also be used outside of sketches
- The new name reflects the fact not just pin mappings, but also
other I/O features such as PWMs are mapped
- Drop all `arduino_board.h`
- `arduino_board.h` and `arduino_iomap.h` now provide the exact
same information, just in a different format
- a generic `arduino_board.h` is provided instead that just
uses the info in `arduinio_iomap.h` and provides them in the
format the code in `sys/arduino` expects it
- Add fine grained features to indicate for mappings
- availability of mappings for analog pins, DAC pins, PWM pins,
UART devices, SPI/I2C buses to the corresponding RIOT
identification can now be expressed:
- `arduino_pins`: `ARDUINO_PIN_0` etc. are available
- `arduino_analog`: `ARDUINO_A0` etc. are available
- `arduino_pwm`: `ARDUINO_PIN_13_PWM_DEV` etc. are available
- `arduino_dac`: `ARDUINO_DAC0` etc. are available
- `arduino_uart`: `ARDUINO_UART_D0D1` or similar are available
- `arduino_spi`: `ARDUINO_SPI_ISP` or similar are available
- `arduino_i2c`: `ARDUINO_I2C_UNO` or similar are available
- mechanical/electrical compatibility with specific form factors
can now be expressed as features:
- `aruino_shield_nano`: Arduino NANO compatible headers
- `aruino_shield_uno`: Arduino UNO compatible headers
- `aruino_shield_mega`: Arduino MEGA compatible headers
- `aruino_shield_isp`: ISP header is available
This provides the groundwork to implement shield support as modules
that can rely on the I/O mappings, rather than having to provide a
configuration per board.
19718: drivers/dht: busy wait reimplementation r=benpicco a=hugueslarrive
### Contribution description
In PR #19674, I also provided quick and dirty fixes to restore functionality on esp8266 and enable operation on AVR. While reviewing PR #18591, it became apparent to me that this driver needed a refresh, particularly its migration to ztimer.
The cause of the malfunction on esp8266 was that since the default switch to ztimer as the backend for xtimer, XTIMER_BACKOFF was no longer taken into account. Therefore, the correction I provided in PR #19674 simply made explicit what was previously done implicitly with xtimer and now needs to be done explicitly with ztimer (spinning instead of sleeping).
Moreover, it was unnecessarily complex to measure the pulse duration in a busy-wait implementation, which required 2 calls to ztimer_now() and 32-bit operations expensive on 8-bit architecture. Instead, it is sufficient to read the state of the bus at the threshold moment.
Finally, in practice, it is possible to reduce the read interval (down to less than 0.5s for DHT22) by "harassing" the DHT with start signals until it responds.
This re-implementation brings the following improvements:
- Many backports from `@maribu's` IRQ based implementation (#18591):
- Use of ztimer
- Use of errno.h
- Use of a dht_data structure to pass arguments, to facilitate integration
- Adaptation of the bit parsing technique to parse bits into the data array
- Reintroduction of DHT11/DHT22 differentiation.
- Separation of `dht_read()` steps into functions for better readability and the ability to share certain functions among different implementations
- Sensor presence check in `dht_init()`
- ~~Automatic adjustment to a minimum data hold time~~
- Default input mode changed to open drain (a pull-up resistor should be placed close to the output if necessary but not close to the input)
- AVR support without platform-specific handling by avoiding ztimer_spin() and using the overflow of an 8-bit variable as a pre-timeout to minimize time-consuming ztimer_now() calls
Regarding the changes in the start signal sequence and the removal of the `_reset()` function:
~~In the previous implementation, there was an unnecessary spike at the beginning of the signal sequence, corresponding to START_HIGH_TIME. This spike has been removed in the re-implementation, as it is unnecessary. Instead, the MCU now simply pulls the signal low for START_LOW_TIME and then releases the bus, which is sufficient for initiating communication with the DHT sensor.~~ Actually, it is necessary to raise the bus level; otherwise, the _wait_for_level() called immediately after to check the response of the DHT may read the port before the signal level is raised, resulting in a false positive.
Additionally, the previous implementation had an issue where the MCU switched back to output mode and went high immediately after reading the 40 bits of data. However, the DHT sensor was still transmitting 2 or 3 additional bytes of '0' at that point, causing a conflict. This issue has been resolved in the re-implementation:
~~Regarding the optimization for AVR, I have performed measurements of `_wait_for_level()` until timeout (85 loops):~~
~~- on esp8266-esp-12x: 264 µs, which is 3.11 µs per loop~~
~~- on nucleo-f303k8: 319 µs, which is 3.75 µs per loop~~
~~- on arduino-nano: 3608 µs, which is 42.45 µs per loop~~
~~Duration measurements on the Arduino Nano:~~
19737: dist/tools/openocd: start debug-server in background and wait r=benpicco a=fabian18
19746: buildsystem: Always expose CPU_RAM_BASE & SIZE flags r=benpicco a=Teufelchen1
### Contribution description
Hello 🐧
This moves the definition of `CPU_RAM_BASE/SIZE` from being only available in certain situation to be always available.
Reason for change is to simplify common code in the cpu folder.
In cooperation with `@benpicco`
### Testing procedure
Passing CI
### Issues/PRs references
First usage will be in the PMP driver. Although there is more code in RIOT that could be refactored to use these defines instead of hacks / hardcoded values.
Co-authored-by: Hugues Larrive <hlarrive@pm.me>
Co-authored-by: Fabian Hüßler <fabian.huessler@ml-pa.com>
Co-authored-by: Teufelchen1 <bennet.blischke@outlook.com>
- many backports from @maribu's IRQ based implementation (#18591)
- use of ztimer and errno.h
- separation of dht_read() steps into functions for better readability
- reintroduction of DHT11/DHT22 differentiation
- sensor presence checking in dht_init()
- default input mode changed to open drain
- AVR support without platform-specific handling by avoiding
ztimer_spin() and using the overflow of an 8-bit variable as a
pre-timeout to minimize time-consuming ztimer_now() calls
- add a new DHT11_2022 type for 0.01 °C resolution devices
- data caching removed
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:
#ifndef UART_USE_USCI
/* implementation of x1xx peripheral ... */
#else
/* implementation of F2xx/G2xx peripheral ... */
#endif
/* zero shared code between both variants */
This splits the peripheral drivers for USCI and USART serial IP blocks
into separate files and relocates everything in cpu/msp430, similar to
how cpu/stm32 is organized.
[MSP430 x1xx]: https://www.ti.com/lit/ug/slau049f/slau049f.pdf
[MSP430 F2xx/G2xx]: https://www.ti.com/lit/ug/slau144k/slau144k.pdf
19743: tests/unittests: improve int size detection r=maribu a=maribu
### Contribution description
Deduce from the value of `INT_MAX` whether `int` is 16 bit or 32 bit, rather than check CPU names.
19744: tests: update tests for MSP430 CPU r=maribu a=maribu
### Contribution description
Using the builtin `__MSP430__` macro is fool-proof and stable even if one would try to rename and reorganize the MSP430 cpu code.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
19706: boards/olimex-msp430-h2618: add new board r=maribu a=maribu
### Contribution description
This adds support of the Olimex MSP430-H2618 board. This board has plenty of RAM and ROM for an MSP430 board (even more than the z1), but still is easily obtainable.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
19212: shell/rtc: use rtc_tm_normalize() to sanitize input r=benpicco a=benpicco
19360: gcoap: make use coap_build_reply() in gcoap_resp_init() r=benpicco a=benpicco
19401: shell/cmds: add genfile command r=benpicco a=benpicco
19645: sys/isrpipe: Replace xtimer with ztimer_usec r=benpicco a=MrKevinWeiss
### Contribution description
Getting ready for the xtimer dep.
### Testing procedure
Green murdock, there is no explicit test for isrpipe but since it runs xtimer compat it should operate the same.
### Issues/PRs references
19720: tests: remove unnecessary use of floating point r=benpicco a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
19695: drivers/hih6130: avoid using floats r=maribu a=maribu
### Contribution description
- avoid using floating point arithmetic
- use ztimer instead of xtimer
- use fmt to print fixed point numbers in the test app
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
19693: sys/color: extend unittest and fix module r=maribu a=kfessel
### Contribution description
this extends the unittest for sys_color testing more colors
### Testing procedure
```
RIOT_tree/tests/unittests$ make tests-color test
```
will fail since our `rgb2hsv` implementation is wrong (or is using an other colorspace than hsv2rgb (without documenting))
the new `hsv2rgb` test will succeed
### Issues/PRs references
#19614 was the reason i had a look at this
#1315 added the rgb2hsv and hsv2rgb function
#9940 added the test for black special case
https://www.vagrearg.org/content/hsvrgb << some optimization for that function (avoiding float)
Co-authored-by: Karl Fessel <karl.fessel@ovgu.de>
19696: drivers/mq3: avoid use of floats r=maribu a=maribu
19698: tests/pkg/lvgl: avoid using floats r=maribu a=maribu
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
19691: drivers/bmx055: fix crazy use of FPU r=maribu a=maribu
### Contribution description
As the title says...
19694: tests/drivers/epd_bw_spi_disp_dev: fix accidental use of FPU r=maribu a=maribu
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
19686: sys/string_utils: add memchk() r=maribu a=benpicco
19687: tests/unittests: remove old workaround for SAML1X and gcc9.X bug r=maribu a=dylad
### Contribution description
This reverts #13462, this workaround is no longer needed with newer GCC version.
### Testing procedure
Try to compile tests/unittests for `saml11-xpro` or `saml10-xpro`
### Issues/PRs references
This is a revert of #13462.
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
19650: drivers/nrf24l01p: model in kconfig r=aabadie a=aabadie
19660: cpu/rpx0xx: Fix kconfig model r=aabadie a=MrKevinWeiss
### Contribution description
Broken master due to incorrect model of the periph_pio in kconfig.
### Testing procedure
Green murdock (now that the board is added to the list)
### Issues/PRs references
Look at the master CI...
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
19618: cpu/stm32: fix riotboot settings for L4 and WB r=benpicco a=gschorcht
### Contribution description
This PR fixes the `riotboot` configuration for L4 and WB.
The family is not called `stm32l4` or `stm32wb` but `l4` and `wb`. That is, the `riotboot` configuration didn't work at all. Furthermore, a minimum `RIOTBOOT_LEN` of `0x2000` is required for L4.
Found when investigating the compilation errors for `bootloaders/riotboot_serial` in PR #19576.
### Testing procedure
1. Green CI.
2. Use the following commands:
```
BOARD=nucleo-l496zg make -C tests/riotboot info-debug-variable-RIOTBOOT_HDR_LEN
BOARD=p-nucleo-wb55 make -C tests/riotboot info-debug-variable-RIOTBOOT_HDR_LEN
```
In master these commands give
```
0x400
```
With this PR these commands give
```
0x200
```
as expected.
3. Use the following commands:
```
BOARD=nucleo-l496zg make -C tests/riotboot info-debug-variable-RIOTBOOT_LEN
BOARD=p-nucleo-wb55 make -C tests/riotboot info-debug-variable-RIOTBOOT_LEN
```
In master these commands give
```
0x1000
```
With this PR these commands give
```
0x2000
```
as expected.
### Issues/PRs references
19639: tests/net/gnrc_mac_timeout: add automated test r=aabadie a=aabadie
19644: gnrc_ipv6_nib: include RIO with all subnets in downstream RA r=benpicco a=benpicco
19649: gnrc_sixlowpan_iphc: prefix bits outside context must be zero r=benpicco a=benpicco
19656: gnrc/ipv6_auto_subnets: allow to configure minimal prefix length r=benpicco a=benpicco
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
- Replace all users of `$(RIOTBASE)/build` with the already present
`$(BUILD_DIR)` variable
- Replace all users of `$(BUILD_DIR)/pkg` with the already present
`$(PKGDIRBASE)` variable
- Create a `CACHEDIR.TAG` file in the `$(BUILD_DIR)`
18056: pkg/cmsis: use unique package for CMSIS headers, DSP and NN modules r=benpicco a=aabadie
19571: cpu/stm32/periph_adc: fixes and improvements for L4 support r=benpicco a=gschorcht
### Contribution description
This PR provides the following fixes and improvements for the `periph_adc` implementation for STM32L4.
- Support STM32L496AG added.
- Instead of defining the number of ADC devices for each MCU model, the number of ADC devices is determined from ADCx definitions in CMSIS header.
- MCU specific register/value defines are valid for all L4 MCUs, model based conditional compilation is removed.
- The ADC clock disable function is fixed using a counter. The counter is incremented in `prep` and decremented in `done`. The ADC clock is disabled if the counter becomes 0.
- For boards that have not connected the V_REF+ pin to an external reference voltage, the VREFBUF peripheral can be used as V_REF+ (if supported) by setting `VREFBUF_ENABLE=1`.
- The ASCR register is available and has to be set for all STM32L471xx, STM32L475xx, STM32L476xx, STM32L485xx and STM32L486xx MCUs. Instead of using the CPU model for conditional compilation, the CPU line is used to support all MCU of that lines.
- Setting of SQR1 is fixed. Setting the SQR1 did only work before because the `ADC_SRQ_L` is set to 0 for a sequence length of 1.
- Setting the `ADC_CCR_CKMODE` did only work for the reset state. It is now cleared before it is set. Instead of using the `ADC_CCR_CKMODE_x` bits to set the mode, the mode defines are used.
- Support for V_REFINT as ADC channel added.
### Testing procedure
19589: gnrc/gnrc_netif_hdr_print: printout timestamp if enabled r=aabadie a=chudov
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: chudov <chudov@gmail.com>
19585: tests: move leftover sys related tests to test/sys + move tests/sys/candev to tests/drivers r=aabadie a=aabadie
19586: tests: move net related applications to test/net r=aabadie a=aabadie
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
19582: tests: move nimble and lwip related to test applications to tests/pkg r=aabadie a=aabadie
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
19573: cpu/stm32/periph_dac: small improvements r=maribu a=gschorcht
### Contribution description
This PR provides the following improvements for `periph_dac` on STM32
- Support for `RCC_APB1ENR1_DAC1EN` symbol added.
- For boards that have not connected the V_REF+ pin to an external reference voltage, the VREFBUF peripheral can be used as V_REF+ (if supported) by setting `VREFBUF_ENABLE=1`.
- If the DAC peripheral has a mode register (`DAC_MCR`), it is set to normal mode with buffer enabled and connected to external pin and on-chip peripherals. This allows to measure the current value of a DAC channel with an ADC channel or to use the DAC channel also for other on-chip peripherals.
### Testing procedure
- Green CI
- `tests/periph_dac` should still work for any board supporting the `periph_dac` feature.
### Issues/PRs references
19579: doc/doxygen/src/flashing.md: work around Doxygen bug r=maribu a=maribu
### Contribution description
Doxygen fails to render inline code in headers correctly in the version the CI uses. So, work around the issue by not typestetting `stm32flash` as inline code but as regular text.
19583: tests: move cpu related applications to tests/cpu r=maribu a=aabadie
19584: tests/build_system/external_board_dirs: fix broken symlinks r=maribu a=aabadie
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
19565: tests: move core related applications to their own tests/core/ folder r=maribu a=aabadie
19568: tests: move remaining driver related applications to tests/drivers r=maribu a=aabadie
19574: cpu/stm32/periph_gpio: reset PU/PD for ADC channels r=maribu a=gschorcht
### Contribution description
This PR provides a small fix that is relevant when a GPIO has been used as input/output with a pull resistor before it is initialized as an ADC channel.
The PU/PD configuration has to be `0b00` for analog outputs which is corresponds to the reset state. However, if the GPIO is not in the reset state but was used digital input/output with any pull resistor, the PU/PD configuration has also to be reset to use it as ADC channel.
### Testing procedure
- Green CI
- The `periph_adc` test application should still work for any board that supports the `periph_adc` feature.
### Issues/PRs references
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19564: tests: move all bench applications to their own tests/bench/ folder r=aabadie a=aabadie
19569: tests/lua_loader: move to tests/pkg/lua_loader r=aabadie a=aabadie
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
19552: tests: move all periph applications to their own periphs/ folder r=gschorcht a=aabadie
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
19522: tests/periph_rtt: Fix for tick conversion test r=benpicco a=chudov
### Contribution description
Type casting and `printf` formatting for the `RTT_MAX_VALUE` and `RTT_FREQUENCY` are fixed so 32-bit value is properly handled by 'avr-libc'.
The original tick conversion test assumes that `RTT_FREQUENCY` is power of 2 so forward and backward ticks to seconds conversion results in the original ticks value. To fix it the result of the forward-backward conversion is compared with `ticktest / RTT_FREQUENCY * RTT_FREQUENCY` that considers rounding errors.
Changes were tested on deRFmega256 and nrf52840dongle.
### Testing procedure
tests/periph_rtt on a board with ATmega256RFR2 shall:
* show correct RTT_MAX_VALUE
* conversion check shall report no error.
### Issues/PRs references
Fixes#15940
Co-authored-by: chudov <chudov@gmail.com>
19368: debug: add DEBUG_BREAKPOINT() macro, set breakpoint on failed assertion r=benpicco a=benpicco
19529: cpu/stm32/periph/dac: optimize setting DAC r=benpicco a=Enoch247
### Contribution description
The current implmentation right shifted the 16 bit value passed into `dac_set()` down to the 12 bits that the DAC is actually capable of. This patch drops the shift and instead writes the 16 bit value to the DAC's left aligned 12 bit wide data holding register.
### Testing procedure
do something like:
``` c
#include "perip/dac.h"
int main(void)
{
dac_set(DAC_LINE(0), 0xffff/2);
return 0;
}
```
- observe DAC's output is half of vref
### Issues/PRs references
- none known
19531: tests/unittests: allow passing `UNIT_TESTS` via env r=benpicco a=kaspar030
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
Co-authored-by: Joshua DeWeese <jdeweese@primecontrols.com>
Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
19525: semtech-loramac: extend list of supported radio with sx1261, sx1262 and sx1268 r=maribu a=aabadie
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
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>
18620: core: add core_mutex_debug to aid debugging deadlocks r=maribu a=maribu
### Contribution description
Adding `USEMODULE += core_mutex_debug` to your `Makefile` results in
on log messages such as
[mutex] waiting for thread 1 (pc = 0x800024d)
being added whenever `mutex_lock()` blocks. This makes tracing down
deadlocks easier.
### Testing procedure
Run e.g.
```sh
USEMODULE=core_mutex_debug BOARD=nucleo-f767zi make -C tests/mutex_cancel flash test
```
which should provide output such as
```
Welcome to pyterm!
Type '/exit' to exit.
READY
s
[mutex] waiting for thread 1 (pc = 0x8000f35)
START
main(): This is RIOT! (Version: 2022.10-devel-841-g5cc02-core/mutex/debug)
Test Application for mutex_cancel / mutex_lock_cancelable
=========================================================
Test without cancellation: OK
Test early cancellation: OK
Verify no side effects on subsequent calls: [mutex] waiting for thread 1 (pc = 0x800024d)
OK
Test late cancellation: [mutex] waiting for thread 1 (pc = 0x0)
OK
TEST PASSED
```
```sh
$ arm-none-eabi-addr2line -a 0x800024d -e tests/mutex_cancel/bin/nucleo-f767zi/tests_mutex_cancel.elf
0x0800024d
/home/maribu/Repos/software/RIOT/tests/mutex_cancel/main.c:51
```
### Issues/PRs references
Depends on and includes https://github.com/RIOT-OS/RIOT/pull/18619
19296: nanocoap: allow to define CoAP resources as XFA r=maribu a=benpicco
19504: cpu/cc26xx_cc13xx: Fix bogus array-bound warning r=maribu a=maribu
### Contribution description
GCC 12 create a bogus array out of bounds warning as it assumes that because there is special handling for `uart == 0` and `uart == 1`, `uart` can indeed be `1`. There is an `assert(uart < UART_NUMOF)` above that would blow up prior to any out of bounds access.
In any case, optimizing out the special handling of `uart == 1` for when `UART_NUMOF == 1` likely improves the generated code and fixes the warning.
/home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:88:8: error: array subscript 1 is above array bounds of 'uart_isr_ctx_t[1]' [-Werror=array-bounds]
88 | ctx[uart].rx_cb = rx_cb;
| ~~~^~~~~~
/home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:52:23: note: while referencing 'ctx'
52 | static uart_isr_ctx_t ctx[UART_NUMOF];
| ^~~
/home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:89:8: error: array subscript 1 is above array bounds of 'uart_isr_ctx_t[1]' [-Werror=array-bounds]
89 | ctx[uart].arg = arg;
| ~~~^~~~~~
/home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:52:23: note: while referencing 'ctx'
52 | static uart_isr_ctx_t ctx[UART_NUMOF];
| ^~~
### Testing procedure
The actual change is a pretty obvious one-liner, so that code review and a green CI should be sufficient. If not, running any UART example app without regression should do.
### Issues/PRs references
None
19506: tools/openocd: Fix handling of OPENOCD_CMD_RESET_HALT r=maribu a=maribu
### Contribution description
The OPENOCD_CMD_RESET_HALT was not longer correctly passed to the script. This fixes the issue.
### Testing procedure
Flashing of e.g. the `cc2650-launchpad` with upstream OpenOCD should work again.
### Issues/PRs references
The change was added to https://github.com/RIOT-OS/RIOT/pull/19050 after testing the PR and before merging. I'm not sure if the fix never worked because of this, or if behavior of `target-export-variables` or GNU Make changed.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
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>
The board no longer uses the `periph_usbdev_hs` module. Therefore, the maximum number of EPs used is that of the USB OTG FS peripheral, which is only 4. This is not sufficient for this test application since the board uses `stdio_cdc_acm`.
19397: drivers/usbdev_synopsys_dwc2: fix and reenable DMA mode r=benpicco a=gschorcht
### Contribution description
This PR fixes the DMA mode for all STM32 USB OTG HS cores (including that for STM32F4xx CID 1.xxx) and reenables it. It fixes remaining problems in issue #19359.
This PR includes also includes some changes that are needed to use the DMA mode:
- EP number is used as defined in CMSIS (if defined) for STM32
- `periph_usbdev_hs` feature is added in Kconfig
- `periph_usbdev_hs` feature is added in board definition of `stm32f429i-disc1`
- largest number of available EPs is used for STM32 instead of the smallest number (to be able to use all EPs of HS peripheral)
- `stm32f429i-disco` is removed from blacklist in `tests/usbus_cdc_ecm` since it uses the HS peripheral
### Testing procedure
The following tests should work
```python
USEMODULE=stdio_cdc_acm BOARD=stm32f429i-disc1 make -j8 -C tests/usbus_cdc_ecm flash
```
<details>
<summary>Test results</summary>
```python
[526755.875691] usb 1-2.2: new full-speed USB device number 106 using xhci_hcd
[526755.977853] usb 1-2.2: config 1 interface 3 altsetting 1 endpoint 0x84 has invalid maxpacket 512, setting to 64
[526755.977856] usb 1-2.2: config 1 interface 3 altsetting 1 endpoint 0x2 has invalid maxpacket 512, setting to 64
[526755.978762] usb 1-2.2: New USB device found, idVendor=1209, idProduct=7d01, bcdDevice= 1.00
[526755.978764] usb 1-2.2: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[526755.978766] usb 1-2.2: Product: stm32f429i-disc1
[526755.978768] usb 1-2.2: Manufacturer: RIOT-os.org
[526755.978769] usb 1-2.2: SerialNumber: 7C156425A950A8EB
[526755.991190] cdc_acm 1-2.2:1.0: ttyACM1: USB ACM device
[526755.998131] cdc_ether 1-2.2:1.2 usb0: register 'cdc_ether' at usb-0000:00:14.0-2.2, CDC Ethernet Device, a6:f6:4a:85:1d:c9
[526756.044150] cdc_ether 1-2.2:1.2 enp0s20f0u2u2i2: renamed from usb0
```
</details>
```python
USEMODULE='stdio_cdc_acm periph_usbdev_hs_utmi' BOARD=stm32f723e-disco make -j8 -C tests/usbus_cdc_ecm flash
```
<details>
<summary>Test results</summary>
```python
[528733.480207] usb 1-4.3.4: reset high-speed USB device number 32 using xhci_hcd
[528733.707800] usb 1-4.4: new high-speed USB device number 111 using xhci_hcd
[528733.808257] usb 1-4.4: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11
[528733.808260] usb 1-4.4: config 1 interface 1 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64
[528733.808263] usb 1-4.4: config 1 interface 1 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
[528733.808642] usb 1-4.4: New USB device found, idVendor=1209, idProduct=7d01, bcdDevice= 1.00
[528733.808645] usb 1-4.4: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[528733.808647] usb 1-4.4: Product: stm32f723e-disco
[528733.808649] usb 1-4.4: Manufacturer: RIOT-os.org
[528733.808651] usb 1-4.4: SerialNumber: A6BAC4E1B1E0806B
[528733.811988] cdc_acm 1-4.4:1.0: ttyACM1: USB ACM device
[528733.814456] cdc_ether 1-4.4:1.2 usb0: register 'cdc_ether' at usb-0000:00:14.0-4.4, CDC Ethernet Device, e6:75:97:3a:74:ba
[528733.854371] cdc_ether 1-4.4:1.2 enp0s20f0u4u4i2: renamed from usb0
```
</details>
```python
USEMODULE='stdio_cdc_acm periph_usbdev_hs_ulpi' BOARD=stm32f746g-disco make -j8 -C tests/usbus_cdc_ecm flash
```
<details>
<summary>Test results</summary>
```python
[529000.944482] usb 1-4.3.4: reset high-speed USB device number 32 using xhci_hcd
[529003.728260] usb 1-4.4: new high-speed USB device number 114 using xhci_hcd
[529003.833107] usb 1-4.4: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11
[529003.833111] usb 1-4.4: config 1 interface 1 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64
[529003.833113] usb 1-4.4: config 1 interface 1 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
[529003.833743] usb 1-4.4: New USB device found, idVendor=1209, idProduct=7d00, bcdDevice= 1.00
[529003.833747] usb 1-4.4: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[529003.833749] usb 1-4.4: Product: stm32f746g-disco
[529003.833751] usb 1-4.4: Manufacturer: RIOT-os.org
[529003.833753] usb 1-4.4: SerialNumber: 66FE8934D1A363E0
[529003.837143] cdc_acm 1-4.4:1.0: ttyACM1: USB ACM device
[529003.839755] cdc_ether 1-4.4:1.2 usb0: register 'cdc_ether' at usb-0000:00:14.0-4.4, CDC Ethernet Device, 6a:88:1f:1f:b1:f0
[529003.879025] cdc_ether 1-4.4:1.2 enp0s20f0u4u4i2: renamed from usb0```
```
</details>
### Issues/PRs references
Fixes#19359
19416: cpu/rpx0xx/cmsis: Update vendor header files r=benpicco a=maribu
### Contribution description
Generated new vendor header files from upstream SVD files using:
./SVDConv "$PICO_SDK_DIR"/src/rp2040/hardware_regs/rp2040.svd \
--generate=header --fields=macro --fields=enum
Note: The missing `--fields=struct` flag resulted in the header no longer containing bit-fields to represent different fields within registers. While this would generally ease writing code, the RP2040 has the unpleasant feature of corrupting the remaining bits of the register when a write access that is not word-sized occurs in the memory mapped I/O area. This could happen e.g. when a bit field is byte-sized and byte-aligned.
### Testing procedure
No binary changes (hopefully).
### Issues/PRs references
This adds a few additional vendor defines, notably for USB. If anyone were to implement USB, this would be a requirement.
19418: cpu/gd32v: fix gpio_read in periph_gpio r=benpicco a=gschorcht
### Contribution description
This PR fixes a bug in `gpio_read` which made `gpio_read` completely unusable!
A small bug with big consequences. In `gpio_read` the combined port | pin_num parameter `pin` was used instead of the pin number `pin_num` for the call of `_pin_is_input`. This caused the problem that for example instead of accessing GPIOA->CTL0 with address 0x40010800, address 0x60018c00 was accessed. As a result, a pin was randomly detected as input or output and thus a result was arbitrarily returned. Approx. 50% of all inputs always returned LOW.
I found this error by coincidence when I tried to find out why the BOOT0 button on a Sipeed Longan Nano is not usable as a button in RIOT.
### Testing procedure
Flash `tests/periph_gpio`
```
BOARD=sipeed-longan-nano make -j8 -C tests/periph_gpio flash
```
and use commands
```
init_in 0 8
read 0 8
```
Without this PR, the pin is always LOW. With the PR, the pin should be HIGH when the BOOT button is pressed.
### Issues/PRs references
19419: boards/sipeed-longan-nano: add BOOT as user button r=benpicco a=gschorcht
### Contribution description
This PR makes the BOOT button usable as a user button.
### Testing procedure
The test requires PR #19418 to work.
Flash and test:
```
BOARD=sipeed-longan-nano make -j8 -C tests/saul flash term
```
The output
```
Dev: BOOT Type: SENSE_BTN
Data: 0
```
should change to
```
Dev: BOOT Type: SENSE_BTN
Data: 1
```
when the BOOT button is pressed.
### Issues/PRs references
Depends on PR #19418
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
19407: cpu/stm32/periph: Implement GPIO LL for STM32F1 without IRQ support (yet) r=gschorcht a=maribu
### Contribution description
This implements GPIO LL support for the STM32F1 in the first commit. IRQ support is added with https://github.com/RIOT-OS/RIOT/pull/19412.
This sneaks in a second commit replacing the `expect()` calls in `tests/periph_gpio_ll` with a trivial five-liner that doesn't `panic()`, so that stdio output will still be delivered on high level stdio implementations. The tests provides a lot of useful output to aid debugging, so its a great usability improvement if the test makes sure to actually deliver that output.
### Testing procedure
<details><summary><code>make -C tests/periph_gpio_ll BOARD=nucleo-f103rb flash term</code></summary>
```
2023-03-17 18:55:09,188 # Help: Press s to start test, r to print it is ready
s
2023-03-17 18:55:10,299 # START
2023-03-17 18:55:10,307 # main(): This is RIOT! (Version: 2023.04-devel-683-g9c3812-cpu/stm32/periph/gpio_ll)
2023-03-17 18:55:10,309 # Test / Hardware Details:
2023-03-17 18:55:10,310 # ========================
2023-03-17 18:55:10,311 # Cabling:
2023-03-17 18:55:10,313 # (INPUT -- OUTPUT)
2023-03-17 18:55:10,315 # P2.10 (PC10) -- P2.2 (PC2)
2023-03-17 18:55:10,318 # P2.12 (PC12) -- P2.3 (PC3)
2023-03-17 18:55:10,322 # Number of pull resistor values supported: 1
2023-03-17 18:55:10,325 # Number of drive strengths supported: 1
2023-03-17 18:55:10,328 # Number of slew rates supported: 3
2023-03-17 18:55:10,330 # Valid GPIO ports:
2023-03-17 18:55:10,332 # - PORT 0 (PORT A)
2023-03-17 18:55:10,333 # - PORT 1 (PORT B)
2023-03-17 18:55:10,335 # - PORT 2 (PORT C)
2023-03-17 18:55:10,336 # - PORT 3 (PORT D)
2023-03-17 18:55:10,338 # - PORT 4 (PORT E)
2023-03-17 18:55:10,338 #
2023-03-17 18:55:10,341 # Testing gpio_port_pack_addr()
2023-03-17 18:55:10,343 # =============================
2023-03-17 18:55:10,343 #
2023-03-17 18:55:10,344 # All OK
2023-03-17 18:55:10,344 #
2023-03-17 18:55:10,346 # Testing gpip_ng_init()
2023-03-17 18:55:10,348 # ======================
2023-03-17 18:55:10,348 #
2023-03-17 18:55:10,354 # Testing is_gpio_port_num_valid() is true for PORT_OUT and PORT_IN:
2023-03-17 18:55:10,354 #
2023-03-17 18:55:10,358 # Testing input configurations for PIN_IN_0:
2023-03-17 18:55:10,361 # Support for input with pull up: yes
2023-03-17 18:55:10,366 # state: in, pull: up, schmitt trigger: off, value: on
2023-03-17 18:55:10,369 # Support for input with pull down: yes
2023-03-17 18:55:10,374 # state: in, pull: down, schmitt trigger: off, value: off
2023-03-17 18:55:10,378 # Support for input with pull to bus level: no
2023-03-17 18:55:10,383 # Support for floating input (no pull resistors): yes
2023-03-17 18:55:10,388 # state: in, pull: none, schmitt trigger: off, value: off
2023-03-17 18:55:10,388 #
2023-03-17 18:55:10,392 # Testing output configurations for PIN_OUT_0:
2023-03-17 18:55:10,397 # Support for output (push-pull) with initial value of LOW: yes
2023-03-17 18:55:10,401 # state: out-pp, slew: slowest, value: off
2023-03-17 18:55:10,404 # Output is indeed LOW: yes
2023-03-17 18:55:10,408 # state: out-pp, slew: slowest, value: on
2023-03-17 18:55:10,411 # Output can be pushed HIGH: yes
2023-03-17 18:55:10,417 # Support for output (push-pull) with initial value of HIGH: yes
2023-03-17 18:55:10,420 # state: out-pp, slew: slowest, value: on
2023-03-17 18:55:10,424 # Output is indeed HIGH: yes
2023-03-17 18:55:10,430 # Support for output (open drain with pull up) with initial value of LOW: no
2023-03-17 18:55:10,437 # Support for output (open drain with pull up) with initial value of HIGH: no
2023-03-17 18:55:10,443 # Support for output (open drain) with initial value of LOW: yes
2023-03-17 18:55:10,449 # state: out-od, slew: slowest, pull: none, schmitt trigger: off, value: off
2023-03-17 18:55:10,452 # Output is indeed LOW: yes
2023-03-17 18:55:10,458 # Support for output (open drain) with initial value of HIGH: yes
2023-03-17 18:55:10,465 # state: out-od, slew: slowest, pull: none, schmitt trigger: off, value: on
2023-03-17 18:55:10,470 # state: in, pull: down, schmitt trigger: off, value: off
2023-03-17 18:55:10,474 # Output can indeed be pulled LOW: yes
2023-03-17 18:55:10,478 # state: in, pull: up, schmitt trigger: off, value: on
2023-03-17 18:55:10,483 # Output can indeed be pulled HIGH: yes
2023-03-17 18:55:10,488 # Support for output (open source) with initial value of LOW: no
2023-03-17 18:55:10,494 # Support for output (open source) with initial value of HIGH: no
2023-03-17 18:55:10,501 # Support for output (open source with pull up) with initial value of HIGH: no
2023-03-17 18:55:10,508 # Support for output (open source with pull up) with initial value of LOW: no
2023-03-17 18:55:10,511 # Support for disconnecting GPIO: yes
2023-03-17 18:55:10,515 # Output can indeed be pulled LOW: yes
2023-03-17 18:55:10,519 # Output can indeed be pulled HIGH: yes
2023-03-17 18:55:10,519 #
2023-03-17 18:55:10,523 # Testing Reading/Writing GPIO Ports
2023-03-17 18:55:10,526 # ==================================
2023-03-17 18:55:10,526 #
2023-03-17 18:55:10,529 # testing initial value of 0 after init
2023-03-17 18:55:10,531 # ...OK
2023-03-17 18:55:10,535 # testing setting both outputs_optional simultaneously
2023-03-17 18:55:10,537 # ...OK
2023-03-17 18:55:10,541 # testing clearing both outputs_optional simultaneously
2023-03-17 18:55:10,543 # ...OK
2023-03-17 18:55:10,547 # testing toggling first output (0 --> 1)
2023-03-17 18:55:10,548 # ...OK
2023-03-17 18:55:10,552 # testing toggling first output (1 --> 0)
2023-03-17 18:55:10,553 # ...OK
2023-03-17 18:55:10,557 # testing toggling second output (0 --> 1)
2023-03-17 18:55:10,558 # ...OK
2023-03-17 18:55:10,562 # testing toggling second output (1 --> 0)
2023-03-17 18:55:10,563 # ...OK
2023-03-17 18:55:10,569 # testing setting first output and clearing second with write
2023-03-17 18:55:10,570 # ...OK
2023-03-17 18:55:10,575 # testing setting second output and clearing first with write
2023-03-17 18:55:10,576 # ...OK
2023-03-17 18:55:10,580 # All input/output operations worked as expected
2023-03-17 18:55:10,580 #
2023-03-17 18:55:10,580 #
2023-03-17 18:55:10,582 # TEST SUCCEEDED
2023-03-17 18:55:10,588 # { "threads": [{ "name": "main", "stack_size": 1536, "stack_used": 456 }]}
```
</details>
<details><summary><code>make -C tests/bench_periph_gpio_ll BOARD=nucleo-f103rb flash term</code></summary>
```
2023-03-17 18:55:42,192 # Help: Press s to start test, r to print it is ready
s
2023-03-17 18:55:44,616 # START
2023-03-17 18:55:44,624 # main(): This is RIOT! (Version: 2023.04-devel-683-g9c3812-cpu/stm32/periph/gpio_ll)
2023-03-17 18:55:44,624 #
2023-03-17 18:55:44,626 # Benchmarking GPIO APIs
2023-03-17 18:55:44,628 # ======================
2023-03-17 18:55:44,628 #
2023-03-17 18:55:44,632 # estimating loop overhead for compensation
2023-03-17 18:55:44,635 # -----------------------------------------
2023-03-17 18:55:44,642 # 4168 us for 50000 iterations
2023-03-17 18:55:44,642 #
2023-03-17 18:55:44,647 # periph/gpio: Using 2x gpio_set() and 2x gpio_clear()
2023-03-17 18:55:44,651 # ---------------------------------------------------
2023-03-17 18:55:44,706 # 50000 iterations took 45840 us (50008 us uncompensated)
2023-03-17 18:55:44,713 # Two square waves pins at 1090750 Hz ( 999840 Hz uncompensated)
2023-03-17 18:55:44,719 # ~66 CPU cycles per square wave period (~72 cycles uncompensated)
2023-03-17 18:55:44,719 # :'-(
2023-03-17 18:55:44,719 #
2023-03-17 18:55:44,724 # periph/gpio_ll: Using gpio_ll_set() and gpio_ll_clear()
2023-03-17 18:55:44,729 # -------------------------------------------------------
2023-03-17 18:55:44,738 # 50000 iterations took 695 us (4863 us uncompensated)
2023-03-17 18:55:44,745 # Two square waves pins at 71942446 Hz ( 10281719 Hz uncompensated)
2023-03-17 18:55:44,750 # ~1 CPU cycles per square wave period (~7 cycles uncompensated)
2023-03-17 18:55:44,751 # :-D
2023-03-17 18:55:44,751 #
2023-03-17 18:55:44,755 # periph/gpio: Using 4x gpio_toggle()
2023-03-17 18:55:44,757 # -----------------------------------
2023-03-17 18:55:44,965 # 50000 iterations took 198646 us (202814 us uncompensated)
2023-03-17 18:55:44,972 # Two square waves pins at 251704 Hz ( 246531 Hz uncompensated)
2023-03-17 18:55:44,977 # ~286 CPU cycles per square wave period (~292 cycles uncompensated)
2023-03-17 18:55:44,978 # :'-(
2023-03-17 18:55:44,978 #
2023-03-17 18:55:44,982 # periph/gpio_ll: Using 2x gpio_ll_toggle()
2023-03-17 18:55:44,985 # -----------------------------------------
2023-03-17 18:55:45,010 # 50000 iterations took 15972 us (20140 us uncompensated)
2023-03-17 18:55:45,017 # Two square waves pins at 3130478 Hz ( 2482621 Hz uncompensated)
2023-03-17 18:55:45,023 # ~23 CPU cycles per square wave period (~29 cycles uncompensated)
2023-03-17 18:55:45,023 # :'-(
2023-03-17 18:55:45,023 #
2023-03-17 18:55:45,026 # periph/gpio: Using 4x gpio_write()
2023-03-17 18:55:45,029 # ----------------------------------
2023-03-17 18:55:45,097 # 50000 iterations took 58345 us (62513 us uncompensated)
2023-03-17 18:55:45,103 # Two square waves pins at 856971 Hz ( 799833 Hz uncompensated)
2023-03-17 18:55:45,109 # ~84 CPU cycles per square wave period (~90 cycles uncompensated)
2023-03-17 18:55:45,109 # :'-(
2023-03-17 18:55:45,110 #
2023-03-17 18:55:45,113 # periph/gpio_ll: Using 2x gpio_ll_write()
2023-03-17 18:55:45,117 # ----------------------------------------
2023-03-17 18:55:45,128 # 50000 iterations took 2777 us (6945 us uncompensated)
2023-03-17 18:55:45,135 # Two square waves pins at 18005041 Hz ( 7199424 Hz uncompensated)
2023-03-17 18:55:45,141 # ~4 CPU cycles per square wave period (~10 cycles uncompensated)
2023-03-17 18:55:45,141 # :-)
2023-03-17 18:55:45,141 #
2023-03-17 18:55:45,141 #
2023-03-17 18:55:45,142 # TEST SUCCEEDED
2023-03-17 18:55:45,149 # { "threads": [{ "name": "main", "stack_size": 1536, "stack_used": 448 }]}
```
</details>
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Use a custom expect() that just spins in an endless loop instead of
panicking. The test isn't run automatically anyway, as it requires
connecting two GPIOs with jumper wires; but when run manually it is
helpful to not kill RIOT to also get the stdio output of the exact
point where the test fails (e.g. USB CDC ACM doesn't like panic()).
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>
