The LEDx_PIN may still be defined (eg. on the particle-mesh family
because it is used to configure the PWM pins); the IS_PRESENT macro
performs the stricter check ov testing for an _ON function.
GPIO LL headers might be included even when not using GPIO LL. Some
functions may be provided by the common header or the platform specific
one, depending on the features used. Hence, the header can only be
safely included if the correct set of GPIO LL hardware features is used.
The assumption that every MCU has this feature turned out wrong. Hence,
add a feature to allow testing for support of edge triggered IRQs on
both flanks.
When WDT_HAS_INIT is non-zero (which it is for all but two supported
CPUs). The watchdog timer was not automatically started on boot when the
periph_wdt_auto_start module was enabled. This patch fixes this.
This adds two functions:
void gpio_ll_switch_dir_output(gpio_port_t port, uword_t outputs);
void gpio_ll_switch_dir_input(gpio_port_t port, uword_t inputs);
The first configures GPIO pins specified by a bitmask as output, the
second configures the specified pins as input.
The main use case is to allow bit-banging bidirectional protocols using
more basic GPIO peripherals that do not implement open drain mode, such
as found e.g. on MSP430, ATmega, or SAM0.
It is not intended to implement this feature on modern MCUs with
sophisticated GPIO peripherals.
This adds the features
- periph_gpio_ll_input_pull_down:
To indicate support for input mode with internal pull down
- periph_gpio_ll_input_pull_keep:
To indicate support for input mode with internal resistor
pulling towards current level
- periph_gpio_ll_input_pull_up:
To indicate support for input mode with internal pull up
- periph_gpio_ll_disconnect:
To indicate a GPIO can be disconnected
- periph_gpio_ll_open_drain:
To indicate support for open drain mode
- periph_gpio_ll_open_drain_pull_up:
To indicate support for open drain mode with internal pull up
- periph_gpio_ll_open_source:
To indicate support for open source mode
- periph_gpio_ll_open_source_pull_down:
To indicate support for open source mode with internal pull down
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>
Allow accessing supported timer frequencies with a dedicated API.
This API needs to be implemented per platform and is available with
the feature periph_timer_query_freqs.
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>
17830: periph/timer: fix Kconfig menu title r=aabadie a=gschorcht
### Contribution description
This PR is a very small fix of inconsistent peripheral driver entry in `Kconfig` for `periph/timer`.
In Kconfig menu `(Top) → Drivers → Peripherals drivers` all entries start with the peripheral name in alphabetical order with only one exception, the timer entry. This entry is called `Configure timer peripheral driver`:
```
[ ] CPU unique ID
[ ] EEPROM peripheral driver
[ ] Flashpage peripheral driver ----
[*] GPIO peripheral driver --->
[ ] HWRNG peripheral driver
[ ] PWM peripheral driver
[*] Power Management (PM) peripheral driver
[*] Auto initialize Power Management (PM) peripheral
[ ] Quadrature Decoder (QDEC) peripheral driver
[ ] RTC peripheral driver ----
[ ] SPI peripheral driver ----
[*] UART peripheral driver --->
[*] Configure timer peripheral driver --->
```
This is confusing and doesn't help to find the right entry. This PR
1. changes the entry to `Timer peripheral driver` and
2. corrects the alphabetical order.
### Testing procedure
Use command
```
TEST_KCONFIG=1 make -C tests/periph_timer menuconfig
```
and check the output. in menu `(Top) → Drivers → Peripherals drivers`. It should be with this PR:
```
[ ] CPU unique ID
[ ] EEPROM peripheral driver
[ ] Flashpage peripheral driver ----
[*] GPIO peripheral driver --->
[ ] HWRNG peripheral driver
[ ] PWM peripheral driver
[*] Power Management (PM) peripheral driver
[*] Auto initialize Power Management (PM) peripheral
[ ] Quadrature Decoder (QDEC) peripheral driver
[ ] RTC peripheral driver ----
[ ] SPI peripheral driver ----
[*] Timer peripheral driver --->
[*] UART peripheral driver --->
```
### Issues/PRs references
19635: drivers/mrf24j40: cleanup function r=aabadie a=maribu
### Contribution description
`_set_csma_params()` spends some time to prepare a value in `uint8_t tmp`, which then is never used. Likely this is a leftover of moving code to `mrf24j40_set_csma_max_retries()`. This drops the leftover code.
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
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>
The warnings appeared after the -fno-builtin compiler flag was removed (#17898),
but the code is looking fine and tests/periph_cpuid shows correct results.
