The Arduino Zero based boards already provided the feature
`arduino_spi`, but were missing the corresponding mapping. This fixes
the issue by adding the SPI bus numbers for the ISP SPI bus and the
D11D12D13 SPI bus.
(And in order to actually add the D11D12D13 SPI bus, the `periph_conf.h`
was extended to provide an SPI configuration for it.)
This fixes a race in `LED<NUM>_TOGGLE`, which is a read-copy-write
operation. Any access to a GPIO pin on the same GPIO port that
happens concurrently could result in data corruption. Using the
GPIO LL API, which is thread-safe, fixes the issue.
Note: The used GPIO LL functions will work even in when the GPIO LL
module is not used.
The API was based on the assumption that GPIO ports are mapped in memory
sanely, so that a `GPIO_PORT(num)` macro would work allow for constant
folding when `num` is known and still be efficient when it is not.
Some MCUs, however, will need a look up tables to efficiently translate
GPIO port numbers to the port's base address. This will prevent the use
of such a `GPIO_PORT(num)` macro in constant initializers.
As a result, we rather provide `GPIO_PORT_0`, `GPIO_PORT_1`, etc. macros
for each GPIO port present (regardless of MCU naming scheme), as well as
`GPIO_PORT_A`, `GPIO_PORT_B`, etc. macros if (and only if) the MCU port
naming scheme uses letters rather than numbers.
These can be defined as macros to the peripheral base address even when
those are randomly mapped into the address space. In addition, a C
function `gpio_port()` replaces the role of the `GPIO_PORT()` and
`gpio_port_num()` the `GPIO_PORT_NUM()` macro. Those functions will
still be implemented as efficient as possible and will allow constant
folding where it was formerly possible. Hence, there is no downside for
MCUs with sane peripheral memory mapping, but it is highly beneficial
for the crazy ones.
There are also two benefits for the non-crazy MCUs:
1. We can now test for valid port numbers with `#ifdef GPIO_PORT_<NUM>`
- This directly benefits the test in `tests/periph/gpio_ll`, which
can now provide a valid GPIO port for each and every board
- Writing to invalid memory mapped I/O addresses was treated as
triggering undefined behavior by the compiler and used as a
optimization opportunity
2. We can now detect at compile time if the naming scheme of the MCU
uses letters or numbers, and produce more user friendly output.
- This is directly applied in the test app
The ESP32 Ethernet Kit has only a single GPIO pin exposed to SAUL via
`saul_gpio`, but that GPIO doubles as PHY clock input when `esp32_eth`
is used. Hence, the `saul_gpio` dep should be optional and only kick
in when `esp32_eth` is not used.
This gets rid of a long list of boards with network interfaces and
instead let's boards (or MCUs with peripheral network interfaces)
provide the netif feature.
The apps that before used the long list are not depending on the
feature instead (in case of the default example, this is an
optional dependency).
Co-authored-by: mguetschow <mikolai.guetschow@tu-dresden.de>
Co-authored-by: mewen.berthelot <mewen.berthelot@orange.com>
This fixes compilation issues in `tests/pkg/tinyusb_netdev` with
newer versions of the RISC-V toolchain due to two competing USB
stacks being pulled in. With the older toolchain the build system
warns:
The following features may conflict: periph_usbdev tinyusb_device
But builds fine (even though surprises at runtime are likely). The
newer toolchain takes an issue with the same symbol being linked
in more than once (and more than one instance not being `weak`).
C has this feature that the order of struct members in the
initialization doesn't need to match the order in the declaration.
C++ has not yet caught up:
boards/common/gd32v/include/cfg_usbdev_default.h:50:1: error: designator order for field 'dwc2_usb_otg_fshs_config_t::type' does not match declaration order in 'const dwc2_usb_otg_fshs_config_t'
So, just reorder the fields for now by hand.
The `SWJ_CFG` field of the `AFIO_MAPR` register is write only and values
read are undefined (random). Hence, using `AFIO->MAPR |= mask;` to
enable flags can corrupt the state of the `SWJ_CFG` (configure it to
an unintended value).
Two helper functions have been introduced:
- `afio_mapr_read()` reads the value, but sanitizes the `SWJ_CFG` field
to zero
- `afio_mapr_write()` writes the given value, but applies the `SWJ_CFG`
configured by the board before writing.
Finally, the `nucleo-f103rb` and `bluepill*`/`blackpill*` boards have
been updated to no longer specify `STM32F1_DISABLE_JTAG`, as this
is handled by the `SWJ_CFG` setting (which defaults to disabling JTAG).
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>
This commit includes the following cleanups:
- The macros `I2C_DEV_1_USED` and `SPI_DEV_1_USED` are now used with the values 0 and 1. This allows to enable but also to disable the second interface even if the board definition enables it by default.
- The second I2C device `I2C_DEV(1)` and the second SPI device `SPI_DEV(1)` are now disabled by default.
- The second SPI device `SPI_DEV(1)` now uses PB5 as default CS signal instead of PA4 to keep PA4 free for ADC or DAC even if `SPI_DEV(1)` is used, for example for the TFT display.
19764: drivers/shield_w5100: add module for the W5100 Ethernet Shield r=benpicco a=maribu
### Contribution description
This module provides no more than the correct configuration parameters for the `w5100` driver using the Arduino I/O mapping features. But by doing so, it will work out of the box with every mechanically and electrically compatible board for which the Arduino I/O mapping features are implemented.
19781: cpu/nrf{53,9160}: add pwm support r=benpicco a=dylad
### Contribution description
This PR moves the nRF52 PWM driver to `cpu/nrf5x_common` to allow nRF9160 and nRF53 to use this driver.
IP is identical on these families.
I didn't test on nRF9160DK and I didn't test if there is any regression on nRF52-based board as I don't have any so tests are welcome !
However it works fine on nRF53-based board.
### Testing procedure
Flash the `tests/periph/pwm` test application on `nrf5340dk` or `nrf9160dk`.
You can then use the `osci` command to make the onboard LEDs "breath".
You can also attach an oscilloscope and/or logic analyzer to watch the signal.
### Issues/PRs references
~~Based on #19769~~
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Co-authored-by: dylad <dylan.laduranty@mesotic.com>
