It turns out that the legacy GPIO API and GPIO LL may disagree on what
the GPIO base address is: GPIO LL will use the IOBUS as base address
no matter what, the legacy GPIO API will use the APB as base address
unless `periph_gpio_fast_read` is used.
If the APIs disagree, we need to do impedance matching.
The API was based on the assumption that GPIO ports are mapped in memory
sanely, so that a `GPIO_PORT(num)` macro would work allow for constant
folding when `num` is known and still be efficient when it is not.
Some MCUs, however, will need a look up tables to efficiently translate
GPIO port numbers to the port's base address. This will prevent the use
of such a `GPIO_PORT(num)` macro in constant initializers.
As a result, we rather provide `GPIO_PORT_0`, `GPIO_PORT_1`, etc. macros
for each GPIO port present (regardless of MCU naming scheme), as well as
`GPIO_PORT_A`, `GPIO_PORT_B`, etc. macros if (and only if) the MCU port
naming scheme uses letters rather than numbers.
These can be defined as macros to the peripheral base address even when
those are randomly mapped into the address space. In addition, a C
function `gpio_port()` replaces the role of the `GPIO_PORT()` and
`gpio_port_num()` the `GPIO_PORT_NUM()` macro. Those functions will
still be implemented as efficient as possible and will allow constant
folding where it was formerly possible. Hence, there is no downside for
MCUs with sane peripheral memory mapping, but it is highly beneficial
for the crazy ones.
There are also two benefits for the non-crazy MCUs:
1. We can now test for valid port numbers with `#ifdef GPIO_PORT_<NUM>`
- This directly benefits the test in `tests/periph/gpio_ll`, which
can now provide a valid GPIO port for each and every board
- Writing to invalid memory mapped I/O addresses was treated as
triggering undefined behavior by the compiler and used as a
optimization opportunity
2. We can now detect at compile time if the naming scheme of the MCU
uses letters or numbers, and produce more user friendly output.
- This is directly applied in the test app
The script to fix the vendor header files has been renamed to
`fix_headers.sh` and now does two things:
1. Strip bogus type qualifiers in front of padding (as before)
2. Strip bogus `LITTLE_ENDIAN` defines.
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>
Drop type qualifiers in front of anonymous bit fields (padding for
reserved bits) for compatibility with `clang++`. A four line bash
script was added to ease fixing new vendor header files.
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>
This reverts commit 585dc15f99.
I did misunderstand this feature: This only inverts the data
bits (instead of `c` uart will transmit `~c`), not the whole
line level.
This is not very useful on it's own, so revert it.
