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>
19893: pkg/tinyusb: add missing include r=gschorcht a=Enoch247
### Contribution description
The macro `AUTO_INIT_PRIO_MOD_TINYUSB` was being used, but not defined. This patch includes the header where `AUTO_INIT_PRIO_MOD_TINYUSB` is defined to fix the compiler error.
### Testing procedure
Run any build with `auto_init` and `stdio_tinyusb_cdc_acm` modules active and see that build fails without patch and succeeds with the patch.
### Issues/PRs references
- none known
Co-authored-by: Joshua DeWeese <jdeweese@primecontrols.com>
19876: sys/net/ipv4/addr: fix typos r=benpicco a=Enoch247
### Contribution description
This patch fixes some typos in the doxygen doc.
### Testing procedure
Nothing to test. No change to code.
### Issues/PRs references
- None known
19878: makefiles/usb_board_reset.mk: declare term-delay target with test target r=benpicco a=aabadie
19888: boards/sltb009a: complete and fix documentation r=benpicco a=gschorcht
### Contribution description
This PR completes and fixes the documentation which was still in the state as generated automatically by `efm2riot`.
The PR also includes a fix of the configuration of the second UART device that was find out while completing the documentation.
### Testing procedure
Green CI
### Issues/PRs references
Co-authored-by: Joshua DeWeese <jdeweese@primecontrols.com>
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
The macro `AUTO_INIT_PRIO_MOD_TINYUSB` was being used, but not defined.
This patch includes the header where `AUTO_INIT_PRIO_MOD_TINYUSB` is
defined to fix the compiler error.
There are new pseudomodules for this driver:
- atwinc15x0_static_connect: Should behave as before, by trying to connect to an AP
by specified WIFI_SSIS and WIFI_PASS
- atwinc15x0_dynamic_connect: takes connection request via NETOPT_CONNECT
and provides the connection result via callback
- atwinc15x0_dynamic_scan: takes network scan requests via NETOPT_SCAN
and provides the scan result as a sorted list via callback
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.
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>
19824: boards/sipeed_longan_nano: separate board definition for Sipeed Longan Nano TFT r=benpicco a=gschorcht
### Contribution description
This PR provides a minimal separate board definition for the Sipeed Longan Nano version with TFT display which is just an extension of `boards/sipeed-longan-nano` with enabled TFT display module.
From the lessons we had to learn with the Kconfig modelling of optional hardware, the TFT version of the Sipeed Longan Nano board has been split off into its own board definition based on the existing Siepeed Longan Nano board.
Commits ba29a5eefad6f24106d51bf4fbd0d1407bc7b816, 237819eac894399e423f24ffd9b79b48af1cf25c, 6d8b56dcd426580ddbbbecd003ece54d46cee05c and c5faf349d63aef28b3aa3cfce8250229b6622a15 are small cleanups of peripheral configurations and could be split from this PR as follow-up PR (changes +70 -36).
### Testing procedure
Green CI
```
BOARD=sipeed-longan-nano-tft make -j8 -C tests/drivers/st77xx flash
```
should work
### Issues/PRs references
Follow up to PR #19813 and PR #19814
Prerequisite for PR #19825 and PR #19827
19855: gnrc_static: fix static PID assignment r=benpicco a=benpicco
19862: cpu/riscv_common: remove picolibc from blacklisting in CI r=benpicco a=gschorcht
### Contribution description
`picolibc` is now supported by the RISC-V toolchain in `riotdocker`. It is not necessary to blacklist it in CI any longer.
Reference: `picolib` was blacklisted by commit 45270dada0 in PR #15011.
### Testing procedure
1. Green CI
2. Check feature list for CI compilation:
```
BUILD_IN_DOCKER=1 RIOT_CI_BUILD=1 FEATURES_OPTIONAL=picolibc \
BOARD=sipeed-longan-nano make -j8 -C tests/sys/shell info-modules | grep picolib
picolibc
picolibc_stdout_buffered
picolibc_syscalls_default
```
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
After cleaning up the default config of SPI, this commit cleans up the configuration for `sipeed-longan-nano` a bit:
- PA4 is no longer used as default CS for `SPI_DEV(1)`
- At least one DAC channel PA4 is always available if DAC is used.
- PA4 is always available as ADC channel if DAC is not used.
- The order of ADC and DAC channels has been changed accordingly.
