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>
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>
Typically, OpenOCD is already performing a reset on connect. A
`reset halt` to bring the target to a `halt` state for flashing will
result in the device going through a second reset cycle. This can be
problematic with some device, such as the CC26xx MCUs. For these
devices, an `OPENOCD_CMD_RESET_HALT := -c 'halt'` will avoid the second
reset that is causing the issues.
19099: dist/tools/usb-serial: Clean up legacy scripts r=aabadie a=maribu
### Contribution description
Refactor the old bash scripts to use `ttys.py` instead and update the documentation.
### Testing procedure
The pi fleet should still work without modification.
### Issues/PRs references
Fixes https://github.com/RIOT-OS/RIOT/issues/15814
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
This commits add documentation to the HDC1000 params and adds generic
exclude patters to the doc check, so that when boards provide custom
HDC1000 params they do not need to document them again. The reasoning
is that the documentation in the central place is sufficient.
This commits add documentation to the FXOS8700 params and adds generic
exclude patters to the doc check, so that when boards provide custom
FXOS8700 params they do not need to document them again. The reasoning
is that the documentation in the central place is sufficient.
In addition, a generic exclude patter is added to match FXOS8700_REG_*,
as the register names are relatively self-explaining and an
implementation detail of the driver that doesn't need public
documentation.
This commits add documentation to the AT86RF2xx params and adds generic
exclude patters to the doc check, so that when boards provide custom
AT86RF2xx params they do not need to document them again. The reasoning
is that the documentation in the central place is sufficient.
Add generic patterns to allow XTIMER_DEV, XTIMER_HZ, XTIMER_WIDTH,
XTIMER_CHAN, XTIMER_BACKOFF, and XTIMER_ISR_BACKOFF to be undocumented.
The reasoning is that having them documented once is enough and warnings
for missing doc in every boards is just noise.
This commits add documentation to the TMP00X params and adds generic
exclude patters to the doc check, so that when boards provide custom
TMP00X params they do not need to document them again. The reasoning is
that the documentation in the central place is sufficient.
This commits add documentation to the pulse counter params and adds
generic exclude patters to the doc check, so that when boards provide
custom pulse counter params they do not need to document them again. The
reasoning is that the documentation in the central place is sufficient.
This commits add documentation to the PIR params and adds generic
exclude patters to the doc check, so that when boards provide custom PIR
params they do not need to document them again. The reasoning is that
the documentation in the central place is sufficient.
19039: Ensure C locale when querying the compiler for compile commands r=maribu a=janhenke
### Contribution description
This fixes generating the compile commands with localization enabled GCC and non-English shell locale. The python script uses regexes to extract the required information. These only match on the default English output. GCC supports localized output messages which break the regexes used. Instead of matching any possible localization, this fix forces the C locale for message output on the compiler invocation, thus ensuring the regexes can match.
### Testing procedure
Needed: arm-none-eabi.gcc with localization support and non-English system locale.
Invoke the compile-commands make target (`make compile-commands`).
It should generate the `compile_commands.json` file correctly.
### Issues/PRs references
None found, fix was trivial enough to fix it directly.
Co-authored-by: Jan Henke <Jan.Henke@taujhe.de>
GCC supports localized outputs, depending on the currently set locale.
This broke the compile-commands target, as the regexes only match the
English output. By invoking the compiler explicitly with the C locale,
it ensures the expected English language output.
19012: boards/arduino-mega2560: add TTY_BOARD_FILTER r=gschorcht a=maribu
### Contribution description
This allows automatically selecting TTY actually belonging to an
Arduino Mega2560 if `MOST_RECENT_PORT=1` is set.
### Testing procedure
```
make BOARD=arduino-mega2560 MOST_RECENT_PORT=1 -C examples/default flash term
```
Should automatically select the TTY of the most recently connected Arduino Mega2560, even if a board of a different type is connect more recently.
### Issues/PRs references
- [x] depends on (and includes) https://github.com/RIOT-OS/RIOT/pull/19011
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
If no TTY serial (matching the given filters, if any) was found, use
the exit code `1`. The idea is that simple shell scripts falling back
to alternative variants of a board can be used via
```.sh
ttys.py --most-recent --model Fooboard --vendor Footronic || \
ttys.py --most-recent --model Barboard --vendor Bartronic
```
Just adding a regex that would accept both vendors and models would
have different semantics: If both a Fooboard and a Barboard are
attached, it would pick the most recently connected of both. The shell
expression above would always prefer a Fooboard over a Borboard.
The use case cheap Arduino clones that replace the ATmega16U2 used
as USB UART bridge with cheap single purpose chips. The original
ATmega16U2 has the advantage that it provides identification data
unique the specific Arduino board, while the clones cannot be told
apart from standalone USB UART bridges or Arduino clones of other
models. Hence, we want to pick the genuine Arduino board if connected,
and only fall back to matching cheap USB UART bridges if no genuine
Arduino board is connected.
18803: dist/tools: Add compile_like_murdock r=benpicco a=MrKevinWeiss
### Contribution description
Helper script to pre-test murdock build conditions.
This is intended to compile like murdock giving control for only a subset of boards or applications. One can use this if only a limited change should be build tested. Defaults boards and apps are selected to be an early warning if something is wrong.
This should be used before triggering much larger murdock builds.
The following use cases are:
I made a change to something in the stm32 clocks... ./compile_like_murdock.py -c stm32
I changed a driver the DHT driver
./compile_like_murdock.py -a tests/driver_dht tests/saul
I changed a nucleo-f103rb board...
./compile_like_murdock.py -a tests/driver_dht tests/saul
### Testing procedure
View the help...
```
./dist/tools/compile_test/compile_like_murdock.py -h
```
Do a dry run of the cpu...
```
./dist/tools/compile_test/compile_like_murdock.py -c stm -d
```
Play with each of the args, try adding a module to hello-world to get a module mismatch.
### Issues/PRs references
<!--
Examples: Fixes#1234. See also #5678. Depends on PR #9876.
Please use keywords (e.g., fixes, resolve) with the links to the issues you
resolved, this way they will be automatically closed when your pull request
is merged. See https://help.github.com/articles/closing-issues-using-keywords/.
-->
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
Helper script to pre-test murdock build conditions.
This is intended to compile like murdock giving control for only a subset of
boards or applications. One can use this if only a limited change should be
build tested. Defaults boards and apps are selected to be an early warning
if something is wrong.
This should be used before triggering much larger murdock builds.
The following use cases are:
I made a change to something in the stm32 clocks...
./compile_like_murdock.py -c stm32
I changed a driver the DHT driver
./compile_like_murdock.py -a tests/driver_dht tests/saul
I changed a nucleo-f103rb board...
./compile_like_murdock.py -a tests/driver_dht tests/saul
For some TTY interfaces no DB entry exists, which is reflected by
having a `None` in `tty[key]`. Trying to match a regex against `None`
in turn resulted then in an exception.
This fixes the issue by treating a filter applied on a non-existing
entry as not matching.
It turned out that 4983f8bb60 was not
enough to allow the tool to be executed from within
`dist/tools/backport_pr`. With this, I successfully tested it :)
