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>
19789: cpu/nrf5x/periph/wdt: enable support for nRF53/nRF9160 r=benpicco a=dylad
### Contribution description
This PR enables support for the watchdog driver on nRF53.
This MCU has two watchdog peripherals, for now, it only uses the first one.
The use of the second watchdog can be add in a followup PR later.
### Testing procedure
Flash and play with `tests/periph/wdt` application.
### Issues/PRs references
None.
19796: boards/b_u585i_ iot02a/periph usbdev r=benpicco a=gschorcht
### Contribution description
This PR adds the USB OTG support for STM32U5 and the `b_u585i_iot02a` board.
This PR includes PR #19795 since it uses directly the changes made in PR #19795.
### Testing procedure
Compile and flash
```
BOARD=b-u585i-iot02a make -C tests/sys/usbus_cdc_ecm/ flash term
```
Use the `sudo dmesg` command to get the kernel messages.
```pyhon
[766948.556645] usb 1-2.2: new full-speed USB device number 108 using xhci_hcd
[766948.658688] usb 1-2.2: New USB device found, idVendor=1209, idProduct=7d00, bcdDevice= 1.00
[766948.658696] usb 1-2.2: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[766948.658699] usb 1-2.2: Product: b-u585i-iot02a
[766948.658702] usb 1-2.2: Manufacturer: RIOT-os.org
[766948.658704] usb 1-2.2: SerialNumber: AA140057DA41D467
[766948.668681] cdc_ether 1-2.2:1.0 usb0: register 'cdc_ether' at usb-0000:00:14.0-2.2, CDC Ethernet Device, ea:dc:44:71:d9:24
[766948.743250] cdc_ether 1-2.2:1.0 enxeadc4471d924: renamed from usb0
```
Use the `ifconfig` command on the node to determine the IPv6 LLUA and ping the node.
```
ping6 -c 3 fe80::e8dc:44ff:fe71:c524%enxeadc4471d924
PING fe80::e8dc:44ff:fe71:c524%enxeadc4471d924(fe80::e8dc:44ff:fe71:c524%enxeadc4471d924) 56 data bytes
64 bytes from fe80::e8dc:44ff:fe71:c524%enxeadc4471d924: icmp_seq=1 ttl=64 time=0.523 ms
64 bytes from fe80::e8dc:44ff:fe71:c524%enxeadc4471d924: icmp_seq=2 ttl=64 time=0.546 ms
64 bytes from fe80::e8dc:44ff:fe71:c524%enxeadc4471d924: icmp_seq=3 ttl=64 time=0.599 ms
```
### Issues/PRs references
Includes PR #19795
19802: cpu/nrf53: enable flashpage support r=benpicco a=dylad
### Contribution description
This PR enables flashpage support on nRF53 family.
The peripheral is identical to nRF52, just add the flashpage configuration and enable the module in both Makefiles.features and Kconfig.
### Testing procedure
run `/tests/periph/flashpage` on `nrf5340dk-app`
output of `make BOARD=nrf5340dk-app flash test`
```
/home/dylan/work/RIOT/dist/tools/pyterm/pyterm -p "/dev/ttyACM0" -b "115200" --no-reconnect --noprefix --no-repeat-command-on-empty-line
Twisted not available, please install it if you want to use pyterm's JSON capabilities
Connect to serial port /dev/ttyACM0
Welcome to pyterm!
Type '/exit' to exit.
>
>
test_last_raw
> test_last_raw
wrote raw short buffer to last flash page
> help
help
Command Description
---------------------------------------
info Show information about pages
dump Dump the selected page to STDOUT
dump_local Dump the local page buffer to STDOUT
read Copy the given page to the local page buffer and dump to STDOUT
write Write the local page buffer to the given page
write_raw Write (ASCII, max 64B) data to the given address
erase Erase the given page buffer
edit Write bytes to the local page buffer
test Write and verify test pattern
test_last_pagewise Write and verify test pattern on last page available
test_last_pagewise
test_reserved_pagewise Write and verify short write on reserved page
test_last_raw Write and verify raw short write on last page available
> test_last_pagewise
wrote local page buffer to last flash page
> help
help
Command Description
---------------------------------------
info Show information about pages
dump Dump the selected page to STDOUT
dump_local Dump the local page buffer to STDOUT
read Copy the given page to the local page buffer and dump to STDOUT
write Write the local page buffer to the given page
write_raw Write (ASCII, max 64B) data to the given address
erase Erase the given page buffer
edit Write bytes to the local page buffer
test Write and verify test pattern
test_last_pagewise Write and verify test pattern on last page available
test_reserved_pagewise Write and verify short write on reserved page
test_reserved_pagewise
test_last_raw Write and verify raw short write on last page available
> test_reserved_pagewise
Reserved page num: 5
Since the last firmware update this test has been run 0 times
wrote local page buffer to reserved flash page
When running on a bootloader, as an extra check, try restarting the board and check whether this application still comes up.
> help
help
Command Description
---------------------------------------
info Show information about pages
dump Dump the selected page to STDOUT
dump_local Dump the local page buffer to STDOUT
read Copy the given page to the local page buffer and dump to STDOUT
write Write the local page buffer to the given page
write_raw Write (ASCII, max 64B) data to the given address
erase Erase the given page buffer
edit Write bytes to the local page buffer
test Write and verify test pattern
test_last_pagewise Write and verify test pattern on last page available
test_reserved_pagewise Write and verify short write on reserved page
test_last_raw Write and verify raw short write on last page available
>
make : on quitte le répertoire « /home/dylan/work/RIOT/tests/periph/flashpage »
```
### Issues/PRs references
None.
19803: cpu/nrf5x_common: rework LFCLK source selection r=benpicco a=dylad
### Contribution description
This PR changes the source selection of LFCLK for all nRF families.
This idea is to use the values provided by Nordic vendor files to properly populate the source of the LFCLK. Then setup a per CPU check to ensure the value provided at board level is fine. In the end, the LFCLK source selection is a mere assignment.
The selection of the LFCLK source is still done at board level. I also add a bit of documentation to help users to select another value if needed.
I'll provide in a followup PR, `periph_rtt` support for both nRF9160 and nRF53.
### Testing procedure
CI should be enough I think. Otherwise, one can ran tests/periph/rtt on any nRF51-based board and any nRF52-based board.
You can also change the LFCLK source at board level to ensure the guards are doing their jobs.
### Issues/PRs references
None.
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19733: cpu/msp430: reorganize code r=maribu a=maribu
### Contribution description
RIOT supports two distinct families of the MSP430: The [MSP430 x1xx] MCU family and the [MSP430 F2xx/G2xx] MCU family. For both incompatible MCU families the code was located in the msp430fxyz folder, resulting in case of the UART driver in particularly bizarre code looking roughly like this:
```C
#ifndef UART_USE_USCI
/* implementation of x1xx peripheral ... */
#else
/* implementation of F2xx/G2xx peripheral ... */
#endif
/* zero shared code between both variants */
```
This moves peripheral drivers shared between the two families to msp430_common and splits the SPI and UART driver into two MCU families.
In addition, it cleans up the `msp430_regs.h` by dropping most of it and using the macros and symbols provided by the vendor header files. There is little reason for us to maintain constants when TI is already doing that.
[MSP430 x1xx]: https://www.ti.com/lit/ug/slau049f/slau049f.pdf
[MSP430 F2xx/G2xx]: https://www.ti.com/lit/ug/slau144k/slau144k.pdf
19747: gnrc/ipv6/nib: reset rs_sent counter also for not-6LN interfaces r=maribu a=fabian18
19769: cpu/nrf53: add initial support with nRF5340DK-APP board r=maribu a=dylad
### Contribution description
This PR adds support for nRF5340 MCU and its associated Nordic development board, nRF5340DK.
This MCU provides a dual Cortex-M33, one application core running at up to 128MHz, and one network core running at up to 64MHz.
Peripherals are inherited from others Nordic MCUs families so it shouldn't be hard to add more of them in followup PRs.
For now, only the minimal set of peripherals is supported:
- GPIO / GPIO_IRQ
- UART
- TIMER
### Testing procedure
Build the usual test application for the supported peripherals and flash the board.
nRF5340DK provides two serial ports on its embedded debugger. RIOT's shell should be available on the first one (/dev/ttyACM0)
### Issues/PRs references
#18576#19267
19782: cpu/msp430: fix for ti's msp430-gcc-opensource package ld version r=maribu a=hugueslarrive
### Contribution description
My msp430 toolchain (https://www.ti.com/tool/MSP430-GCC-OPENSOURCE) was broken by #19484:
```
hugues@p700:~/github/cpu_msp430_common/RIOT$ BOARD=msb-430 make -j64 -C examples/hello-world
make : on entre dans le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
Building application "hello-world" for "msb-430" with MCU "msp430fxyz".
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core/lib
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers/periph_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/auto_init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/div
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/libc
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/malloc_thread_safe
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/newlib_syscalls_default
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz/periph
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/preprocessor
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/stdio_uart
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common/periph
/opt/ti/msp430-gcc/bin/../lib/gcc/msp430-elf/9.3.1/../../../../msp430-elf/bin/ld: .rodata not found for insert
collect2: error: ld returned 1 exit status
make: *** [/home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world/../../Makefile.include:761 : /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world/bin/msb-430/hello-world.elf] Erreur 1
make : on quitte le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
hugues@p700:~/github/cpu_msp430_common/RIOT$ /opt/ti/msp430-gcc/msp430-elf/bin/ld --version
GNU ld (Mitto Systems Limited - msp430-gcc 9.3.1.11) 2.34
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
hugues@p700:~/github/cpu_msp430_common/RIOT$ /opt/ti/msp430-gcc/msp430-elf/bin/ld --version | grep -Eo '[0-9]\.[0-9]+'
9.3
1.11
2.34
hugues@p700:~/github/cpu_msp430_common/RIOT$ /opt/ti/msp430-gcc/msp430-elf/bin/ld --version | grep -Eo '[0-9]\.[0-9]+$'
2.34
```
### Testing procedure
```
hugues@p700:~/github/cpu_msp430_common/RIOT$ BOARD=msb-430 make -j64 -C examples/hello-world
make : on entre dans le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
Building application "hello-world" for "msb-430" with MCU "msp430fxyz".
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core/lib
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers/periph_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/auto_init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/div
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/libc
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/malloc_thread_safe
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/newlib_syscalls_default
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/preprocessor
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/stdio_uart
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz/periph
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common/periph
text data bss dec hex filename
8612 722 866 10200 27d8 /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world/bin/msb-430/hello-world.elf
make : on quitte le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
```
### Issues/PRs references
Introduced by #19484, highlighted in #16727.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
Co-authored-by: Fabian Hüßler <fabian.huessler@ml-pa.com>
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Co-authored-by: Hugues Larrive <hlarrive@pm.me>
The correct macro name is `ARDUINO_I2C_UNO` for Arduino UNO compatible
I2C bus location, or `ARDUINO_I2C_NANO` for Arduino Nano compatible
I2C bus location.
Rather than providing this for every board (or group of boards)
individually, it is better to provide this once relying on the Arduino
I/O mapping features.
- 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.
RIOT supports two distinct families of the MSP430: The [MSP430 x1xx]
MCU family and the [MSP430 F2xx/G2xx] MCU family. For both incompatible
MCU families the code was located in the msp430fxyz folder, resulting
in case of the UART driver in particularly bizarre code looking roughly
like this:
#ifndef UART_USE_USCI
/* implementation of x1xx peripheral ... */
#else
/* implementation of F2xx/G2xx peripheral ... */
#endif
/* zero shared code between both variants */
This splits the peripheral drivers for USCI and USART serial IP blocks
into separate files and relocates everything in cpu/msp430, similar to
how cpu/stm32 is organized.
[MSP430 x1xx]: https://www.ti.com/lit/ug/slau049f/slau049f.pdf
[MSP430 F2xx/G2xx]: https://www.ti.com/lit/ug/slau144k/slau144k.pdf
