19715: drivers/mrf24j40: add note about missing wake pin handling r=maribu a=maribu
### Contribution description
This adds a note that wake pin handling is not implemented and users need to connect the wake pin to VCC, or drive it high in the board / application logic prior to initializing the driver.
19716: boards/olimex-msp430-h1611: fix doc r=maribu a=maribu
### Contribution description
The statement about the missing pin 1 marking on the JTAG header is not correct. It's just a bit hidden between the JTAG header and the power selector jumper.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
The statement about the missing pin 1 marking on the JTAG header is
not correct. It's just a bit hidden between the JTAG header and the
power selector jumper.
19708: boards/esp32s3-pros3: Fix stdio kconfig model r=MrKevinWeiss a=MrKevinWeiss
### Contribution description
Always something...
It seems like the desired behaviour (if we use `MODULE_USBUS`, then override the `MODULE_STDIO_USB_SERIAL_JTAG`) requires selection of MODULE_USBUS_CDC_ACM. Seems to be a bit of a corner case.
### Testing procedure
Let's see if murdock can test faster than my cpu.
### Issues/PRs references
Failure in master
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
19693: sys/color: extend unittest and fix module r=maribu a=kfessel
### Contribution description
this extends the unittest for sys_color testing more colors
### Testing procedure
```
RIOT_tree/tests/unittests$ make tests-color test
```
will fail since our `rgb2hsv` implementation is wrong (or is using an other colorspace than hsv2rgb (without documenting))
the new `hsv2rgb` test will succeed
### Issues/PRs references
#19614 was the reason i had a look at this
#1315 added the rgb2hsv and hsv2rgb function
#9940 added the test for black special case
https://www.vagrearg.org/content/hsvrgb << some optimization for that function (avoiding float)
Co-authored-by: Karl Fessel <karl.fessel@ovgu.de>
19704: makefiles/toolchain/gnu.inc.mk: fix compilation r=dylad a=maribu
### Contribution description
The `--param=min-pagesize=0` needed since GCC 12 is still needed with GCC 13. This time at least the message is more meaningful:
note: source object is likely at address zero
This is something that is not expected in a userspace app, but with bare metal MCUs and often flash or memory mapped I/O starting from address zero, this warning prevents legitimate code from compiling.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
The `--param=min-pagesize=0` needed since GCC 12 is still needed with
GCC 13. This time at least the message is more meaningful:
note: source object is likely at address zero
This is something that is not expected in a userspace app, but with
bare metal MCUs and often flash or memory mapped I/O starting from
address zero, this warning prevents legitimate code from compiling.
19689: cpu/sam0_eth: disable PHY when MAC is sleeping r=maribu a=benpicco
19700: pkg/openthread: Fix Kconfig and broken example r=maribu a=MrKevinWeiss
### Contribution description
There were some improvements that could be make to the kconfig modeling of the `pkg/openthread` after looking a bit closer.
The bigger problem is the hash check on nightlies require reproducible builds, however, even with make, the builds are not reproducible. So, for now, I just rename the `app.config.test` to `skip.app.config.test` to prevent murdock from trying to do a hash check but still letting it be useable.
### Testing procedure
Green murdock, all modules match `examples/openthread`
- Rename `skip.app.config.test` to `app.config.test`
- Run the following
```
./dist/tools/compile_test/compile_like_murdock.py -j 8 -a examples/openthread/ -b all -m
```
<details>
```
examples/openthread/ cc2538dk PASS
examples/openthread/ frdm-kw41z PASS
examples/openthread/ iotlab-a8-m3 PASS
examples/openthread/ iotlab-m3 PASS
examples/openthread/ nrf52840-mdk PASS
examples/openthread/ nrf52840dk PASS
examples/openthread/ omote PASS
examples/openthread/ openlabs-kw41z-mini PASS
examples/openthread/ openlabs-kw41z-mini-256kib PASS
examples/openthread/ openmote-cc2538 PASS
examples/openthread/ phynode-kw41z PASS
examples/openthread/ reel PASS
examples/openthread/ remote-reva PASS
examples/openthread/ remote-revb PASS
examples/openthread/ samr21-xpro PASS
examples/openthread/ usb-kw41z PASS
```
</details>
### Issues/PRs references
Fixes an aspect of broken master
19701: sys/usb/Kconfig: Fix default PID r=maribu a=MrKevinWeiss
### Contribution description
Seems like I just didn't have the correct `USB_PID` defined in the `usb-codes.inc.mk`.
It should be 0x7D01 not 0x7001.
It only shows up in nightlies since the hash would mismatch.
### Testing procedure
Simulated nightly testing with:
```
./dist/tools/compile_test/compile_like_murdock.py -j 8 -a tests/pkg/tinyusb_cdc_acm_stdio/ tests/pkg/tinyusb_cdc_msc/ tests/pkg/tinyusb_cdc_msc/ tests/sys/fido2_ctap/ tests/sys/usbus_board_reset/ tests/sys/usbus_msc/ -b arduino-zero samd21-xpro nucleo-f767zi -v
```
<details>
```
tests/pkg/tinyusb_cdc_acm_stdio/ arduino-zero PASS
ctests/pkg/tinyusb_cdc_acm_stdio/ nucleo-f767zi PASS
tests/pkg/tinyusb_cdc_acm_stdio/ samd21-xpro PASS
tests/pkg/tinyusb_cdc_msc/ arduino-zero PASS
tests/pkg/tinyusb_cdc_msc/ nucleo-f767zi PASS
tests/pkg/tinyusb_cdc_msc/ samd21-xpro PASS
tests/pkg/tinyusb_cdc_msc/ arduino-zero PASS
tests/pkg/tinyusb_cdc_msc/ nucleo-f767zi PASS
tests/pkg/tinyusb_cdc_msc/ samd21-xpro PASS
tests/sys/fido2_ctap/ arduino-zero PASS
tests/sys/fido2_ctap/ samd21-xpro PASS
tests/sys/usbus_board_reset/ arduino-zero PASS
tests/sys/usbus_board_reset/ nucleo-f767zi PASS
tests/sys/usbus_board_reset/ samd21-xpro PASS
tests/sys/usbus_msc/ arduino-zero PASS
tests/sys/usbus_msc/ nucleo-f767zi PASS
tests/sys/usbus_msc/ samd21-xpro PASS
```
### Issues/PRs references
Broken master in nightlies.
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
It seems like the openthread package has some 'non-reproducible' builds
so we just disable it by renaming the app.config.test so murdock will not
pick it up.
Probably something to do with a timestamp.
19696: drivers/mq3: avoid use of floats r=maribu a=maribu
19698: tests/pkg/lvgl: avoid using floats r=maribu a=maribu
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
19691: drivers/bmx055: fix crazy use of FPU r=maribu a=maribu
### Contribution description
As the title says...
19694: tests/drivers/epd_bw_spi_disp_dev: fix accidental use of FPU r=maribu a=maribu
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
19086: Remodel the USB in Kconfig r=aabadie a=MrKevinWeiss
### Contribution description
#### The issues with current architecture
Generally there has been some confusion on how to manage KConfig with respect to the board selection of default STDIO backends, specifically for boards that require a USB based backend as there are possible stacks to use.
The `<BOARD>.config` way of selecting cannot handle conditional selects.
The issues is more with boards such as `esp32s2-wemos-mini`, currently some USB stack will be selected regardless of overridding the preferred STDIO.
Selecting a USB stack directly with `STDIO_USB*` creates some circular dependency issues with kconfig and is hard to manage.
We also have a mutually exclusive USB stacks, TINYUSB or USBUS which should probably be a choice.
#### Desired behaviour
1. Ideally we want a board to default to the most obvious STDIO implementation, for example, if I have nucleo, it uses a UART, for some ESPs, USB is the default way to communicate.
2. These backends could always be overridden though, for example, I may just connect directly to a UART and want my STDIO there, or maybe use a ble based STDIO.
3. The next condition would be specifically for boards with a USB based STDIO. Since we have a TINYUSB stack and a USBUS stack we would want to use the associated STDIO depending on the stack the application selects.
4. However, if nothing is selected by the application, than bring in a USB stack (board based preference) unless there is a specific non-USB based STDIO is selected. For these boards that have this requirement, we DO NOT want to bring in the USB stack if the STDIO is specifically overridden (important for kconfig).
#### Update kconfiglib package to RIOT-OS org managed one
There is a problem with the upstreamed Kconfiglib implementation and the maintainer is not responsive to the fix. The issue is to do with `menuconfig`s in choices and has been fixed with the RIOT-OS based fork. This PR requires this fix.
#### Changes to the USB stack
A new entry point is introduced `USB_DEVICE` which indicates wanting a USB device but not caring which stack is used. This allows making a `choice` between the `TINYUSB` and `USBUS` stack allowing mutual exclusivity.
Making the USB stack a `choice` means that a specific stack cannot be selected from non-board/non-cpu/non-application based symbols. Thus the `REQUIRES_` design pattern is used for a module to indicate a specific stack should be selected. This is needed for the `MODULE_TINYUSB_NETDEV` in this case.
#### Changes to USB STDIO implementations
The `MODULE_STDIO_CDC_ACM` and `MODULE_STDIO_TINYUSB_CDC_ACM` are both depends on now, using a `REQUIRES_USB_STDIO` to select the dependencies.
This means we do not have to use `select PACKAGE_TINYUSB if TEST_KCONFIG && !MODULE_USBUS` in the board select.
##### Why not just select the USB from STDIO_USB
Issue with using select for STDIO choices is that we cannot check which stack we are using to default the STDIO to that, breaking desired behaviour 3.
#### The `FORCE_USB_STDIO`
Desired behaviour 4 means that we do not want to bring in the USB stack if we override, say, to the UART STDIO backend. Due to the limitations of Kconfig, this is my solution to prevent the USB from being brought in if there is an STDIO that doesn't need it. It is only for the `esp32s2-wemos-mini` board and would not be used in other places and would only need to be explicitly disabled for applications requiring different STDIO backend and no USB. It is not perfect but I think the best solution and fairly understandable...
<details><summary><h4>Issues with Kconfig</h4></summary>
When using a `choice` and having conditional defaults, for example:
```kconfig
choice IMPL
default FOO if CHOOSE_FOO
default BAR
```
there is a limitation of the level of the level of knowledge that can be expected from Kconfig, a limitation on circular dependencies, and a limitation that the dependencies only get resolved once.
For example, if ` BAR` selects something that would eventually select `CHOOSE_FOO`, then the default should be `FOO` and which would no longer select `BAR` preventing the select `CHOOSE_FOO`... Messy stuff and we would want an error saying no no no.
What Kconfig cannot handle is something like:
```kconfig
choice IMPL
bool "Implementation"
default FOO if CHOOSE_FOO
default BAR
config FOO
bool "Foo"
config BAR
bool "Bar"
endchoice
config CHOOSE_FOO
bool
config SYMBOL
bool
select CHOOSE_FOO if !BAR
```
`SYMBOL` causes a circular dependency in Kconfig even though the only possible outcome for the `choice` selection would be static. If we select `BAR` then `CHOOSE_FOO` would not be selected and we stay with `BAR`. If we select `FOO` than `CHOOSE_FOO` will be selected which stays with `FOO`. Everything should be fine, but isn't because Kconfig does not resolve to that degree, it simply sees that there is a dependency of the `IMPL` choice outcome (ie. `if !BAR`) that is a condition for a dependency of the `IMPL` choice selection (ie. ` if CHOOSE_FOO`).
This is a limitation of the Kconfig what what makes this problem so challenging, with Make we say "select some sort of USB backend if no other stdio is specifically requested" and it will.
</details>
An attempt at remodelling the dependencies of the USB stack in Kconfig.
Currently there are some issues, especially with the integration of TinyUSB package as a backend.
This will require a kconfiglib package fix though...
### Testing procedure
`TEST_KCONFIG=1 BOARD=reel make menuconfig -C examples/hello-world`
### Issues/PRs references
Requires https://github.com/ulfalizer/Kconfiglib/pull/123 to be merged upstream or fork for RIOT
Relates maybe to #18998 and #19038
19672: pkg/micropython: model in Kconfig r=aabadie a=aabadie
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
