Assertions are used instead of returning a NULL pointer to detect errors in the MTD definition and access in the case that the return value is not evaluated.
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.
This makes it easier to use common error reporting such as `strerror()`
or `tiny_strerror()` to give more insight on why something failed.
The custom error codes via `enum` have been updated to be synonymous
with the `errno` codes for backward compatibility.
In addition, `pcf857x_init()` has been updated to no longer or
together the return code, but rather abort on the first fail transaction
and return the error code as is. Otherwise (when both fail due to
different error codes) the returned error code may be garbage.
19465: drivers/mtd: use XFA for pointers to defined MTDs r=benpicco a=gschorcht
### Contribution description
This PR provides the support to hold pointers to defined MTDs within a XFA. The XFA allows
- to access MTDs of different types (`mtd_flashpage`, `mtd_sdcard`, `mtd_emulated`, ...) by an index
- to determine the number of MTDs defined in the system.
### Testing procedure
To be defined once PR #19443 is merged because emulated MTDs will allow to test this PR on arbitrary boards.
### Porting Guide
For external boards:
- remove the `MTD_NUMOF` definition from `board.h`
- add `MTD_XFA_ADD(<mtd_dev>, <idx>);` to the definition of `<mtd_dev>`.
- `MTD_0`, `MTD_1`, … defines are no longer needed.
### Issues/PRs references
Related to PR #19443
19981: Fletcher32: Add incremental API r=benpicco a=bergzand
### Contribution description
This PR extends the current fletcher32 checksum with an incremental API mode. This way the bytes to be checksummed can be supplied via multiple successive calls and do not have to be provided in a single consecutive buffer.
I've also rephrased the warning with the original function a bit as that function uses an `unaligned_get_u16` to access the data. The data thus does not require alignment, but the length does need to be supplied as number of 16 bit words.
### Testing procedure
The test has been extended
### Issues/PRs references
None
19995: sys/psa_crypto: Fix macro for public key max size and SE example r=benpicco a=Einhornhool
### Contribution description
#### 1. Wrong public key size when using secure elements, introduced by #19954
Fixed conditions for key size macros in `crypto_sizes.h`.
#### 2. EdDSA and ECDSA examples fail when using a secure element because of unsopported changes introduced by #19954
Updated `example/psa_crypto` to use only supported functions for secure elements.
### Testing procedure
Build `example/psa_crypto` for secure elements and run application
Output on master:
```
2023-10-19 14:33:24,372 # main(): This is RIOT! (Version: 2019.07-devel-22378-gb6772)
2023-10-19 14:33:24,372 # HMAC SHA256 took 56393 us
2023-10-19 14:33:24,372 # Cipher AES 128 took 68826 us
2023-10-19 14:33:24,372 # *** RIOT kernel panic:
2023-10-19 14:33:24,373 # HARD FAULT HANDLER
2023-10-19 14:33:24,373 #
2023-10-19 14:33:24,373 # *** rebooting...
```
Output with fixes:
```
2023-10-19 13:35:24,715 # main(): This is RIOT! (Version: 2019.07-devel-22384-g8ef66-dev/psa-crypto-fixes)
2023-10-19 13:35:24,715 # HMAC SHA256 took 56374 us
2023-10-19 13:35:24,715 # Cipher AES 128 took 68805 us
2023-10-19 13:35:24,715 # ECDSA took 281164 us
2023-10-19 13:35:24,715 # All Done
```
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Koen Zandberg <koen@bergzand.net>
Co-authored-by: Lena Boeckmann <lena.boeckmann@haw-hamburg.de>
19941: drivers/lcd: add MCU-driven low-level parallel interface r=benpicco a=gschorcht
### Contribution description
The PR extends the LCD driver by a low-level interface for MCU-driven implementations of the MCU 8080 16-/8-bit parallel interface, allowing the MCU to use special peripherals for the interface, such as the FMC for STM32 MCUs, which is significantly faster than the integrated GPIO-driven parallel interface implementation of the LCD driver.
### Testing procedure
~Once PR #19938 and PR #19939 are merged, a PRs for these board can be pushed that allow to test this PR.~
Use either PR #19943 or PR #19944 on top of this PR to test, e.g. with PR #19943:
```
BOARD=stm32f723e-disco make -j8 -C tests/drivers/st77xx flash
```
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19760: cpu/sam0_common/periph: add low-level SDMMC peripheral driver for SDHC r=benpicco a=gschorcht
### Contribution description
This PR implements the low-level SDIO/SDMMC peripheral driver for SAM0 SDHC according to the definition in #19539.
### Testing procedure
```
BOARD=same54-xpro make -C tests/drivers/sdmmc
```
```
BOARD=same54-xpro make -C tests/sys/vfs_default
```
### Issues/PRs references
~Depends on PR #19539~
Depends on PR #19899
19946: posix_sockets.c: Fix 2 byte int compilation errors r=benpicco a=mrdeep1
19956: cpu/esp32: fix heap definition for ESP32-S2 and ESP32-S3 r=benpicco a=gschorcht
### Contribution description
For ESP32-S2 and ESP32-S3 the symbol `_heap_end` must not be used as `_eheap` for the newlibc `malloc` and function `sbrk`.
`_heap_end` is used by the ESP-IDF heap implementation `esp-idf-heap` and points to the highest possible address (0x40000000) that could be used for the heap in ESP-IDF. It doesn't point to the top address of the unused SRAM area that can be used in newlibc `malloc` and function `sbrk`. Instead, the origin and the length of `dram0_0_seg` must be used to calculate the end of the heap `_eheap`.
The problem only occurs for the newlibc `malloc` when the `sbrk` function is used but not for the ESP-IDF heap implementation `esp_idf_heap`.
### Testing procedure
Use any ESP32-S2 or ESP32-S3 board and flash `tests/sys/malloc`, e.g.
```
CFLAGS='-DCHUNK_SIZE=16384' USEMODULE='stdio_uart' BOARD=esp32s3-pros3 make -j8 -C tests/sys/malloc flash
```
Without the PR the `nm` command will give the wrong address
```
nm -s tests/sys/malloc/bin/esp32s3-pros3/tests_malloc.elf | grep _eheap
40000000 A _eheap
```
The test will stuck, i.e. the allocation of memory stops when the top of unused SRAM is reached and the board restarts when the watchdog timer expires. With the PR it should work as expected
```
Help: Press s to start test, r to print it is ready
START
main(): This is RIOT! (Version: 2023.10-devel-309-g4669e)
calloc(zu, zu) = 0x10000000
CHUNK_SIZE: 16384
NUMBER_OF_TESTS: 3
Allocated 16384 Bytes at 0x3fc8c4b0, total 16384
...
Allocated 16384 Bytes at 0x3fcec6f0, total 409792
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x7 (TG0WDT_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x403763e3
```
With this PR the `nm` command should give a address in unused SRAM address space
```
nm -s tests/sys/malloc/bin/esp32s3-pros3/tests_malloc.elf | grep _eheap
3fcca000 A _eheap
```
and the test should pass.
### Issues/PRs references
19957: cpu/esp32: fix Octal SPI RAM for ESP32-S3 r=benpicco a=gschorcht
### Contribution description
This PR fixes Octal SPI RAM handling for ESP32-S3.
Functions that are used during the initialization of the Octal SPI RAM must reside in IRAM instead of Flash. Otherwise, the system stucks during boot once the Octal SPI RAM is enabled. The reason is that the Flash is not available during the initialization of the Octal SPI RAM and the functions that are called during that initialization can't be accessed in Flash. As a result the call of such a function leads to code that is messed up and the system crashes.
The PR also includes the documentation fixe for the `esp32s3-box`. It also includes a small documentation fix regarding the SPI RAM for the `esp32s3-pros3` board.
### Testing procedure
Use a board that has Octal SPI RAM and flash `tests/sys/malloc`, e.g.:
```
CFLAGS='-DCHUNK_SIZE=16384' USEMODULE='stdio_uart esp_spi_ram esp_log_startup' \
BOARD=esp32s3-box make -C tests/sys/malloc
```
Without the PR, the system stuck during boot once the information for the Octal SPI RAM is print
```
ESP-ROM:esp32s3-20210327
...
I (133) boot: Loaded app from partition at offset 0x10000
I (134) boot: Disabling RNG early entropy source...
vendor id : 0x0d (AP)
dev id : 0x02 (generation 3)
density : 0x03 (64 Mbit)
good-die : 0x01 (Pass)
Latency : 0x01 (Fixed)
VCC : 0x01 (3V)
SRF : 0x01 (Fast Refresh)
BurstType : 0x01 (Hybrid Wrap)
BurstLen : 0x01 (32 Byte)
Readlatency : 0x02 (10 cycles@Fixed)
DriveStrength: 0x00 (1/1)
```
and the board restarts when the watchdog timer expires.
With this PR, the system starts as expected.
```
ESP-ROM:esp32s3-20210327
...
I (132) boot: Loaded app from partition at offset 0x10000
I (133) boot: Disabling RNG early entropy source...
vendor id : 0x0d (AP)
dev id : 0x02 (generation 3)
density : 0x03 (64 Mbit)
good-die : 0x01 (Pass)
Latency : 0x01 (Fixed)
VCC : 0x01 (3V)
SRF : 0x01 (Fast Refresh)
BurstType : 0x01 (Hybrid Wrap)
BurstLen : 0x01 (32 Byte)
Readlatency : 0x02 (10 cycles@Fixed)
DriveStrength: 0x00 (1/1)
Found 64MBit SPI RAM device
SPI RAM mode: sram 40m
PSRAM initialized, cache is in normal (1-core) mode.
Pro cpu up.
Single core mode
SPI SRAM memory test OK
Initializing. RAM available for dynamic allocation:
At 3FC8C150 len 00053EB0 (335 KiB): D/IRAM
At 3FCE0000 len 0000EE34 (59 KiB): STACK/DRAM
At 3FCF0000 len 00008000 (32 KiB): DRAM
Starting ESP32x with ID: f412fafd0f8c
ESP-IDF SDK Version v4.4.1
Current clocks in Hz: CPU=80000000 APB=80000000 XTAL=40000000 SLOW=150000
PRO cpu is up (single core mode, only PRO cpu is used)
PRO cpu starts user code
Adding pool of 8192K of external SPI memory to heap allocator
Used clocks in Hz: CPU=80000000 APB=80000000 XTAL=40000000 FAST=8000000 SLOW=150000
XTAL calibration value: 3643448
Heap free: 8754851 bytes
Board configuration:
UART_DEV(0) txd=43 rxd=44
LED pins=[ ]
BUTTONS pins=[ 0 ]
Starting RIOT kernel on PRO cpu
Help: Press s to start test, r to print it is ready
```
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Jon Shallow <supjps-libcoap@jpshallow.com>
19914: boards: complete SD Card MTD definition for several bords r=benpicco a=gschorcht
### Contribution description
This PR completes the MTD definition for the following boards:
- `seeedstudio-gd32`
- `sipeed-longan-nano` including `sipeed-longan-nano-tft`
- `waveshare-nrf52840-eval-kit`
- ESP32x boards that have an SPI SD Card interface and use `mtd_sdcard_default`
### Testing procedure
Green CI
### Issues/PRs references#19465
Prerequisite for PR #19465
19915: drivers/lcd: support MCU 8080 8-bit parallel mode r=benpicco a=gschorcht
### Contribution description
LCD driver ICs usually support
- SPI serial mode,
- MCU 8080 8-bit parallel mode and
- MCU 8080 16-bit parallel mode.
This PR extends the LCD display driver API to support the MCU 8080 8-/16-bit parallel modes and implements a GPIO-driven MCU 8080 8-bit parallel mode.
The following features are already working locally and will be provided as follow-on PRs for which this PR is a prerequisite.
- GPIO-driven bit-banging implementation of the 16-bit mode of the MCU 8080 parallel interface
- Enabling the display on `stm32f723e-disco` and `stm32l496g-disco` using the feature above
- Definition of a low-level API for the parallel modes using the LCD controller of the MCU
- Using FMC for the display on `stm32f723e-disco` and `stm32l496g-disco`
- Using LCD controller for the display of `esp32-wt32-sc01-plus` (PR #19917)
### Testing procedure
The PR can be tested with PR #19917 on top of this PR.
```
BOARD=esp32s3-wt32-sc01-plus make -j8 -C tests/drivers/st77xx flash
```
The following video shows the test.
**Please note** The test is pretty slow because the display has 480 x 320 pixels and the MCU 8080 8-bit parallel interface is realized by a GPIO-driven bit-banging implementation where each GPIO of the data bus is set separately. A follow-up PR will use the ESP32-S3 LCD controller and DMA for this board. This PR just defines the extension of the driver by the parallel interface and provides the bit-banging implementation for MCUs that don't have a LCD controller on chip.
https://github.com/RIOT-OS/RIOT/assets/31932013/c1e3e3d7-05d9-4ca5-8fff-9a5eaca50fba
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19919: drivers/st77xx: introduce rotation defines r=benpicco a=gschorcht
### Contribution description
The PR introduces counterclockwise rotations for the definition of parameter `ST77XX_PARAM_ROTATION`.
It is more intuitive and universal to use `ST77XX_ROTATION_{0,90,180,270}` instead of `ST77XX_ROTATION_{ST77XX_ROTATION_{VERT,VERT_FLIP,HORZ,HORZ_FLIP}`, especially because the orientation of the display may vary with respect to the orientation of the board.
### Testing procedure
`tests/drivers/st77xx` should still work, for example:
```
BOARD=adafruit-pybadge make -C tests/drivers/st77xx flash
```
```
BOARD=esp32s3-usb-otg make -j8 -C tests/drivers/st77xx flash
```
### Issues/PRs references
19931: boards: fix documentation for GD32V boards and doxygen 1.9.4 r=benpicco a=gschorcht
### Contribution description
This PR fixes some small problems in documentation of `sipeed-longan-nano`, `sipeed-longan-nano-tft` and `seeedstudio-gd32` for doxygen 1.9.4 that is used on `doc.riot-os.org`.
Doxygen version 1.9.4 doesn't like anymore
- single double quotes as symbol for the inches unit in the text
- line breaks in `[]()` to avoid exhausting the 100 characters per line.
See https://doc.riot-os.org/group__boards__sipeed__longan__nano.html for example.
Doxygen 1.9.1 which is part of `riot-docker` container didn't have theses problems 😟
### Testing procedure
Documentation should be fixed.
### Issues/PRs references
19935: boards/nucleo64: fix SPI Arduino mapping for most boards r=benpicco a=maribu
### Contribution description
Before, the Arduino SPI mapping for all Nucleo-64 boards was incorrect. With this, the situation improves to the following:
- [x] nucleo-f030r8
- [ ] nucleo-f070rb
- No SPI buses provided.
- [x] nucleo-f072rb
- [x] nucleo-f091rc
- [x] nucleo-f103rb
- [ ] nucleo-f302r8
- No SPI bus at D11, D12, D13 provided
- [x] nucleo-f303re
- [x] nucleo-f334r8
- [x] nucleo-f401re
- [x] nucleo-f410rb
- [x] nucleo-f411re
- [x] nucleo-f446re
- [x] nucleo-g070rb
- [x] nucleo-g071rb
- [x] nucleo-g431rb
- [x] nucleo-g474re
- [x] nucleo-l053r8
- [x] nucleo-l073rz
- [x] nucleo-l152re
- No SPI bus at D11, D12, D13 provided
- [x] nucleo-l452re
- [x] nucleo-l476rg
- [x] nucleo-wl55jc
The remaining offenders still need to be fixed, but that is better done one PR at a time.
### Testing procedure
- Check if the SPI device provided in the given `boards/<BOARD_NAME>/incude/periph_conf.h` is indeed `SPI_DEV(0)`, or in `periph_conf.h` the correct SPI dev is found
- this should be fine for all boards above, except for the unchecked ones
or:
- run https://github.com/RIOT-OS/RIOT/pull/19932: The SPI test should pass now
### Issues/PRs references
Bug found in https://github.com/RIOT-OS/RIOT/pull/19932#issuecomment-1726305437
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
For the parallel interface support the following changes were made:
1. Additional `lcd_*` pseudomodules are defined to control whether SPI serial or MCU 8080 8-/16-bit parallel interface is used.
2. The low level function implementation was extended for parallel interfaces so that the now can use either the SPI serial interface or the MCU 8080 8-/16-bit parallel interface.
Using the `lcc_*` modules, either the SPI serial interface or the MCU 8080 8-/16-bit interface or even both for multiple display can be used simultaneously.
This allows including the header without using the module. Obviously,
calls to the functions provided by the header won't like without using
the module. But including the header can still be useful for e.g.:
if (IS_USED(MODULE_PCF857x)) {
/* make use of the module */
}
In the above example all calls to pcf857x functions would be optimized
out when the module is not used, full compile checks happen in either
case.
19825: drivers: rename st7735 to more generic st77xx r=aabadie a=gschorcht
### Contribution description
This PR provides the following changes:
- renames the driver `st7735` to `st77xx`
- renames the test `st7735` to `st77xx`
- models controller variants as pseudomodules `st7735`, `st7789` and `st7796`
- removes the buggy initialization as a workaround to use reset defaults, see issue #19818
- adds backward compatibility header files for `ST7735_PARAM_*` symbols
- adds a test board for compilation test of backward compatibility
- updates the corresponding board definitions
The PR should solve the remaining dependency issues in KConfig we had by using `st7735` module for different controller variants. The backward compatibility header files should work for boards that still use `ST7735_PARAM_*` in their board definitions so that the board defintions at user's side use shouldn't be affected.
~To be compilable, the PR includes PR #19824.~
### Testing procedure
- Green CI
- `tests/drivers/disp_dev` and `tests/drivers/st77xx` should still work for all boards using a ST77xx display.
- The PR was already tested for these tests for:
- [x] `adafruit-pybadge`
- [x] `esp32s2-lilygo-ttgo-t8`
- [x] `esp32s3-usb-otg`
- [x] `sipeed-longan-nano`
### Issues/PRs references
Workaround for issue #19818
Preqruisite for PR #19827
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19794: drivers/periph: Add documentation on thread safety and initialization r=aabadie a=maribu
19912: drivers/at86rf215: switch example config to use EXT3 on same54-xpro r=aabadie a=benpicco
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
To obtain coordinates from the touch panel that correspond to the display coordinates, it is often necessary to convert the coordinates from the touch display by swapping and mirroring. For the sake of simplicity, possible rotations are additionally defined.
19884: drivers/touch_dev_gestures: add gesture recognition for touch devices r=aabadie a=gschorcht
### Contribution description
This PR adds simple gesture recognition for touch devices accessed via the generic Touch Device API. It can be used in conjunction with device drivers that use either interrupts or polling mode. It supports up to two touches and the following gestures:
- Single and double tap at given position
- Long press and release given position
- Moving while pressed with current position
- Swipe left, right, up and down
- Zoom in (spread) and out (pinch)
Gesture recognition has been tested with:
- [x] `stm32f746g-disco` (works out of the box)
- [x] `stm32f723e-disco` (works out of the box)
- [x] `stm32f429i-disc1` (works on top of PR #19885)
- [x] `stm32l496g-disco` (works with my local LCD display changes waiting for PR #19825, not yet provided)
- [x] `esp32s3-wt32-sc01-plus` (new board, not yet provided)
### Testing procedure
Flash `tests/drivers/touch_dev_gestures` to a board with touch pane, for example:
```
BOARD=stm32f746g-disco make -j8 -C tests/drivers/touch_dev_gestures/ flash
```
PR #19885 is required for the `stm32f429i-disc1` board.
The output should look like this:
```
main(): This is RIOT! (Version: 2023.10-devel-121-g81c5c-drivers/touch_dev_gestures)
Single Tap X: 255, Y:154
Single Tap X: 253, Y:153
Double Tap X: 253, Y:149
Swipe right
Swipe down
Swipe left
Swipe up
Pressed X: 257, Y:155
Moving X: 257, Y:155
Moving X: 257, Y:155
Moving X: 259, Y:156
Moving X: 262, Y:157
Moving X: 266, Y:158
Moving X: 269, Y:160
Moving X: 273, Y:162
Moving X: 276, Y:165
Moving X: 278, Y:167
Moving X: 278, Y:169
Moving X: 278, Y:169
Released X: 279, Y:172
```
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
To obtain coordinates from the touch panel that correspond to the display coordinates, it is often necessary to convert the coordinates from the touch display by swapping and mirroring. For the sake of simplicity, possible rotations are additionally defined.
There is no need to copy the configuration parameter set to the device descriptor. A const pointer to the configuration parameter set in ROM is sufficient. It saves some 16 byte of RAM.
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>
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
In preparation for the parallel interface support the following changes were made:
1. The code for basic communication (acquire/release SPI device, SPI transfers), which were always implemented identically in the individual display drivers again and again, have been moved to the LCD driver as low-level functions and are now used by the display drivers. These low level function allow
- code deduplication on one hand and
- to define a more abstract communication interface on the other hand that can then be extended by parallel communication
2. Identical GPIO initialization has also been moved from display drivers to the LCD driver.
- Rename all `arduino_pinmap.h` to `arduino_iomap.h`
- An empty `arduino_pinmap.h` that just includes `arduino_iomap.h`
is provided for backward compatibility
- Move all info from `arduino_board.h` into the new file as trivial
macros, so that they can also be used outside of sketches
- The new name reflects the fact not just pin mappings, but also
other I/O features such as PWMs are mapped
- Drop all `arduino_board.h`
- `arduino_board.h` and `arduino_iomap.h` now provide the exact
same information, just in a different format
- a generic `arduino_board.h` is provided instead that just
uses the info in `arduinio_iomap.h` and provides them in the
format the code in `sys/arduino` expects it
- Add fine grained features to indicate for mappings
- availability of mappings for analog pins, DAC pins, PWM pins,
UART devices, SPI/I2C buses to the corresponding RIOT
identification can now be expressed:
- `arduino_pins`: `ARDUINO_PIN_0` etc. are available
- `arduino_analog`: `ARDUINO_A0` etc. are available
- `arduino_pwm`: `ARDUINO_PIN_13_PWM_DEV` etc. are available
- `arduino_dac`: `ARDUINO_DAC0` etc. are available
- `arduino_uart`: `ARDUINO_UART_D0D1` or similar are available
- `arduino_spi`: `ARDUINO_SPI_ISP` or similar are available
- `arduino_i2c`: `ARDUINO_I2C_UNO` or similar are available
- mechanical/electrical compatibility with specific form factors
can now be expressed as features:
- `aruino_shield_nano`: Arduino NANO compatible headers
- `aruino_shield_uno`: Arduino UNO compatible headers
- `aruino_shield_mega`: Arduino MEGA compatible headers
- `aruino_shield_isp`: ISP header is available
This provides the groundwork to implement shield support as modules
that can rely on the I/O mappings, rather than having to provide a
configuration per board.
19718: drivers/dht: busy wait reimplementation r=benpicco a=hugueslarrive
### Contribution description
In PR #19674, I also provided quick and dirty fixes to restore functionality on esp8266 and enable operation on AVR. While reviewing PR #18591, it became apparent to me that this driver needed a refresh, particularly its migration to ztimer.
The cause of the malfunction on esp8266 was that since the default switch to ztimer as the backend for xtimer, XTIMER_BACKOFF was no longer taken into account. Therefore, the correction I provided in PR #19674 simply made explicit what was previously done implicitly with xtimer and now needs to be done explicitly with ztimer (spinning instead of sleeping).
Moreover, it was unnecessarily complex to measure the pulse duration in a busy-wait implementation, which required 2 calls to ztimer_now() and 32-bit operations expensive on 8-bit architecture. Instead, it is sufficient to read the state of the bus at the threshold moment.
Finally, in practice, it is possible to reduce the read interval (down to less than 0.5s for DHT22) by "harassing" the DHT with start signals until it responds.
This re-implementation brings the following improvements:
- Many backports from `@maribu's` IRQ based implementation (#18591):
- Use of ztimer
- Use of errno.h
- Use of a dht_data structure to pass arguments, to facilitate integration
- Adaptation of the bit parsing technique to parse bits into the data array
- Reintroduction of DHT11/DHT22 differentiation.
- Separation of `dht_read()` steps into functions for better readability and the ability to share certain functions among different implementations
- Sensor presence check in `dht_init()`
- ~~Automatic adjustment to a minimum data hold time~~
- Default input mode changed to open drain (a pull-up resistor should be placed close to the output if necessary but not close to the input)
- AVR support without platform-specific handling by avoiding ztimer_spin() and using the overflow of an 8-bit variable as a pre-timeout to minimize time-consuming ztimer_now() calls
Regarding the changes in the start signal sequence and the removal of the `_reset()` function:
~~In the previous implementation, there was an unnecessary spike at the beginning of the signal sequence, corresponding to START_HIGH_TIME. This spike has been removed in the re-implementation, as it is unnecessary. Instead, the MCU now simply pulls the signal low for START_LOW_TIME and then releases the bus, which is sufficient for initiating communication with the DHT sensor.~~ Actually, it is necessary to raise the bus level; otherwise, the _wait_for_level() called immediately after to check the response of the DHT may read the port before the signal level is raised, resulting in a false positive.
Additionally, the previous implementation had an issue where the MCU switched back to output mode and went high immediately after reading the 40 bits of data. However, the DHT sensor was still transmitting 2 or 3 additional bytes of '0' at that point, causing a conflict. This issue has been resolved in the re-implementation:
~~Regarding the optimization for AVR, I have performed measurements of `_wait_for_level()` until timeout (85 loops):~~
~~- on esp8266-esp-12x: 264 µs, which is 3.11 µs per loop~~
~~- on nucleo-f303k8: 319 µs, which is 3.75 µs per loop~~
~~- on arduino-nano: 3608 µs, which is 42.45 µs per loop~~
~~Duration measurements on the Arduino Nano:~~
19737: dist/tools/openocd: start debug-server in background and wait r=benpicco a=fabian18
19746: buildsystem: Always expose CPU_RAM_BASE & SIZE flags r=benpicco a=Teufelchen1
### Contribution description
Hello 🐧
This moves the definition of `CPU_RAM_BASE/SIZE` from being only available in certain situation to be always available.
Reason for change is to simplify common code in the cpu folder.
In cooperation with `@benpicco`
### Testing procedure
Passing CI
### Issues/PRs references
First usage will be in the PMP driver. Although there is more code in RIOT that could be refactored to use these defines instead of hacks / hardcoded values.
Co-authored-by: Hugues Larrive <hlarrive@pm.me>
Co-authored-by: Fabian Hüßler <fabian.huessler@ml-pa.com>
Co-authored-by: Teufelchen1 <bennet.blischke@outlook.com>
- many backports from @maribu's IRQ based implementation (#18591)
- use of ztimer and errno.h
- separation of dht_read() steps into functions for better readability
- reintroduction of DHT11/DHT22 differentiation
- sensor presence checking in dht_init()
- default input mode changed to open drain
- AVR support without platform-specific handling by avoiding
ztimer_spin() and using the overflow of an 8-bit variable as a
pre-timeout to minimize time-consuming ztimer_now() calls
- add a new DHT11_2022 type for 0.01 °C resolution devices
- data caching removed
19703: cpu/sam0_eth: interrupt based link detection/auto-negotiation r=benpicco a=benpicco
19724: dist/tools/openocd: add OPENOCD_SERVER_ADDRESS variable r=benpicco a=fabian18
19735: nrf5x_common: Clear I2C periph shorts r=benpicco a=bergzand
### Contribution description
The I2C peripheral's shortcuts are used with the read and write register to automatically stop the I2C transaction or to continue with the next stage.
With simple I2C read and write bytes these shorts are not used, but are also not cleared by the function in all cases, causing it to use the shortcut configuration set by a previous function call. This patch ensures that the shorts are always set by the read and write functions
### Testing procedure
Should be possible to spot with a logic analyzer and the I2C periph test. Maybe the HIL test can also detect it :)
### Issues/PRs references
None
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Fabian Hüßler <fabian.huessler@ml-pa.com>
Co-authored-by: Koen Zandberg <koen@bergzand.net>
19695: drivers/hih6130: avoid using floats r=maribu a=maribu
### Contribution description
- avoid using floating point arithmetic
- use ztimer instead of xtimer
- use fmt to print fixed point numbers in the test app
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
19610: drivers/periph/rtc: improve doc on rtc_set_alarm r=maribu a=maribu
### Contribution description
- point out behavior on denormalized time stamps
- use errno codes to indicate errors (and adapt the few instances of actual error handling to use them)
19670: cpu/stm32: stm32f4 BRR from BSRR r=maribu a=kfessel
### Contribution description
sometimes one wants to save one instruction :)
just write the bits we need to write.
### Testing procedure
tests/periph/gpio_ll tests this
### Issues/PRs references
`@maribu` might know some reference
maybe #19407
19678: gnrc_sixlowpan_iphc: fix NULL pointer dereference r=maribu a=miri64
19679: gnrc_sixlowpan_frag_sfr: fix ARQ scheduler race-condition r=maribu a=miri64
19680: gnrc_sixlowpan_frag_rb: fix OOB write in _rbuf_add r=maribu a=miri64
19681: sys/xtimer: improve documentation r=maribu a=maribu
### Contribution description
- Add a warning that xtimer is deprecated, so that new code hopefully starts using ztimer
- Add a hint that `ztimer_xtimer_compat` can be used even after `xtimer` is gone
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Karl Fessel <karl.fessel@ovgu.de>
Co-authored-by: Martine Lenders <m.lenders@fu-berlin.de>
- point out behavior on denormalized time stamps
- use errno codes to indicate errors (and adapt the few instances of
actual error handling to use them)
The `mtd_default` module defines `MTD_NUMOF` if not existing based on the `MTD_*` defines which are usually set to the corresponding MTD device pointer variables `mtd*`. However, these MTD device pointer variables are not always made known by external variable declarations. An example are SD Card Interfaces which are defined via the `mtd_sdcard_default` module. As a consequence, an application that uses `mtd_default` has still to be modified. Therefore, `mtd_default` also declares up to 6 `mtd*` MTD device pointer variables.
19523: boards/iotlab-m3: enable l3g4200d_ng r=benpicco a=benpicco
19527: drivers/sdcard_spi: small cleanup r=benpicco a=gschorcht
### Contribution description
This PR provides a small cleanup:
- the copy of `sdcard_spi_params_t` is removed (commit bfc2a51f70)
- the documentation was changed to fit the 100 characters per line. (commit 36f0162b34)
It is not necessary to hold a complete copy `sdcard_spi_params_t` in the device descriptor. Constant parameters can be used directly from ROM instead. This saves 24 bytes of RAM.
### Testing procedure
Use any board with SD Card SPI interface. The driver test should still work, for example:
```
BOARD=esp32-wrover-kit make -j8 -C tests/driver_sdcard_spi flash term
```
```
main(): This is RIOT! (Version: 2023.07-devel-176-g7213c-drivers/sdcard_spi_cleanup)
SD-card spi driver test application
insert SD-card and use 'init' command to set card to spi mode
WARNING: using 'write' or 'copy' commands WILL overwrite data on your sd-card and
almost for sure corrupt existing filesystems, partitions and contained data!
> init
Initializing SD-card at SPI_0...
[OK]
>
```
### Issues/PRs references
19530: sys/xtimer: add missing "modules.h" include to `xtimer.h` r=benpicco a=kaspar030
19532: tests/unittests: tests-core-mbox: add missing `container.h` include r=benpicco a=kaspar030
19533: core: move macros/math.h to core/lib/include/macros r=benpicco a=kaspar030
19535: nanocoap_sock: defuse nanocoap_sock_get() API footgun r=benpicco a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
It is not necessary to hold a complete copy `sdcard_spi_params_t` in the device descriptor. Constant parameters can be used directly from ROM instead. This saves 24 bytes of RAM.
