19343: ztimer: add ztimer_stopwatch convenience functions r=benpicco a=benpicco
19349: cpu/native: Switch to ztimer for gettimeofday r=benpicco a=MrKevinWeiss
### Contribution description
A xtimer is somewhat taken over by ztimer this explicitly uses ztimer instead of relying on the compatibility layer.
### Testing procedure
`make all test -C tests/cpp11_mutex/`
and green murdock I guess.
### Issues/PRs references
19353: doc: add quicklink to boards in navbar r=benpicco a=OlegHahm
### Contribution description
Finding a list of supported boards and how to use them is an essential information. Currently this list is somewhat hidden under "Modules" which is not very intuitive. Hence, I propose to (at least) put a link in the side menu to this overview page.
### Testing procedure
1. Call `make doc`
2. Check the sidebar `${RIOT_BASE}/doc/doxygen/html/index.html` for an entry "Supported Boards"
19361: nanocoap_sock: ensure response address is the same as request address r=benpicco a=benpicco
19363: Fix stm32 timer periodic r=benpicco a=Enoch247
### Contribution description
From the commit msg:
> cpu/stm32/periph/timer: remove unneeded header
>
> I see no reason this header should be included. It does not exist in
> RIOT's source tree. This patch removes the include.
and
> cpu/stm32/periph/timer: fix execution flow
>
> The implmentation of `timer_set_absolute()` has The following problems.
> First, it attempts to restore the auto reload register (ARR) to it's
> default if the ARR was previosly set by `timer_set_periodic()` by
> comparing it to the channel's capture compare (CC) register _after_ it
> has already set the CC register. Secondly, it clears spurious IRQs
> _after_ the CC register has been set. If the value being set is equal to
> the timer's current count (or the two become equal before the supurios
> IRQ clearing happens), this could cause a legitimate IRQ to be cleared.
>
> The implmentation of `timer_set()` has the same error in handling the
> ARR as described above.
>
> This patch reorders the operations of both functions to do:
>
> 1. handle ARR
> 2. clear spurious IRQs
> 3. set channel's CC
> 4. enable IRQ
>
> Additionally, the calulation of `value` in `timer_set()` is moved
> earlier in the function's exec path as a pedantic measure.
### Testing procedure
I tested by doing the following:
1. `make -C tests/periph_timer BOARD=nucleo-f767zi all flash term`
2. press s
3. press [ENTER]
4. observe test passes
5. `make -C tests/periph_timer_periodic BOARD=nucleo-f767zi all flash term`
6. press s
7. press [ENTER]
8. observe test passes
9. `make -C tests/periph_timer_short_relative_set BOARD=nucleo-f767zi all flash term`
10. press s
11. press [ENTER]
12. observe test passes
### Issues/PRs references
- none known
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
Co-authored-by: Oleg Hahm <oleg@hobbykeller.org>
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Joshua DeWeese <jdeweese@primecontrols.com>
The implmentation of `timer_set_absolute()` has The following problems.
First, it attempts to restore the auto reload register (ARR) to it's
default if the ARR was previosly set by `timer_set_periodic()` by
comparing it to the channel's capture compare (CC) register _after_ it
has already set the CC register. Secondly, it clears spurious IRQs
_after_ the CC register has been set. If the value being set is equal to
the timer's current count (or the two become equal before the supurios
IRQ clearing happens), this could cause a legitimate IRQ to be cleared.
The implmentation of `timer_set()` has the same error in handling the
ARR as described above.
This patch reorders the operations of both functions to do:
1. handle ARR
2. clear spurious IRQs
3. set channel's CC
4. enable IRQ
Additionally, the calulation of `value` in `timer_set()` is moved
earlier in the function's exec path as a pedantic measure.
19341: Picolibc updates r=benpicco a=keith-packard
### Contribution description
Minor updates to picolibc support for newer versions of picolibc, including 1.8.
### Testing procedure
Here's the current build result for a board I happen to have on my bench right now:
```
$ make -C examples/blinky BOARD=nucleo-f103rb FEATURES_REQUIRED=picolibc
...
/home/keithp/src/RIOT/sys/picolibc_syscalls_default/syscalls.c:319:1: error: unknown type name '_READ_WRITE_RETURN_TYPE'
319 | _READ_WRITE_RETURN_TYPE read(int fd, void *dest, size_t count)
| ^~~~~~~~~~~~~~~~~~~~~~~
/home/keithp/src/RIOT/sys/picolibc_syscalls_default/syscalls.c:351:1: error: unknown type name '_READ_WRITE_RETURN_TYPE'
351 | _READ_WRITE_RETURN_TYPE write(int fd, const void *src, size_t count)
| ^~~~~~~~~~~~~~~~~~~~~~~
...
```
### Description of changes
1. Fix the read/write return values (Picolibc 1.8 uses POSIX standard types now)
2. Add new symbols to linker scripts (Picolibc needs help dealing with TLS alignment)
3. Align stack and thread local storage block during thread setup.
19345: cpu/riscv_common: convert to uword_t usage r=benpicco a=dylad
### Contribution description
This PR makes use of `uword_t` type in a few places in `cpu/riscv_common`.
This should not have any effect on produced binaries.
### Testing procedure
CI should be enough.
### Issues/PRs references
Quickly adapt from #16994. It will help for 64 bits support one day ;)
Co-authored-by: Keith Packard <keithp@keithp.com>
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Newer picolibc versions require some additional symbols defined in the
linker script to correctly manage alignment constraints on thread
local storage.
Signed-off-by: Keith Packard <keithp@keithp.com>
19329: MAINTAINING.md: add some notes on Bors r=benpicco a=benpicco
19330: native/stdio: Explicitly provide getchar r=chrysn a=chrysn
### Contribution description
This ensures that even when libc does not implement getchar through getc, any custom stdio is still in the loop when getchar is used.
Frankly, I don't know when this broke -- I'm pretty sure custom stdio worked just a few days ago -- but either way, without this patch RIOT on native currently bypasses a configured stdio for me.
### Testing procedure
* `make -C examples/saul all debug`
* `break stdio_read`
* `run`
Without this patch, observe how the shell runs w/o ever breaking. After, lots of breakpoint hits.
This is the way it behaves for me (Debian sid, libc6:i386 2.36-8). If it works for you before this patch, we might start bisecting the differences between the systems, but we may also accept that libcs may imlpement getchar in different ways, and not all of them pass by the getc which we're patching.
### Issues/PRs references
This is needed for testing #19289.
The implementation stems from the `fgetc(3)` man page, which states that "getchar() is equivalent to getc(stdin)".
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
Co-authored-by: chrysn <chrysn@fsfe.org>
This allows automatically moving format strings to flash, provided that
code previously compiled fine with `-Wformat-nonliteral` (which in RIOT
is the case due to `-Wformat=2`).
This adds a layer of convenience abstraction over classical Harvard
architectures (like most AVRs) that do not map the flash memory into
the data address space and modern Harvard architectures or von-Neumann
architectures that do so. The motivation is to safe a lot of RAM for
AVR by storing constant strings into flash.
19165: cpu/sam0_common: adc: implement 16 bit mode by oversampling r=dylad a=benpicco
19303: dist/tools/insufficient_memory: Minor improvements r=benpicco a=maribu
### Contribution description
`create_makefile.sh`:
- address all shellcheck warnings
- make script POSIX shell compatible
- use nproc to set the number of parallel jobs to increase throughput
- print error messages when building fails
- run `make info-boards-supported` with `EXTERNAL_BOARD_DIRS=""` to avoid adding out-of-tree boards to `Makefile.ci`.
- classify output as "not supported" also when used features are blacklisted, not only when required features are missing
`add_insufficient_memory_board.sh`:
- classify output as "not supported" also when used features are blacklisted, not only when required features are missing
### Testing procedure
Run the script; it should still work.
### Issues/PRs references
None
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
19256: pkg/tinyusb: add GD32VF103 support r=gschorcht a=gschorcht
### Contribution description
This PR provides the tinyUSB support for GD32VF103 and enables the `tinyusb_device` feature as well as `stdio_tinyusb_cdc_acm` for GD32VF103 boards.
### Testing procedure
```
BOARD=sipeeed-longan-nano make -C tests/shell flash term
```
should work
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19269: cpu/gd32v/periph_i2c: interrupt based driver r=gschorcht a=gschorcht
### Contribution description
This PR provides an interrupt-driven version of the I2C low-level driver.
The existing I2C low-level driver for GDVF103 uses a busy-waiting approach where the status register is continuously polled while waiting for a certain status when sending or receiving. The MCU is thus occupied the whole time during a send or receive operation.
The driver provided with this PR uses an interrupt-driven approach. This is, while waiting for a certain status when sending or receiving, the calling thread is suspended and woken up by interrupts.
Since the I2C controller allows to receive up to two bytes before the application has to react, receiving a single byte, two bytes or more than two bytes needs a different handling for correct receiption. This requires a tricky implementation which distinguish a number of different case. There the driver requires 860 byte more ROM and 8 byte more RAM.
### Testing procedure
The driver should work with any I2C sensor/actuator. It was tested with
- `tests/driver_bmp180`
<details>
```
main(): This is RIOT! (Version: 2023.04-devel-355-g940c7-cpu/gd32v/periph_i2c_interrupt_driven)
BMP180 test application
+------------Initializing------------+
Initialization successful
+------------Calibration------------+
AC1: 8448
AC2: -1208
AC3: -14907
AC4: 33310
AC5: 24774
AC6: 19213
B1: 6515
B2: 49
MB: -32768
MC: -11786
MD: 2958
+--------Starting Measurements--------+
Temperature [°C]: 22.0
Pressure [hPa]: 1006.49
Pressure at see level [hPa]: 1025.55
Altitude [m]: 157
+-------------------------------------+
Temperature [°C]: 22.0
Pressure [hPa]: 1006.56
Pressure at see level [hPa]: 1025.58
Altitude [m]: 157
+-------------------------------------+
```
</details>
- `tests/driver_ccs811`
<details>
```
main(): This is RIOT! (Version: 2023.04-devel-355-g940c7-cpu/gd32v/periph_i2c_interrupt_driven)
CCS811 test application
+------------Initializing------------+
+--------Starting Measurements--------+
TVOC [ppb]: 0
eCO2 [ppm]: 0
+-------------------------------------+
TVOC [ppb]: 0
eCO2 [ppm]: 0
+-------------------------------------+
TVOC [ppb]: 0
eCO2 [ppm]: 0
+-------------------------------------+
TVOC [ppb]: 0
eCO2 [ppm]: 400
+-------------------------------------+
TVOC [ppb]: 0
eCO2 [ppm]: 400
+-------------------------------------+
TVOC [ppb]: 0
eCO2 [ppm]: 400
+-------------------------------------+
TVOC [ppb]: 7
eCO2 [ppm]: 446
+-------------------------------------+
TVOC [ppb]: 7
eCO2 [ppm]: 446
+-------------------------------------+
TVOC [ppb]: 7
eCO2 [ppm]: 446
+-------------------------------------+
TVOC [ppb]: 7
eCO2 [ppm]: 446
+-------------------------------------+
```
</details>
- `tests/driver_sht3x`
<details>
```
main(): This is RIOT! (Version: 2023.04-devel-355-g940c7-cpu/gd32v/periph_i2c_interrupt_driven)
SHT3X test application
+------------Initializing------------+
Initialization successful
+--------Starting Measurements--------+
Temperature [°C]: 21.46
Relative Humidity [%]: 54.50
+-------------------------------------+
Temperature [°C]: 21.47
Relative Humidity [%]: 54.53
+-------------------------------------+
Temperature [°C]: 21.46
Relative Humidity [%]: 54.48
+-------------------------------------+
Temperature [°C]: 21.46
Relative Humidity [%]: 54.47
+-------------------------------------+
```
</details>
- `tests/driver_l3gxxxx`
<details>
```
main(): This is RIOT! (Version: 2023.04-devel-375-g75547-cpu/gd32v/periph_i2c_interrupt_driven)
L3GXXXX gyroscope driver test application
Initializing L3GXXXX sensor
[OK]
gyro [dps] x: +0, y: -1, z: -2
gyro [dps] x: +0, y: +0, z: +0
gyro [dps] x: +0, y: +0, z: +0
gyro [dps] x: +0, y: +0, z: +0
gyro [dps] x: +0, y: +0, z: +0
gyro [dps] x: +0, y: +0, z: +0
gyro [dps] x: -1, y: +0, z: +4
gyro [dps] x: +0, y: +0, z: -21
gyro [dps] x: +0, y: +0, z: +6
gyro [dps] x: -43, y: +0, z: -13
gyro [dps] x: -21, y: -2, z: +0
gyro [dps] x: +0, y: +1, z: +3
gyro [dps] x: +25, y: +0, z: +0
```
</details>
- `tests/driver_hd44780` with `pcf8574a` I2C interface
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19284: boards: support for the LILYGO TTGO T8 ESP32-S2 board r=benpicco a=gschorcht
### Contribution description
This PR provides the support for the LILYGO TTGO T8 ESP32-S2 board which has a OLED display (not yet supported) and a SD-Card slot on board.
The board is equipped with a USB-C connector that connects either to a USB-to-UART bridge or to the USB-OTG/JTAG interface of the ESP32-S2 via some DIP switches.
The PR includes a very small fix of printf format string in `tests/malloc`. I can split it off.
### Testing procedure
t.b.d.
### Issues/PRs references
19286: cpu/esp_common: use generic WIFI_SSID/WIFI_PASS defines r=benpicco a=benpicco
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
19270: drivers/at24cxxx: implement _mtd_at24cxxx_read_page r=benpicco a=HendrikVE
### Contribution description
The function `read_page` was missing which lead to (from a user perspective) undefined behavior on the MTD layer.
### Testing procedure
Any application using MTD in conjunction with a board with an at24cxxx.
19271: core/xfa: disable asan on llvm r=benpicco a=Teufelchen1
### Contribution description
Hi! 🦎
When using llvm and address sanitation, the XFA trip the sanitizer.
This PR attempts to fix this by adding the `no_sanitize` attribute to the XFA macros. Sadly, this attribute is not known by gnu, a guard is hence needed. I'm open for alternatives as I dislike this solution but it is the best I could come up with.
### Testing procedure
Before this patch:
Go to `examples/gnrc_minimal` and run `TOOLCHAIN=llvm make all-asan` and then `make term`.
You should see an error similar to this:
```
==3374719==ERROR: AddressSanitizer: global-buffer-overflow on address 0x080774e0 at pc 0x0804af5e bp 0x0808eb88 sp 0x0808eb78
READ of size 4 at 0x080774e0 thread T0
#0 0x804af5d in _auto_init_module /RIOT/sys/auto_init/auto_init.c:40
#1 0x804af5d in auto_init /RIOT/sys/auto_init/auto_init.c:339
#2 0x804b375 in main_trampoline /RIOT/core/lib/init.c:56
#3 0xf76bc7b8 in makecontext (/lib32/libc.so.6+0x4a7b8)
...
```
After applying this PR, the example can be build and run with llvm or gcc, with or without asan.
Co-authored-by: Hendrik van Essen <hendrik.vanessen@ml-pa.com>
Co-authored-by: Teufelchen1 <bennet.blischke@haw-hamburg.de>
19263: cpu/stm32/periph/timer: don't stop counter r=maribu a=Enoch247
### Contribution description
From the git comment msg:
If a timer's channel was set with a really small realtive duration from now, such that it would be missed (underflowed), the driver would stop the timer, potentially causing missed ticks. It was stopped to ensure that the channel's output-compare register could be set to the current counter value, before re-enabling the timer's counter. This is a condition that will ensure that the underflow won't happen again and the interrupt will fire, at the cost of losing some ticks for very high speed clocks.
This patch replaces the logic that stopped the timer. Instead it uses a register provided by the timer hardware to trigger timer interrupts via software.
### Testing procedure
1. do
``` bash
$ cd tests/periph_timer_short_relative_set
$ make BOARD=nucleo-f303ze flash term
```
1. follow prompts to run test
1. observe all tests pass
1. apply patch below to break test
1. rerun test
1. observe test fails, so new method is doing its job
##### patch to intentionally break test
```` diff
diff --git a/cpu/stm32/periph/timer.c b/cpu/stm32/periph/timer.c
index 64a6f3a656..7078c46ab4 100644
--- a/cpu/stm32/periph/timer.c
+++ b/cpu/stm32/periph/timer.c
`@@` -177,7 +177,7 `@@` int timer_set(tim_t tim, int channel, unsigned int timeout)
if (value > timeout) {
/* time till timeout is larger than requested --> timer already expired
* ==> let's make sure we have an IRQ pending :) */
- dev(tim)->EGR |= (TIM_EGR_CC1G << channel);
+ //dev(tim)->EGR |= (TIM_EGR_CC1G << channel);
}
````
### Issues/PRs references
- none known
Co-authored-by: Joshua DeWeese <jdeweese@primecontrols.com>
If a timer's channel was set with a really small realtive duration from
now, such that it would be missed (underflowed), the driver would stop
the timer, potentially causing missed ticks. It was stopped to ensure
that the channel's output-compare register could be set to the current
counter value, before re-enabling the timer's counter. This is a
condition that will ensure that the underflow won't happen again and the
interrupt will fire, at the cost of losing some ticks for very high
speed clocks.
This patch replaces the logic that stopped the timer. Instead it uses a
register provided by the timer hardware to trigger timer interrupts via
software.
17045: sys/coding: add XOR based coding module r=benpicco a=benpicco
19243: cpu/gd32v: add periph_gpio_ll and periph_gpio_ll_irq support r=benpicco a=gschorcht
### Contribution description
This PR provides the `periph_gpio_ll` and `periph_gpio_ll_irq` support for GD32VF103. Level triggered interrupts are emulated.
`periph_gpio_ll_irq` could be split off from this PR as a separate PR if necessary.
### Testing procedure
Use any GD32V board and connect PA0 -> PB0 and PA1 -> PB1 where PA is the output port and PB the input port. With these connections `tests/periph_gpio_ll` should work.
```
BOARD=sipeed-longan-nano make -j8 -C tests/periph_gpio_ll flash term
```
If necessary, change the input and output pins by setting the environment variables and connect the corresponding pins, for example for `seeedstudio-gd32` PA1 -> PB8 and PA8 -> PB9:
```
PIN_OUT_0=1 PIN_OUT_1=8 PIN_IN_0=8 PIN_IN_1=9 BOARD=seedstudio-gd32 make -j8 -C tests/periph_gpio_ll flash term
```
### Issues/PRs references
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19240: tools/doccheck: add simple exclude to doccheck r=benpicco a=kfessel
while doccheck runs for #19228 and #19220, i saw some spikes in memory consumption, turned out that was `grep -Evf dist/tools/doccheck/exclude_patterns` using about 2GB RAM. This PR changes that.
### Contribution description
add `exclude_simple` to `doccheck` drived from `exclude patterns`
`sort`ed and `uniq`ued the simple excludes
removes no longer needed patterns from `exclude patterns`
simple excludes are string rules (no patterns just strings)
how to apply these:
in this PR:
*remove the path and line number from the rule
* that made some of them doubles of each other
* sorted and uniqued them.
* this set of excludes is no longer path specific (an exception covers all paths but may of them still contain a file name)
another possible solution would be to have the excludes line number specific.
### Testing procedure
run `dist/tools/doccheck/check.sh`
compare memory consumption of
master: `grep -Evf dist/tools/doccheck/exclude_patterns`
to
this PR: `grep -Fvf dist/tools/doccheck/exclude_simple`
### Issues/PRs references
19248: cpu/gd32v: add periph_dac support r=benpicco a=gschorcht
### Contribution description
This PR provides the `periph_dac` support for GD32VF103.
### Testing procedure
`tests/periph_dac` should work on `sipeed-longan-nano` port on PA4 and PA5.
### Issues/PRs references
19255: boards/esp*: complete SD Card MTD config r=benpicco a=gschorcht
### Contribution description
This PR provides the remaining changes necessary to use the generic MTD SD Card configuration as described in PR #19216.
This includes defining the MTD offset for SD cards, since the default `MTD_0` device always uses the internal flash device, and the completion of the configuration for the ESP32 boards with a SD card interface.
### Testing procedure
`tests/vfs_default` should work now with SD Cards:
```
main(): This is RIOT! (Version: 2023.04-devel-323-gfcc07)
mount points:
/nvm0
/sd0
data dir: /sd0
> vfs df
Mountpoint Total Used Available Use%
/nvm0 3052 KiB 8 KiB 3044 KiB 0%
/sd0 7580 MiB 3632148992 B 21089792 B 99%
```
### Issues/PRs references
Co-authored-by: Karl Fessel <karl.fessel@ovgu.de>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19251: tests/driver_dac_dds: fix output of sine and saw functions r=benpicco a=benpicco
19254: cpu/gd32v: add periph_rtc_mem support r=benpicco a=gschorcht
### Contribution description
This PR provides the `periph_rtc_mem` support for GD32VF103.
A modified version of this driver could also be used for STM32F1.
### Testing procedure
`tests/periph_rtt` should work on any GD32V board, for example:
```
BOARD=sipeed-longan-nano make -C tests/periph_rtt flash
```
```
Help: Press s to start test, r to print it is ready
START
main(): This is RIOT! (Version: 2023.04-devel-319-gebc86-cpu/gd32v/periph_rtc_mem)
RIOT RTT low-level driver test
RTT configuration:
RTT_MAX_VALUE: 0xffffffff
RTT_FREQUENCY: 32768
Testing the tick conversion
Trying to convert 1 to seconds and back
Trying to convert 256 to seconds and back
Trying to convert 65536 to seconds and back
Trying to convert 16777216 to seconds and back
Trying to convert 2147483648 to seconds and back
All ok
Initializing the RTT driver
RTC mem OK
This test will now display 'Hello' every 5 seconds
RTT now: 1
Setting initial alarm to now + 5 s (163841)
rtt_get_alarm() PASSED
RTC mem OK
```
### Issues/PRs references
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
This file contains the definitions for the DWC2 USB OTG FS IP Core from Synopsys as also defined in the CMSIS Device Peripheral Access Layer for each STM32 MCU and in the same way for ESP32x SoCs. GD32V MCUs use the same USB IP Core, but the vendor headers for these MCUs use a different register structure and different identifiers. To be able to use the same driver `usbdev_synopsys_dwc2`, the relevant USB IP core definitions have been extracted from `cmsis/f7/Include/stm32f767xx.h` which is under the copyright of STMicroelectronics, see below. This is the same file used by ESP32x SoCs but modified for GD32V MCUs.
19249: boards/gd32v: improve board definitions r=benpicco a=gschorcht
### Contribution description
This PR provides some small improvements of the existing board definitions for GD32VF103 boards for more flexibel default configurations and documentation of the board peripherals:
- Allow the remapping of SPI0 pins in SPI configuration (ae984b0bea)
- More flexible I2C configuration (0c337583b4)
The default I2C device configuration allows to define up to two I2C devices `I2C_DEV(0)` and `I2C_DEV(1)`. `I2C_DEV(0)` is always defined if the I2C peripheral is enabled by the module `periph_spi`. The second I2C device `I2C_DEV(1)` is only defined if `I2C_DEV_1_USED` is defined by the board. This allows to use the default configuration with one or two I2C devices depending on whether other peripherals are enabled that would collide with the I2C devices.
- More flexible SPI configuration (edbf59e37e)
The default SPI device configuration allows to define up to two SPI devices `SPI_DEV(0)` and `SPI_DEV(1)`. `SPI_DEV(0)` is always defined if the SPI peripheral is enabled by the module `periph_spi`. The second SPI device `SPI_DEV(1)` is only defined if `SPI_DEV_1_USED` is defined by the board. This allows to use the default configuration with one or two SPI devices depending on whether other peripherals are enabled that would collide with the SPI devices.
Furthermore, the CS signal in the SPI configuration is given by a define that can be overriden with another pin if
the default CS signal is connected to an unused hardware.
- Improve ADC config for Sipeed-Longan-Nano (c9c587ee00)
The ADC configuration was too complex. It was hard to follow when certain ADC lines are available. Furthermore, the order of ADC lines did depend on the use of other peripherals. Now, either the TFT display is not connected and all ADC lines are available or the TFT display is connected and the second SPI device is used so that only the first 4 ADC lines are available.
- Improve Kconfig for Sipeed-Longan-Nano (025f4fdf00)
Board-specific configuration not shown any longer directly in the top level menu but within a submenu.
- Improve peripherals documentation (7f0d560dd8, e24abe495a)
Available peripherals for the board are now documented in two tables ordered by RIOT peripheral names and by pins.
Although the different changes are small and mostly related to the documentation, I could split the PR if necessary.
### Testing
Green CI
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
18863: boards/esp32s2-mini: add definition for ESP32 S2 Mini r=gschorcht a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
16782: drivers/mfrc522: add new driver r=benpicco a=HendrikVE
### Contribution description
This PR adds support for the MFRC522. It is quite common in the Arduino world and it is quite cheap. The driver connects to the MFRC522 via SPI and is heavily based on the Arduino driver available [here](https://github.com/miguelbalboa/rfid). Basically it was ported, but with several improvements in readability and documentation.
### Testing procedure
The given (manual) test provides single commands for some driver functions.
19201: cpu/gd32v: add periph_i2c support r=benpicco a=gschorcht
### Contribution description
This PR provides the `periph_i2c` support and is one of a bunch of PRs that complete the peripheral drivers for GD32VF103.
The driver is a modified version of the driver for STM32F1 with some changes that were necessary to get it working on GD32V. As for STM32F1, the driver is using polling instead of interrupts for now. It will be implemented interrupt-driven later.
### Testing procedure
`tests/periph_i2c` as well as a test with any I2C sensor should work. The driver was tested with `tests/driver_l3gxxxx` and `tests/driver_bmp180`.
### Issues/PRs references
Co-authored-by: Hendrik van Essen <hendrik.ve@fu-berlin.de>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
When a timer is set, any pending interrupts must be cleared before the interrupt is enabled for the channel. Otherwise the interrupt would be triggered immediately when the timer is set.
19192: cpu/esp32: fixes for boot issues and crashes on ESP32 r=kaspar030 a=Flole998
### Contribution description
In syscalls_init() there is a call to malloc(), which will return NULL if the heap is not initialized before, causing the entire board to fail booting if MODULE_ESP_IDF_HEAP is used.
API of [vTaskDelete()](https://www.freertos.org/a00126.html) says, that if NULL is passed to vTaskDelete the calling task should be deleted.
This PR needs a backport to 2023.01.
### Testing procedure
Just compiling on the ESP32S2 and running it with WiFi caused it to not start anymore, no output, nothing. When Null is written to that null-pointer it hangs.
The second commit fixed an issue/assertion fail that happens when the WiFi connection drops/disconnects.
### Issues/PRs references
Issue was introduced with PR #19146
Co-authored-by: Flole998 <Flole998@users.noreply.github.com>
In syscalls_init() there is a call to malloc(), which will return NULL if the heap is not initialized before, causing the entire board to fail booting if MODULE_ESP_IDF_HEAP is used.
19185: cpu/gd32v: add periph_gpio_irq support r=gschorcht a=gschorcht
### Contribution description
This PR provides the `periph_gpio_irq` support and is one of a bunch of follow up PRs that complete the peripheral drivers for GD32VF103.
### Testing procedure
Use a GD32VF103 board and flash `tests/periph_gpio`. Note: The Sipeed Longan Nano works also with `seeedstudio-gd32` board defintion and could be used for testing.
```
BOARD=seeedstudio-gd32 make -C tests/periph_gpio flash (until PR #19170 is merged only `seeedstudio
```
With the GPIO PB8 and PB9 connected, the following test sequence should work:
```
> init_out 1 8
> init_int 1 9 2 0
GPIO_PIN(1, 9) successfully initialized as ext int
> set 1 8
INT: external interrupt from pin 9
> clear 1 8
INT: external interrupt from pin 9
```
### Issues/PRs references
19187: cpu/gd32v: add pm_layered support in periph_pm r=gschorcht a=gschorcht
### Contribution description
This PR provides the `pm_layered` support and is one of a bunch of follow up PRs that complete the peripheral drivers for GD32VF103.
Since the configuration of the deep sleep and the standby mode require the access CSR (control and status registers) of the MCU, the Nuclei-SDK NMSIS is added as package which provides a low-level interface for Nuclei-based RISC-V MCUs.
### Testing procedure
The best way to test it is to rebase this PR onto PR #19186 and to flash `tests/periph_pm` to any GD32VF103 board. Note: The Sipeed Longan Nano works also with `seeedstudio-gd32` board definition and could be used for testing.
```
BOARD=seeedstudio-gd32 make -C tests/periph_pm flash
```
The test output should be:
```
main(): This is RIOT! (Version: 2023.04-devel-174-g7dc91-cpu/gd32v/periph_pm_test)
...
mode 0 blockers: 1
mode 1 blockers: 2
mode 2 blockers: 0
Lowest allowed mode: 2
```
Using command the `set_rtc 1 5` command should let the MCU deep sleep for 5 seconds
```
> set_rtc 1 5
Setting power mode 1 for 5 seconds.
␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀>
```
while command `set_rtc 1 5` should set the MCU into the standby mode which is left with restart.
```
> set_rtc 0 5
Setting power mode 0 for 5 seconds.
main(): This is RIOT! (Version: 2023.04-devel-174-g7dc91-cpu/gd32v/periph_pm_test)
...
mode 0 blockers: 1
mode 1 blockers: 2
mode 2 blockers: 0
Lowest allowed mode: 2
>
```
The garbage on UART interface after deep sleep is caused by the clock synchronisation that becomes necessary after deep sleep and is the same as for other boards.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
18472: drivers/mrf24j40: add support for IEEE 802.15.4 Radio HAL r=benpicco a=jia200x
19175: drivers/periph_common/flashpage: fix silent error r=benpicco a=Enoch247
### Contribution description
This patch removes a test that silently hides failed writes to NULL. Instead, assert is used to ensure that the address is not NULL.
### Testing procedure
I am not certain how to update the tests to catch asserts. If this is possible, I will add a test, if someone will point me to a good example to learn from.
### Issues/PRs references
- none
Co-authored-by: Jose Alamos <jose@alamos.cc>
Co-authored-by: Joshua DeWeese <jdeweese@primecontrols.com>
19079: cpu/esp32: add periph_flashpage support r=kaspar030 a=gschorcht
### Contribution description
This PR provides the `periph_flashpage` support for ESP32x SoCs.
For byte-aligned read access to constant data in the flash, the MMU of all ESP32x SoCs allows to map a certain number of 64 kByte pages of the flash into the data address space of the CPU. This address space is called DROM. Normally the whole DROM address space is assigned to the section `.rodata`. The default flash layout used by all ESP32x SoCs is:
| Address in Flash | Content |
|:-----------------------|:-----------|
| `0x0000` or `0x1000` | bootloader |
| `0x8000` | parition table |
| `0x9000` | `nvs` parition with WiFi data |
| `0xf000` | `phy_init` partition with RF data |
| `0x10000` | `factory` partition with the app image |
The factory partition consists of a number of 64 kByte pages for the sections `.text`, `.rodata`, `.bss` and others. The `.text` and `rodata` sections are page-aligned and are simply mapped into the instruction address space (IROM) and the data address space (DROM), respectively. All other sections are loaded into RAM.
If the `periph_flashpage` module is used, the `periph_flashpage` driver
- decreases the size of the `.rodata` section in DROM address space by `CONFIG_ESP_FLASHPAGE_CAPACITY`,
- adds a section `.flashpage.writable` of size `CONFIG_ESP_FLASHPAGE_CAPACITY` at the end of DROM address space that is mapped into data address space of the CPU,
- reserves a region of size `CONFIG_ESP_FLASHPAGE_CAPACITY` starting from `0x10000` in front of the image partition `factory` and
- moves the image partition `factory` by `CONFIG_ESP_FLASHPAGE_CAPACITY` to address `0x10000 + CONFIG_ESP_FLASHPAGE_CAPACITY`.
The new flash layout is then:
| Address in Flash | Content |
|:-----------------------|:-----------|
| `0x0000` or `0x1000` | bootloader |
| `0x8000` | parition table |
| `0x9000` | `nvs` parition with WiFi data |
| `0xf000` | `phy_init` partition with RF data |
| `0x10000` | flashpage region |
| `0x10000 + CONFIG_ESP_FLASHPAGE_CAPACITY` | `factory` partition with the app image |
This guarantees that the flash pages are not overwritten if a new app image with changed size is flashed. `CONFIG_ESP_FLASHPAGE_CAPACITY` has to be a multiple of 64 kBytes.
~The PR includes PR #19077 and PR #19078 for the moment to be compilable.~
### Testing procedure
The following tests should pass.
```
USEMODULE='esp_log_startup ps shell_cmds_default' BOARD=esp32-wroom-32 make -j8 -C tests/periph_flashpage flash term
```
```
USEMODULE='esp_log_startup ps shell_cmds_default' BOARD=esp32-wroom-32 make -j8 -C tests/mtd_flashpage flash term
```
### Issues/PRs references
Depends on PR #19077
Depends on PR #19078
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19010: bootloaders/riotboot: add tinyUSB DFU support r=benpicco a=gschorcht
### Contribution description
This PR provides
- the tinyUSB DFU and DFU Runtime support and
- the `riotboot_tinyusb_dfu` bootloader that uses the tinyUSB DFU mode to flash new application images.
~This PR includes PR #18983 for now to be compilable.~
### Testing procedure
1. Use any board that supports the `riotboot´ and `tinyusb_device` features and flash the bootloader first, for example
```
BOARD=nucleo-f767zi make -C bootloaders/riotboot_tinyusb_dfu flash
```
and check that the `riotboot_tinyusb_dfu` bootloader is in DFU mode:
```
dfu-util --list
```
3. Flash a first application using the following command:
```
FEATURES_REQUIRED=riotboot USEMODULE=tinyusb_dfu BOARD=nucleo-f767zi \
make -C tests/saul PROGRAMMER=dfu-util riotboot/flash-slot0
```
and check that the application starts and is seen as upgradable:
```
dfu-util --list
```
4. Restart the node in bootloader DFU mode by:
```
dfu-util -e
```
Flash a second application, for example
```
FEATURES_REQUIRED=riotboot USEMODULE=tinyusb_dfu BOARD=nucleo-f767zi \
make -C tests/shell PROGRAMMER=dfu-util riotboot/flash-slot1
```
and check that the second application starts and is seen as upgradable:
```
dfu-util --list
```
### Issues/PRs references
~Depends on PR #18983~
19149: SECURITY: Describe that declassification is an option r=benpicco a=chrysn
### Contribution description
Our security policy does not contain provisions for the case when what is reported is not what we consider an actual security issue. As it is described now, everything reported through security@ would go through the full treatment, including a point release.
I'm not sure it belongs into the text itself (as it's more about how security reporters interact with the project than internals), but declassification should IMO be backed at least by 3 maintainers, and no strong NACK.
### Issues/PRs references
#19141 followed that procedure after some chat on it on the maintainers channel. (In the discussion, I proposed declassification, with 2.5 people supporting it and one "I was about to, but can we be sure nobody is using it?" voice).
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: chrysn <chrysn@fsfe.org>
18763: sys/tiny_strerror: add missing error codes r=benpicco a=maribu
### Contribution description
When double-checking the error codes provided by newlib by default (without magic defines, such as `__LINUX_ERRNO_EXTENSIONS__` or `__CYGWIN__`), some where still missing in `tiny_strerror()`. This adds the missing ones.
This in turn showed that three errno codes were missing in the avr-libc compat `errno.h`, which are added as well.
### Testing procedure
Murdock should double check that the added errno codes indeed are defined by default.
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
To avoid garbage on reconfiguring the UART console pins, e.g. in initialization of the `arduino` module, pins that are already configured as UART pins must not be initialized.
The TX line is set and temporarily configured as a pull-up open-drain output before configuring it as a push-pull output to avoid a several msec long LOW pulse resulting in some garbage.
Since PR #19100 it is possible to define:
- other pins for `UART_DEV(0)` than the default pins
- different `UART_DEV(0)` pins for the bootloader and RIOT
To allow correct reinitialization of the UART pins used by the bootloader as well as their usage for other purposes, the pin usage for the default UART0 pins and the UART pins used by the bootloader are reset to `_GPIO`. This is done in `uart_system_init` which has to be called earlier in the startup procedure.
If LOG_LEVEL >= 4, such as in `tests/log_printfnoformat`, the ESP-IDF config function called for the GPIO pins of the UART will output the configuration with `printf` before the `_GLOBAL_REENT` structure is initialized. This causes a crash during system startup. Therefore the initialization by `syscalls_init` must be called earlier in the startup procedure.
19050: boards/common/cc26xx cc13xx: clean up and fix flash configs r=benpicco a=maribu
### Contribution description
- Add support for XDS110 debugger via `OPENOCD_DEBUG_ADAPTER=xds110`
- Clean up OpenOCD configs in `boards/common/cc26xx_cc13xx`
- No longer hardcode the debugger to xds110, but use `OPENOCD_DEBUG_ADATER ?= xds110`
- Add support for cc13x0, cc13x2, cc26x0
- `boards/cc2650*`: drop custom OpenOCD config in favor of shared one
- add variables needed to support flashing with `PROGRAMMER=jlink`
- allow specifying a custom OpenOCD command to bring the device to a halt state, as the default `reset halt` (which causes a second reset) is causing issues with the ICEPick JTAG routers in the CC26xx - CC13xx devices
- Use `halt` instead of `reset halt` for CC26xx / CC13xx boards in OpenOCD to avoid issues in flashing
### Testing procedure
```
make BOARD=cc2650-launchpad -C examples/default flash
```
Should now work. The same should still work for other cc26xx cc13xx boards.
### Issues/PRs references
Partially fixes: https://github.com/RIOT-OS/RIOT/issues/18750
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
19109: cpu/gd32v: fix and extend Kconfig clock settings r=benpicco a=gschorcht
### Contribution description
This PR fixes the following issus of the clock configuration which led to highly deviating peripheral clocks so that the UART interface was not usable in my case:
1. Setting the `RCU_CTL` register just to the IRC8M bit also removes the IRC8M calibration and trim adjust value in this register. Therefore IRC8M calibration and trim adjust value have to be preserved and the IRC8M has to be set.
2. `CLOCK_HXTAL` is a value and not a flag, so that shifting to the left changes anything in the register but does not set the PLLSEL bit. `RCU_CFG0_PLLSEL_Msk` has to be used instead to set the PLLSEL bit.
3. `CONFIG_BOARD_HAS_HXTAL` is used to indicate that the board has an HXTAL connected. If the HXTAL is present, it is used as PLL clock source. But if the HXTAL is not present, the half IRC8M clock should be used as PLL clock source and must not be disabled at the end of clock settings. Using IRC8M clock as PLL clock source also requires another PLL multiplication factor.
Issues 1 and 2 led to the problem that IRC8M was used without calibration instead of HXTAL. With the fixes, the GD32V is working with as well as without HXTAL correctly.
Furthermore, the Kconfig configuration has been extended. It is now possible to configure the HXTAL frequency as well, since the GD32VF103 allows HXTAL clocks from 3 MHz to 25 MHz. This has currently been added directly to the board's Kconfig, as it is currently the only GD32VF103 board. It should be moved to a common Kconfig later when more GD32V boards are added.
### Testing procedure
`BOARD=seeedstudio-gd32 make -C tests/shell flash term` should still work.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
The configuration whether a HXTAL is present and what its clock frequency is will be added to Kconfig. Since it is the only GD32V board at the moment, the configuration is added to the Kconfig of the board, but should be moved to a common Kconfig later when more GD32V boards are added.
`CONFIG_BOARD_HAS_HXTAL` is used to indicate that the board has an HXTAL connected. If the HXTAL is present, it is used as PLL clock source. But if the HXTAL is not present, the half IRC8M clock should be used as PLL clock source and must not be disabled at the end of clock settings. Using IRC8M clock as PLL clock source also requires another PLL multiplication factor.
`CLOCK_HXTAL` is a value and not a flag, so that shifting to the left changes anything in the register but does not set the PLLSEL bit. `RCU_CFG0_PLLSEL_Msk` has to be used instead to set the PLLSEL bit.