19938: boards/stm32l496g-disco: enable ST7789 display and touch panel r=benpicco a=gschorcht
### Contribution description
This PR enables the ST7789 display and the touch panel for the `stm32l496g-disco`.
The PR requires PR #19937.
### Testing procedure
```
BOARD=stm32l496g-disco make -j8 -C tests/drivers/st77xx
```
should work.
### Issues/PRs references
Depends on PR #19937
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19937: drivers/lcd: add MCU 8080 16-bit parallel mode support r=benpicco a=gschorcht
### Contribution description
This PR adds the 16-bit support for MCU 8080 parallel mode for LCD driver ICs.
### Testing procedure
Use either PR #19938
```
BOARD=stm32l496g-disco make -j8 -C tests/drivers/st77xx
```
or #19939 on top of this PR to test.
```
BOARD=sstm32f723e-disco make -j8 -C tests/drivers/st77xx
```
### Issues/PRs references
Prerequisite for PR #19938 or PR #19938
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19927: sys/shell/ping: fix ping packet size overflow r=miri64 a=krzysztof-cabaj
### Contribution description
In #19829 `@mchesser` point out integer overflow in the ```ping``` command and API. This PR fix this issue in two ways:
1) Add protection in the API.
2) Add protection in the user command.
### Testing procedure
Without this PR passing negative number to the ```ping -s``` option cause segmentation fault, for example in the
```example/gnrc_networking```:
```
> ping -s -7 ::1
ping -s -7 ::1
Segmentation fault
```
With this PR user shows appropriate warning test:
```
> ping -s -7 ::1
ping -s -7 ::1
ICMPv6 datagram size should be in range <0, 65527>.
>
```
### Issues/PRs references
Issue #19829
Co-authored-by: krzysztof-cabaj <kcabaj@gmail.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.
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>
