- Move common code for USART (shared SPI / UART peripheral) to its
own file and allow sharing the USART peripheral to provide both
UART and SPI in round-robin fashion.
- Configure both UART and SPI bus via a `struct` in the board's
`periph_conf.h`
- this allows allocating the two UARTs as needed by the use case
- since both USARTs signals have a fixed connection to a single
GPIO, most configuration is moved to the CPU
- the board now only needs to decide which bus is provided by
which USART
Note: Sharing an USART used as UART requires cooperation from the app:
- If the UART is used in TX-only mode (no RX callback), the driver
will release the USART while not sending
- If the UART is used to also receive, the application needs to power
the UART down while not expecting something to send. An
`spi_acquire()` will be blocked while the UART is powered up.
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.
Revision 10199-V1.0 of the board has an incorrect pin labeling on the
silkscreen, presumably because the board was initially developed
for a different E180 module and the silkscreen was not updated when
populated with a different E180 module.
It is very likely that if newer revisions of the test board get
produced, they will use the same very systematical routing as revision
1.0 and only the silkscreen labeling will be fixed. Hence, documenting
the correct pin mapping will be useful even for newer revisions.
The CC2538-CC2592-DK is one of the few readily available and
affordable boards featuring a legacy CC2538 MCU. This should make
maintaining RIOT support for that legacy MCU more affordable :-)
Fix flashing with `MOST_RECENT_PORT=1` by detecting the board when
either in RIOT mode or in bootloader mode (which matches different
USB vendor and model strings).
Support for programming with the nrf52-u2f bootloader was dropped
apparently, but the documentation still recommends that over the
Arduino Bootloader. This brings doc and code in sync.
- add support for multiple timers
- add support for selecting clock source in the board's `periph_conf.h`
- add support for the prescaler
- implement `periph_timer_query_freqs`
- add a second timer to all MSP430 boards
- the first timer is fast ticking, high-power
- the second is slow ticking, low-power
When using `make flash` or `make term` with `MOST_RECENT_PORT=1`, RIOT
should now only consider plausible TTYs and select the most recently
connected one. The filter is a bit broad, though, and will match
any board with a CH430 UART2USB bridge. But depending on the boards
attached, it might be good enough to reliably tell it apart from
other boards.
When using `make flash` or `make term` with `MOST_RECENT_PORT=1`, RIOT
should now only consider plausible TTYs and select the most recently
connected one. The filter is a bit broad, though, and will match
any board with a CH430 USB 2.0 UART2USB bridge. But depending on the
boards attached, it might be good enough to reliably tell it apart from
other boards.
When using `make flash` or `make term` with `MOST_RECENT_PORT=1`, RIOT
should now only consider plausible TTYs and select the most recently
connected one. The filter is a bit broad, though, and will match
any board with a CP2104 USB2UART bridge. But depending on the boards
attached, it might be good enough to reliably tell it apart from other
boards.
When using `make flash` or `make term` with `MOST_RECENT_PORT=1`, RIOT
should now only consider plausible TTYs and select the most recently
connected one. The filter is a bit broad, though, and will match
any board with a CP2102N USB2UART bridge. But depending on the boards
attached, it might be good enough to reliably tell it apart from other
boards.
When using `make flash` or `make term` with `MOST_RECENT_PORT=1`, RIOT
should now only consider plausible TTYs and select the most recently
connected one. The filter is a bit broad, though, and will match
any board with a CP2102 USB2UART bridge. But depending on the boards
attached, it might be good enough to reliably tell it apart from other
boards.
When using `make flash` or `make term` with `MOST_RECENT_PORT=1`, RIOT
should now select relatively robustly the most recently connected
ESP32 Ethernet Kit / ESP32 Wrover Kit board, even with other TTYs
present. This is because the FTDI Dual RS232-HS with two USB2UART
bridges in the chip would be an expensive overkill for most boards,
unless one is using the FTDI chip to big-bang JTAG as well - as done
on the Ethernet Kit and Wrover Kit boards.
The board have one user button and a user led but are not enabled.
This add necessary support to use the button and the led. It include
the configs to use with SAUL and button interrupt.
Signed-off-by: Gerson Fernando Budke <nandojve@gmail.com>
- nRF51: Use `uart_conf_t` for consistency with nRF52
- nRF52832: Use UARTE (UART with EasyDMA) over UART (without DMA), as
done for all other nRF52 family members
- use `UARTE_PRESENT` to detect whether an UARTE can be used, rather
than family names
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).
The macro `ARDUINO_SPI_D11D12D13` is used to refer to the SPI bus
on the pins D11/D12/D13 on Arduino UNO compatible boards. For all
Nucleo64 boards this is `SPI_DEV(0)`, but for this board `SPI_DEV(0)`
is internally connected to the radio. Instead `SPI_DEV(1)` is connected
to the correct pins. This provides the macro explicitly in
`periph_conf.h`, which takes preference over the fallback in
`boards/common/nucleo64` when provided.
20003: coap: create typedef for CoAP methods r=benpicco a=benpicco
20028: nanocoap: fix incorrect uses of coap_get_code() r=benpicco a=benpicco
20036: boards/nucleo-l4r5zi : add PWM configuration r=benpicco a=krzysztof-cabaj
### Contribution description
This PR adds to the Nucleo-l4r5zi PWM configuration
### Testing procedure
Flash the board using `tests/periph/pwm` program. Check if you could, for example, change LED
intensity using PWM.
### Issues/PRs references
None.
20041: pkg/littlefs2: bump to v2.8.1 r=benpicco a=bergzand
### Contribution description
Minor version number bump.
### Testing procedure
- Check if I copied the correct commit hash.
- Run the tests.
### Issues/PRs references
None
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: krzysztof-cabaj <kcabaj@gmail.com>
Co-authored-by: Koen Zandberg <koen@bergzand.net>
