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.
- 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.
This adds the three general purpose timers on STM32L4 boards in a
central place so that STM32L4 boards can just include it.
Some other families may also have TIM15 and TIM16 and could use this,
but likely some generalization is needed to use this for other
families as well. This can be added later on.
Provide a common clock initialization driver rather than leaving
clock initialization to the boards code. A declarative description of
the board's clock configuration using a struct does still allow to
fine-tune settings. In addition, a board is still allowed to just
provide a custom `void clock_init(void)` if there really is the need
to do crazy things.
19447: boards/nucleo-f429zi: Provide 2nd timer r=benpicco a=maribu
### Contribution description
- Add a common timer config with two (instead of only one) timer using TIM2 + TIM5
- Mostly copy-pasting the cfg_timer_tim2.h and cfg_timer_tim5.h together
- Make use of that for the `nucleo-f429zi`
### Testing procedure
E.g. `tests/periph_timer`, but also grepping for TIM2 and TIM5 in `boards/nucleo-f429zi/include/periph_conf.h` to detect any conflict e.g. between PWM and timer config.
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
The board uses the USB OTG HS peripheral together with the on-hip FS PHY. Using the `periph_usbdev_hs` module increases the EP data size for the CDC ECM bulk endpoint to 512 bytes, which does not work for the FS interface. Module `periph_usbdev_hs` is therefore not used.
The commit moves the header files from `boards/common/esp32s3/include` that can be used for all types of ESP32x SoCs to a new common ESP32x board module.
19256: pkg/tinyusb: add GD32VF103 support r=gschorcht a=gschorcht
### Contribution description
This PR provides the tinyUSB support for GD32VF103 and enables the `tinyusb_device` feature as well as `stdio_tinyusb_cdc_acm` for GD32VF103 boards.
### Testing procedure
```
BOARD=sipeeed-longan-nano make -C tests/shell flash term
```
should work
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19240: tools/doccheck: add simple exclude to doccheck r=benpicco a=kfessel
while doccheck runs for #19228 and #19220, i saw some spikes in memory consumption, turned out that was `grep -Evf dist/tools/doccheck/exclude_patterns` using about 2GB RAM. This PR changes that.
### Contribution description
add `exclude_simple` to `doccheck` drived from `exclude patterns`
`sort`ed and `uniq`ued the simple excludes
removes no longer needed patterns from `exclude patterns`
simple excludes are string rules (no patterns just strings)
how to apply these:
in this PR:
*remove the path and line number from the rule
* that made some of them doubles of each other
* sorted and uniqued them.
* this set of excludes is no longer path specific (an exception covers all paths but may of them still contain a file name)
another possible solution would be to have the excludes line number specific.
### Testing procedure
run `dist/tools/doccheck/check.sh`
compare memory consumption of
master: `grep -Evf dist/tools/doccheck/exclude_patterns`
to
this PR: `grep -Fvf dist/tools/doccheck/exclude_simple`
### Issues/PRs references
19248: cpu/gd32v: add periph_dac support r=benpicco a=gschorcht
### Contribution description
This PR provides the `periph_dac` support for GD32VF103.
### Testing procedure
`tests/periph_dac` should work on `sipeed-longan-nano` port on PA4 and PA5.
### Issues/PRs references
19255: boards/esp*: complete SD Card MTD config r=benpicco a=gschorcht
### Contribution description
This PR provides the remaining changes necessary to use the generic MTD SD Card configuration as described in PR #19216.
This includes defining the MTD offset for SD cards, since the default `MTD_0` device always uses the internal flash device, and the completion of the configuration for the ESP32 boards with a SD card interface.
### Testing procedure
`tests/vfs_default` should work now with SD Cards:
```
main(): This is RIOT! (Version: 2023.04-devel-323-gfcc07)
mount points:
/nvm0
/sd0
data dir: /sd0
> vfs df
Mountpoint Total Used Available Use%
/nvm0 3052 KiB 8 KiB 3044 KiB 0%
/sd0 7580 MiB 3632148992 B 21089792 B 99%
```
### Issues/PRs references
Co-authored-by: Karl Fessel <karl.fessel@ovgu.de>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19249: boards/gd32v: improve board definitions r=benpicco a=gschorcht
### Contribution description
This PR provides some small improvements of the existing board definitions for GD32VF103 boards for more flexibel default configurations and documentation of the board peripherals:
- Allow the remapping of SPI0 pins in SPI configuration (ae984b0bea)
- More flexible I2C configuration (0c337583b4)
The default I2C device configuration allows to define up to two I2C devices `I2C_DEV(0)` and `I2C_DEV(1)`. `I2C_DEV(0)` is always defined if the I2C peripheral is enabled by the module `periph_spi`. The second I2C device `I2C_DEV(1)` is only defined if `I2C_DEV_1_USED` is defined by the board. This allows to use the default configuration with one or two I2C devices depending on whether other peripherals are enabled that would collide with the I2C devices.
- More flexible SPI configuration (edbf59e37e)
The default SPI device configuration allows to define up to two SPI devices `SPI_DEV(0)` and `SPI_DEV(1)`. `SPI_DEV(0)` is always defined if the SPI peripheral is enabled by the module `periph_spi`. The second SPI device `SPI_DEV(1)` is only defined if `SPI_DEV_1_USED` is defined by the board. This allows to use the default configuration with one or two SPI devices depending on whether other peripherals are enabled that would collide with the SPI devices.
Furthermore, the CS signal in the SPI configuration is given by a define that can be overriden with another pin if
the default CS signal is connected to an unused hardware.
- Improve ADC config for Sipeed-Longan-Nano (c9c587ee00)
The ADC configuration was too complex. It was hard to follow when certain ADC lines are available. Furthermore, the order of ADC lines did depend on the use of other peripherals. Now, either the TFT display is not connected and all ADC lines are available or the TFT display is connected and the second SPI device is used so that only the first 4 ADC lines are available.
- Improve Kconfig for Sipeed-Longan-Nano (025f4fdf00)
Board-specific configuration not shown any longer directly in the top level menu but within a submenu.
- Improve peripherals documentation (7f0d560dd8, e24abe495a)
Available peripherals for the board are now documented in two tables ordered by RIOT peripheral names and by pins.
Although the different changes are small and mostly related to the documentation, I could split the PR if necessary.
### Testing
Green CI
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
After a reset, it can take several seconds before the CDC ACM interface becomes available as serial device `ttyACMx`. This was a change that was already made for `stdio_cdc_acm` in #19128.
The default SPI device configuration allows to define up to two SPI devices `SPI_DEV(0)` and `SPI_DEV(1)`. `SPI_DEV(0)` is always defined if the SPI peripheral is enabled by the module `periph_spi`. The second SPI device `SPI_DEV(1)` is only defined if `SPI_DEV_1_USED` is defined by the board. This allows to use the default configuration with one or two SPI devices depending on whether other peripherals are enabled that would collide with the SPI devices.
Furthermore, the CS signal in the SPI configuration is given by a define that can be overriden with another pin if
the default CS signal is connected to an unused hardware.
The default I2C device configuration allows to define up to two I2C devices `I2C_DEV(0)` and `I2C_DEV(1)`. `I2C_DEV(0)` is always defined if the I2C peripheral is enabled by the module `periph_spi`. The second I2C device `I2C_DEV(1)` is only defined if `I2C_DEV_1_USED` is defined by the board. This allows to use the default configuration with one or two I2C devices depending on whether other peripherals are enabled that would collide with the I2C devices.
16782: drivers/mfrc522: add new driver r=benpicco a=HendrikVE
### Contribution description
This PR adds support for the MFRC522. It is quite common in the Arduino world and it is quite cheap. The driver connects to the MFRC522 via SPI and is heavily based on the Arduino driver available [here](https://github.com/miguelbalboa/rfid). Basically it was ported, but with several improvements in readability and documentation.
### Testing procedure
The given (manual) test provides single commands for some driver functions.
19201: cpu/gd32v: add periph_i2c support r=benpicco a=gschorcht
### Contribution description
This PR provides the `periph_i2c` support and is one of a bunch of PRs that complete the peripheral drivers for GD32VF103.
The driver is a modified version of the driver for STM32F1 with some changes that were necessary to get it working on GD32V. As for STM32F1, the driver is using polling instead of interrupts for now. It will be implemented interrupt-driven later.
### Testing procedure
`tests/periph_i2c` as well as a test with any I2C sensor should work. The driver was tested with `tests/driver_l3gxxxx` and `tests/driver_bmp180`.
### Issues/PRs references
Co-authored-by: Hendrik van Essen <hendrik.ve@fu-berlin.de>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
The default timer configuration has been changed so that `TIMER0` and `TIMER1` are always timer devices. `TIMER2` can only be used as timer device if it is not used for PWM devices. `TIMER3` and `TIMER4` are only available as timer devices if they are supported by the CPU model and not used for PWM devices.
19199: sys/suit: Ensure previous thread is stopped before reusing its stack r=benpicco a=chrysn
### Contribution description
Closes: https://github.com/RIOT-OS/RIOT/issues/19195
If the thread has released the mutex but the thread has not terminated (which happens in the situation that would previously have overwritten a still active thread's state), then a warning is shown and the trigger is ignored.
### Testing procedure
This should work before and after:
* `make -C examples/suit_update BOARD=native all term`
* `aiocoap-client coap://'[fe80::3c63:beff:fe85:ca96%tapbr0]'/suit/trigger -m POST --payload 'coap://[2001:db8::]/foo'`
* In parallel, on the RIOT shell, run `suit fetch coap://[2001:db8::]/foo`
* After the first download fails, the second one starts right away ("suit_worker: update failed, hdr invalid" / "suit_worker: started").
Run again with the worker thread on low priority:
```patch
diff --git a/sys/suit/transport/worker.c b/sys/suit/transport/worker.c
index a54022fb28..e26701a64c 100644
--- a/sys/suit/transport/worker.c
+++ b/sys/suit/transport/worker.c
`@@` -70 +70 `@@`
-#define SUIT_COAP_WORKER_PRIO THREAD_PRIORITY_MAIN - 1
+#define SUIT_COAP_WORKER_PRIO THREAD_PRIORITY_MAIN + 1
```
Before, this runs the download once silently (no clue why it doesn't run it twice, but then again, I claim there's concurrent memory access from two thread, so who knows what happens). After, it runs a single download and shows an error message for the second one once the first is complete ("Ignoring SUIT trigger: worker is still busy.").
### Issues/PRs references
This may be made incrementally easier by https://github.com/RIOT-OS/RIOT/pull/19197 -- that PR as it is now would spare us the zombification (because returning would do that), and having a `wait` function would allow us to turn the new error case into a success.
19205: boards/common: add common timer config for GD32VF103 boards r=benpicco a=benpicco
19207: examples/gnrc_border_router: static: use router from advertisements by default r=benpicco a=benpicco
Co-authored-by: chrysn <chrysn@fsfe.org>
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
19050: boards/common/cc26xx cc13xx: clean up and fix flash configs r=benpicco a=maribu
### Contribution description
- Add support for XDS110 debugger via `OPENOCD_DEBUG_ADAPTER=xds110`
- Clean up OpenOCD configs in `boards/common/cc26xx_cc13xx`
- No longer hardcode the debugger to xds110, but use `OPENOCD_DEBUG_ADATER ?= xds110`
- Add support for cc13x0, cc13x2, cc26x0
- `boards/cc2650*`: drop custom OpenOCD config in favor of shared one
- add variables needed to support flashing with `PROGRAMMER=jlink`
- allow specifying a custom OpenOCD command to bring the device to a halt state, as the default `reset halt` (which causes a second reset) is causing issues with the ICEPick JTAG routers in the CC26xx - CC13xx devices
- Use `halt` instead of `reset halt` for CC26xx / CC13xx boards in OpenOCD to avoid issues in flashing
### Testing procedure
```
make BOARD=cc2650-launchpad -C examples/default flash
```
Should now work. The same should still work for other cc26xx cc13xx boards.
### Issues/PRs references
Partially fixes: https://github.com/RIOT-OS/RIOT/issues/18750
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Place common OpenOCD configs for the different cc13xx and cc26xx
families in boards/common/cc26xx_cc13xx/dist and automatically select
the correct one based on the (prefix of the) value of `$(CPU_MODEL)`, if
`OPENOCD_CONFIG` was not specified and no custom `openocd.cfg` is
located in the board's `dist` folder.
The `cc2650-launchpad` and `cc2650stk` have been adapted to use the
common config instead.
- document that the QN9080DK has an alternative firmware for the
debugger/programmer that supports J-Link
- allow selecting the debugger firmware via parameter / environment
variable
- add `JLINK_DEVICE` parameter to allow flashing via J-Link
For nRF52 J-Link was intended to be preferred as programmer over OpenOCD
when both are available, but falling back to OpenOCD when JLinkExe is
not found in `$PATH`. However, there was call the shell missing to
actually detect `JLinkExe`.
