cpu/efm32/periph: add DAC support for EFM32 Series 1 (VDAC) #19887

gschorcht · 2023-08-15T12:20:27Z

Contribution description

This PR provides a small change for periph_dac to support the VDACs of EFM32 Series 1 MCUs. It was tested with sltb009a board for which this PR includes the DAC configuration.

Testing procedure

tests/periph/dac should work for the sltb009a board. I've tested it already.

BOARD=sltb009a make -j8 -C tests/periph/dac flash

Issues/PRs references

Depends on PR #19886

riot-ci · 2023-08-15T12:40:53Z

Murdock results

✔️ PASSED

e04e8ee boards/sltb009a: enable DAC support

Success	Failures	Total	Runtime
7937	0	7937	14m:27s

Artifacts

Documentation preview

19387: drivers/atwinc15x0: support dynamic scanning and connection to AP r=benpicco a=fabian18 19874: coap: add missing option numbers r=benpicco a=JKRhb 19875: coap: add missing Content-Format definitions r=benpicco a=JKRhb 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 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 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: Fabian Hüßler <fabian.huessler@ml-pa.loc@MLPA-NB119.(none)> Co-authored-by: Fabian Hüßler <fabian.huessler@ml-pa.com> Co-authored-by: Jan Romann <jan.romann@hs-emden-leer.de> 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>

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 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>

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>

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](https://github.com/STMicroelectronics/STM32CubeF7/blob/c20e6dd15bd2a90e19f28cadc703aeb26825d211/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: https://github.com/RIOT-OS/RIOT/blob/bb9011c3fbfe7c20bde99ce2462ef564d555ea08/boards/stm32f723e-disco/include/board.h#L59 - According to the [STM32CubeF7](https://github.com/STMicroelectronics/STM32CubeF7/blob/c20e6dd15bd2a90e19f28cadc703aeb26825d211/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](https://github.com/adafruit/Adafruit_FT6206_Library/blob/95118cd9831890616a1afb55d323b6261dee15af/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>

aabadie · 2023-08-28T08:02:23Z

bors merge

19887: cpu/efm32/periph: add DAC support for EFM32 Series 1 (VDAC) r=aabadie a=gschorcht ### Contribution description This PR provides a small change for `periph_dac` to support the VDACs of EFM32 Series 1 MCUs. It was tested with `sltb009a` board for which this PR includes the DAC configuration. ### Testing procedure `tests/periph/dac` should work for the `sltb009a` board. I've tested it already. ``` BOARD=sltb009a make -j8 -C tests/periph/dac flash ``` ### Issues/PRs references Depends on PR #19886 Co-authored-by: Gunar Schorcht <gunar@schorcht.net>

bors · 2023-08-28T11:21:02Z

Build failed:

Murdock

aabadie · 2023-08-28T12:59:00Z

It seems other boards have to be adapted of something is missing. https://ci.riot-os.org/results/d24f504a91b54fb987d1606d97b9d409/output/builds/tests/drivers/bh1750/xg23-pk6068a:gnu.txt

gschorcht · 2023-08-28T17:54:33Z

Hm 🤔 the board for which the compilation failed is a EFM32 Series 2 board for which the VDAC driver is not yet implemented.

The problem seems to be that em_vdac.h is included only for EFM32 Series 1 in periph_cpu.h but the VDAC_COUNT variable that is used to decide whether to define the dac_conf_t struct using the VDAC_RefType is also defined for EFM32 Series 2 MCUs. For EFM32 Series 2 MCUs, however, em_idac.h is included in periph_cpu.h instead but I couldn't find any place where IDAC is used.

Maybe, EFM32 Series 2 VDACs also work with this PR. I don't have a EFM32 Series 2 board. Maybe @jue89 can help.

gschorcht · 2023-08-29T17:19:13Z

@aabadie I fixed the compilation error by including em_vdac.h also for EFM32 Series 2 MCUs which have VDACs if VDAC_COUNT is defined. This shouldn't make any problem since the ´periph_dac` feature isn't enabled for the only board we have with a EFM32 Series 2 MCU. We can try to use the VDAC for this board later.

aabadie · 2023-08-30T07:29:49Z

please squash!

gschorcht · 2023-08-30T14:48:53Z

please squash!

Done

aabadie · 2023-08-30T17:34:43Z

bors merge

bors · 2023-08-30T21:09:26Z

Build succeeded!

The publicly hosted instance of bors-ng is deprecated and will go away soon.

If you want to self-host your own instance, instructions are here.
For more help, visit the forum.

If you want to switch to GitHub's built-in merge queue, visit their help page.

gschorcht · 2023-08-31T14:41:30Z

@aabadie Thanks for reviewing and merging 😄

gschorcht requested a review from basilfx as a code owner August 15, 2023 12:20

github-actions bot added Platform: ARM Platform: This PR/issue effects ARM-based platforms Area: boards Area: Board ports Area: cpu Area: CPU/MCU ports labels Aug 15, 2023

gschorcht mentioned this pull request Aug 15, 2023

cpu/efm32: fix DAC configuration #19886

Merged

gschorcht added Type: new feature The issue requests / The PR implemements a new feature for RIOT CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Aug 15, 2023

gschorcht force-pushed the cpu/efm32/periph_vdac branch from 72e19be to 7eb20b3 Compare August 15, 2023 12:36

gschorcht force-pushed the cpu/efm32/periph_vdac branch from 7eb20b3 to 3283f34 Compare August 15, 2023 12:58

gschorcht requested review from leandrolanzieri, jia200x and MrKevinWeiss as code owners August 15, 2023 12:58

github-actions bot added the Area: Kconfig Area: Kconfig integration label Aug 15, 2023

gschorcht force-pushed the cpu/efm32/periph_vdac branch from 3283f34 to de523ac Compare August 23, 2023 21:30

aabadie approved these changes Aug 28, 2023

View reviewed changes

gschorcht added 3 commits August 30, 2023 16:47

cpu/efm32: add DAC support for EFM32 Series1 (VDAC)

3499b82

cpu/efm32: include periph_conf.h for system-related methods

e934d52

boards/sltb009a: enable DAC support

e04e8ee

gschorcht force-pushed the cpu/efm32/periph_vdac branch from 53711fb to e04e8ee Compare August 30, 2023 14:48

aabadie added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Aug 30, 2023

bors bot merged commit 26cb4db into RIOT-OS:master Aug 30, 2023

gschorcht deleted the cpu/efm32/periph_vdac branch August 31, 2023 14:53

MrKevinWeiss added this to the Release 2023.10 milestone Nov 17, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cpu/efm32/periph: add DAC support for EFM32 Series 1 (VDAC) #19887

cpu/efm32/periph: add DAC support for EFM32 Series 1 (VDAC) #19887

gschorcht commented Aug 15, 2023 •

edited

Loading

riot-ci commented Aug 15, 2023 •

edited

Loading

aabadie commented Aug 28, 2023

bors bot commented Aug 28, 2023

aabadie commented Aug 28, 2023

gschorcht commented Aug 28, 2023

gschorcht commented Aug 29, 2023 •

edited

Loading

aabadie commented Aug 30, 2023

gschorcht commented Aug 30, 2023

aabadie commented Aug 30, 2023

bors bot commented Aug 30, 2023

gschorcht commented Aug 31, 2023

cpu/efm32/periph: add DAC support for EFM32 Series 1 (VDAC) #19887

cpu/efm32/periph: add DAC support for EFM32 Series 1 (VDAC) #19887

Conversation

gschorcht commented Aug 15, 2023 • edited Loading

Contribution description

Testing procedure

Issues/PRs references

riot-ci commented Aug 15, 2023 • edited Loading

Murdock results

Artifacts

aabadie commented Aug 28, 2023

bors bot commented Aug 28, 2023

aabadie commented Aug 28, 2023

gschorcht commented Aug 28, 2023

gschorcht commented Aug 29, 2023 • edited Loading

aabadie commented Aug 30, 2023

gschorcht commented Aug 30, 2023

aabadie commented Aug 30, 2023

bors bot commented Aug 30, 2023

gschorcht commented Aug 31, 2023

gschorcht commented Aug 15, 2023 •

edited

Loading

riot-ci commented Aug 15, 2023 •

edited

Loading

gschorcht commented Aug 29, 2023 •

edited

Loading