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.
19933: examples/gcoap: add saml11-xpro to CI boards with insufficient memory r=miri64 a=krzysztof-cabaj
### Contribution description
Bors run for PR #19927 reveals that ```examples\gcoap``` do not fit in saml11-xpro board.
I checked and this same linker error also appears on current master branch.
This PR add sampl11-xpro board to the Makefile.ci BOARD_INSUFFICIENT_MEMORY list.
### Testing procedure
See logs from bors https://ci.riot-os.org/details/073c5dadc6ba4bc8a613edb78a1a4a2d
### Issues/PRs references
PR #19927
Co-authored-by: krzysztof-cabaj <kcabaj@gmail.com>
19924: drivers/pcf857x: Move compile time check to compilation unit r=maribu a=maribu
### Contribution description
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.
### Testing procedure
- binaries should not change
- including the pcf857x header should work without having selected one of the pcf857x variants, if the driver is not actually used
- when calling any of the functions provided, linking should fail
- when using the `pcf857x` module without any variant, compiling should still fail with a message indicating that (at least) one of the pcf857x needs to be selected
### Issues/PRs references
None
19925: cpu/sam3: assert valid freq in timer_init() r=maribu a=maribu
### Contribution description
The API of timer_init() expects callers to know what frequencies are supported and only use valid frequencies. So let's add an `assert()` to aid debugging if the app uses an invalid.
### Testing procedure
- any valid application should compile and work as before
- an application using an unsupported timer frequency should trigger an `assert()`, rather than letting the timer silently run at a (possibly widely) different frequency
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
The API of timer_init() expects callers to know what frequencies are
supported and only use valid frequencies. So let's add an `assert()`
to aid debugging if the app uses an invalid.
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.
19922: boards/msb-430: Fix periph config & improve doc r=maribu a=maribu
### Contribution description
tl;dr: This fixes the periph config of the MSB-430 board and improves the documentation.
The pins P5.2, P5.1, P5.3 configured as SPI pins are only routed to USART1 and not to USART0, but previously USART0 was configured as peripheral backing the bus. This fixes the peripheral configuration by changing it to USART1.
This is quite unfortunate as USART1 is also used to provide the UART interface used for `stdio`. Hence, one can either use `stdio` or SPI. A feature conflict between UART and SPI has therefore been added.
Note that while it would be possible to use P3.2, P3.1, P3.3 to provide SPI with USART0, this would not work in practise: P3.1 and P3.3 are connected to the CC1020 transceiver.
Switching to P3.4/P3.5 for UART to provide it using USART 0 would also resolve the resource conflict. However, these pins are not available via any of the header and would require soldering the UART<->USB adapter directly to the pins of the MCU chip on the PCB. It is therefore much more user friendly to keep the UART bus backed by USART1 to use pins P3.6 and P3.7 that are easily accessible via the pin header.
### Testing procedure
Check in above screenshot of the datasheet that P5.2, P5.1, and P5.3 indeed can only provide SPI via USART 1, as indicated by the names SOMI1 (SOMI = slave out, master in ≈ master in, slave out = MISO; 1 for USART 1), SIMO1, and UCLK1 (UCLK = USART clock, used as SCK in SPI mode or SCL in I2C mode).
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
The pins P5.2, P5.1, P5.3 configured as SPI pins are only routed to
USART1 and not to USART0, but previously USART0 was configured as
peripheral backing the bus. This fixes the peripheral configuration by
changing it to USART1.
This is quite unfortunate as USART1 is also used to provide the UART
interface used for `stdio`. Hence, one can either use `stdio` or SPI.
A feature conflict between UART and SPI has therefore been added.
Note that while it would be possible to use P3.2, P3.1, P3.3 to provide
SPI with USART0, this would not work in practise: P3.1 and P3.3 are
connected to the CC1020 transceiver.
Switching to P3.4/P3.5 for UART to provide it using USART 0 would also
resolve the resource conflict. However, these pins are not available
via any of the header and would require soldering the UART<->USB
adapter directly to the pins of the MCU chip on the PCB. It is therefore
much more user friendly to keep the UART bus backed by USART1 to use
pins P3.6 and P3.7 that are easily accessible via the pin header.
A common source of error is that a user connects to a serial port that
has already been opened in another terminal.
This may lead to garbled output or no output at all.
To avoid this, claim exclusive access on the serial port so we get a
proper error instead of corrupted output.
19899: drivers/sdmmc: store SDMMC device descriptor references in XFA r=gschorcht a=gschorcht
### Contribution description
SDIO/SD/MMC device descriptor references are now defined as members of an XFA array `sdmmc_devs`. The i-th device in this array can then be accessed with `sdmmc_devs[i]`. The number of SDIO/SD/MMC device descriptors `SDMMC_NUMOF` is `XFA_LEN(sdmmc_devs)`.
### Testing procedure
Green CI
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Router Advertisements are enabled automatically for routing nodes
as soon as they obtain a prefix (e.g. via DHCPv6, UHCP, …).
Enabling router advertisements without a prefix to advertise is
wrong and causes no router solicitations to be send on an upstream
interface.
Also from https://www.rfc-editor.org/rfc/rfc4861#section-6.2.1
Note that AdvSendAdvertisements MUST be FALSE by
default so that a node will not accidentally start
acting as a router unless it is explicitly
configured by system management to send Router
Advertisements.
19827: drivers/st77xx: implement initialization r=aabadie a=gschorcht
### Contribution description
This PR implements correct initialization for ST7735, ST7789 and ST7796. A number of configuration parameters are exposed via Kconfig. The user can decide whether to use custom configuration parameters or reset defaults.
~To be compilable, the PR includes PR #19824 and PR #19825~
### 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
~Depends on #19825~
Fixes#19818
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
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>
