19033: Fix soft spi bugs r=aabadie a=Enoch247
### Contribution description
This PR contains some small bug and spelling fixes I noticed while reading the soft_spi code while using it as an example for writing my own driver. See the commit comments for details of each change.
### Testing procedure
I compiled, but did not run, tests/driver_soft_spi. The change is minor and verifiable by simply looking at the code.
### Issues/PRs references
- None
Co-authored-by: Joshua DeWeese <jdeweese@primecontrols.com>
The code did not take into account that valid bus numbers are
0...(COUNT-1).
This patch corrects this. It also makes use of the newly introduced
SOFT_SPI_NUMOF define.
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.
19023: pkg/tinyusb: fix Kconfig problems r=maribu a=gschorcht
### Contribution description
This PR tries to fix the [problems with `tinyUSB` in nightlies](https://ci.riot-os.org/details/d11b383ba0cd45048ed6f8d98abbc0de).
- The `tinyusb_device` feature had to be moved from `boards/common/arduino-zero` definition to the `boards/arduino-zero` definition because the common `arduino-zero` features are also used by `wemos-zero` which uses the `highlevel_stdio` feature via the `stdio_cdc_acm` module.
- The `tinyusb_device` feature had to be removed from Kconfig of board `stm32f429i-disco` since it uses the `highlevel_stdio` feature via the `stdio_cdc_acm` module.
### Testing procedure
Green CI
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19042: boards/rpi-pico: doc - fix link to datasheet r=benpicco a=krzysztof-cabaj
### Contribution description
This PR fix link to datasheet - previous one points to some jpg file and ends with 404.
### Testing procedure
```
make doc
xdg-open doc/doxygen/html/group__boards__rpi__pico.html
```
and check if link shows datasheet.
### Issues/PRs references
None
Co-authored-by: krzysztof-cabaj <kcabaj@gmail.com>
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>
This allows automatically selecting TTY actually belonging to an
Arduino Mega2560 if `MOST_RECENT_PORT=1` is set.
Note: Unless `ARDUINO_MEGA2560_COMPAT_WITH_CLONES` is set to `0`,
this will fall back to detecting any cheap USB UART bridge typically
found in Arduino Mega 2560 clones if no genuine Arduino Mega is found.
Allow overriding the shell command used to auto-detect the TTY of a
board with `MOST_RECENT_PORT=1` via the `TTY_SELECT_CMD` variable.
The use case is to also detect Arduino Mega 2560 clones with cheap
USB UART bridges (for which the filter command may yield false
positives) while preferring genuine Arduino Mega 2560 boards (if
found) over the clones (as the filter for genuine boards does not yield
false positives).
18962: pkg/lwip: Force loglevel when using log module r=maribu a=yarrick
18999: Paho: Allow building for 8 and 16 bit platforms r=maribu a=OlegHahm
### Contribution description
Providing a patch to Paho upstream which uses fixed size integers (int32_t) instead of plain int whenever it is used to represent a size of an object.
This patch will allow to build the Paho package for platforms where an integer has a width of less than 32 bit.
This patch is also provided as a PR to the upstream version of Paho (https://github.com/eclipse/paho.mqtt.embedded-c/pull/238) but unfortunately the upstream seems to be unmaintained.
### Testing procedure
Build for a 8 or 16 bit platform that has enough memory for the example, e.g., https://api.riot-os.org/group__boards__atxmega-a1u-xpro.html:
BUILD_IN_DOCKER=1 BOARD=atxmega-a1u-xpro make clean all
Without this PR this build will fail, with the patches applied it will succeed.
### Issues/PRs references
This PR makes #18997 obsolete and thus reverts the change.
19034: boards/nucleo-l496zg: doc improvement r=maribu a=krzysztof-cabaj
### Contribution description
This PR adds to nucleo-l496zg documentation MCU table - similar to those, for example for, Nucleo F103RB, F302R8 or F446RE.
### Testing procedure
```
make doc
xdg-open doc/doxygen/html/group__boards__nucleo-l496zg.html
```
### Issues/PRs references
None
Co-authored-by: Erik Ekman <eekman@google.com>
Co-authored-by: Oleg Hahm <oleg@hobbykeller.org>
Co-authored-by: krzysztof-cabaj <kcabaj@gmail.com>
19026: riscv: Reduce reset trampoline code size by 2 bytes r=maribu a=jnohlgard
`addi` with 20 bit immediate does not have a compressed representation, so using `jalr` with immediate offset uncompressed is smaller than using `addi`+`c.jr`
Co-authored-by: Joakim Nohlgård <joakim@nohlgard.se>
The board reset function `usb_board_reset_coding_cb` can be used on any CDC ACM interface. It is not necessary that the highlevel STDIO is used. Therefore, the call of the board reset function `usb_board_reset_coding_cb` has been moved from the USBUS STDIO CDC ACM implementation to USBUS CDC ACM implementation and is thus a feature of the USBUS CDC ACM interface that don't require any other functionality.
19032: sys/analog_util/dac_util: fix truncation bug r=maribu a=Enoch247
### Contribution description
From the commit message:
> In `dac_util_map(...)` the expression `((value - min) * UINT16_MAX)` was cast to a 16 bit unsigned, then divided by `(max - min)`. This means that anytime `(value - min) != 0` the numerator was truncated prior to being divided and then returned.
>
> This patch modifies the expression so that the downcast to 16 bits is performed as the last operation.
### Testing procedure
Should be verifiable by simply analyzing the code.
### Issues/PRs references
none known
Co-authored-by: Joshua DeWeese <jdeweese@primecontrols.com>
Reduce the number lines to output by only testing for intervals 0..15
to speed up the test.
In addition, run each test case 128 repetitions (it is still faster
than before) to give some confidence the short relative set actually
succeeded.
In `dac_util_map(...)` the expression `((value - min) * UINT16_MAX)` was
cast to a 16 bit unsigned, then divided by `(max - min)`. This means
that anytime `(value - min) != 0` the numerator was truncated prior to
being divided and then returned.
This patch modifies the expression so that the downcast to 16 bits is
performed as the last operation.
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>
19029: check-pr.yml: Fail when `State: waiting for CI update` is set r=miri64 a=miri64
<!--
The RIOT community cares a lot about code quality.
Therefore, before describing what your contribution is about, we would like
you to make sure that your modifications are compliant with the RIOT
coding conventions, see https://github.com/RIOT-OS/RIOT/blob/master/CODING_CONVENTIONS.md.
-->
### Contribution description
See https://github.com/RIOT-OS/RIOT/pull/18956#issuecomment-1342781762
<!--
Put here the description of your contribution:
- describe which part(s) of RIOT is (are) involved
- if it's a bug fix, describe the bug that it solves and how it is solved
- you can also give more information to reviewers about how to test your changes
-->
### Testing procedure
I've set the label in question, so the test should fail in the beginning.
<!--
Details steps to test your contribution:
- which test/example to compile for which board and is there a 'test' command
- how to know that it was not working/available in master
- the expected success test output
-->
### Issues/PRs references
See https://github.com/RIOT-OS/RIOT/pull/18956
<!--
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: Martine Lenders <m.lenders@fu-berlin.de>
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
19024: pkg/paho-mqtt: add support for DNS r=aabadie a=benpicco
<!--
The RIOT community cares a lot about code quality.
Therefore, before describing what your contribution is about, we would like
you to make sure that your modifications are compliant with the RIOT
coding conventions, see https://github.com/RIOT-OS/RIOT/blob/master/CODING_CONVENTIONS.md.
-->
### Contribution description
This is pretty straightforward, we only need to hook up `dns_query()`.
Since paho supports both IPv4 and IPv6 we use `AF_UNSPEC` in the query.
This can however give us a A record if we only have IPv6 enabled, so translate the request based on what IP address module is enabled in `dns_query()`.
### Testing procedure
connecting by name works
```
> con test.mosquitto.org 1883
mqtt_example: Connecting to MQTT Broker from test.mosquitto.org 1883
mqtt_example: Trying to connect to test.mosquitto.org , port: 1883
user: clientId: password:
mqtt_example: Connection successfully
```
connecting by IP still works
```
> con 2001:41d0:1:925e::1 1883
mqtt_example: Connecting to MQTT Broker from 2001:41d0:1:925e::1 1883
mqtt_example: Trying to connect to 2001:41d0:1:925e::1 , port: 1883
user: clientId: password:
mqtt_example: Connection successfully
```
<!--
Details steps to test your contribution:
- which test/example to compile for which board and is there a 'test' command
- how to know that it was not working/available in master
- the expected success test output
-->
### 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: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
18956: CI: implement quick build logic r=kaspar030 a=kaspar030
<!--
The RIOT community cares a lot about code quality.
Therefore, before describing what your contribution is about, we would like
you to make sure that your modifications are compliant with the RIOT
coding conventions, see https://github.com/RIOT-OS/RIOT/blob/master/CODING_CONVENTIONS.md.
-->
### Contribution description
This PR implements "quick builds" (subset builds).
The logic is as following (checkmark for what was tested):
- [x] if the "CI: full build" label is set, [result](https://ci.riot-os.org/details/15e489f7a3f346bdb49a84080329f3d6)
- [x] or NIGHTLY=1 [result](https://ci.riot-os.org/details/d741a174bbbc437eb1972e87688098fb)
- [x] or if building bors' ~~"trying"~~"staging" branch, do a full build. [result](https://ci.riot-os.org/details/692362fd0e594bdeb190ea99a6de2479)
- [x] otherwise, if BOARDS was supplied, build those: [result](https://ci-staging.riot-os.org/details/2034f3ed656c4b37b573732517334cfd) (ci-staging hard-sets BOARDS="samr21-xpro native")
- [x] otherwise, if can_fast_ci_build.py figured out boards that have changes, build those [result](https://ci.riot-os.org/details/ab92ec61cb7040b18d9789c05831eb86)
- [x] otherwise, only consider boards listed in QUICKBUILD_BOARDS [result](https://ci.riot-os.org/details/fca366441e0341d79af52200365d298d)
<!--
Put here the description of your contribution:
- describe which part(s) of RIOT is (are) involved
- if it's a bug fix, describe the bug that it solves and how it is solved
- you can also give more information to reviewers about how to test your changes
-->
TBD: actual list of QUICKBUILD_BOARDS
### Testing procedure
<!--
Details steps to test your contribution:
- which test/example to compile for which board and is there a 'test' command
- how to know that it was not working/available in master
- the expected success test output
-->
### Issues/PRs references
bors tracking issue: https://github.com/RIOT-OS/RIOT/issues/18911
<!--
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: Kaspar Schleiser <kaspar@schleiser.de>
`addi` with 20 bit immediate does not have a compressed representation,
so using `jalr` with immediate offset uncompressed is smaller than using
`addi`+`c.jr`
18910: CI: add bors.toml r=kaspar030 a=kaspar030
<!--
The RIOT community cares a lot about code quality.
Therefore, before describing what your contribution is about, we would like
you to make sure that your modifications are compliant with the RIOT
coding conventions, see https://github.com/RIOT-OS/RIOT/blob/master/CODING_CONVENTIONS.md.
-->
### Contribution description
This adds configuration for [bors](https://bors.tech).
This has been discussed in CI meetings. The intended workflow is:
1. regular PR commits get built by CI as usual, but doing a quick-build (building only a subset of all boards), unless "CI: full build" is set
2. once that passes and the PR is ACKed, instead of merging using the merge button, we use bors to merge by typing "bors merge".
3. bors takes the PR, pushes it to the "testing" branch
4. CI does a full build of "testing"
5. on success, bors merges testing into master
The main benefits are
1. a quickbuild / full build scheme ("regular" PR builds will be <5 minutes, but only fully built branches get merged into master)
2. bors does "rollups", meaning, if multiple PRs are to be "bors merged", bors merges them together, tests them together and merges them together. That's more efficient than doing this sequentially, and prevents semantic merge conflicts (e.g., PR a and b pass CI individually, but fail when both merged, breaking master).
Once fully implemented, using bors will be a workflow change (no more "pressing the green button", but typing "bors merge" instead). But we've been using bors for RIOT-OS/riotdocker for a long time now, the experience was good (as opposed to disruptive).
This PR just adds the necessary bors configuration, and once merged will allow using bors to merge PRs using "bors merge", but the previous workflow is still in place (manual merging can be done, and "regular" PR builds are still full builds).
<!--
Put here the description of your contribution:
- describe which part(s) of RIOT is (are) involved
- if it's a bug fix, describe the bug that it solves and how it is solved
- you can also give more information to reviewers about how to test your changes
-->
### Testing procedure
<!--
Details steps to test your contribution:
- which test/example to compile for which board and is there a 'test' command
- how to know that it was not working/available in master
- the expected success test output
-->
### Issues/PRs references
bors tracking issue: #18911
<!--
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: Kaspar Schleiser <kaspar@schleiser.de>
