19881: drivers/stmpe811: fix initialization if callback function parameter is NULL r=benpicco a=gschorcht
### Contribution description
This PR fixes the `stmpe811` driver initialization if the callback function parameter `cb` is `NULL. This might be the case for example if the application uses the touch device in polling mode.
If the interrupt pin is initialized if the callback function parameter `cb` is `NULL`, the driver crashes the first time an interrupt is triggered. Therefore, the INT pin must be initialized only if also the callback function parameter `cb` is not `NULL`.
To be able to test the polling mode, this PR also includes a change of the `tests/drivers/stmpe811` application which introduces the environment variables `STMPE811_POLLING_MODE` `STMPE811_POLLING_PERIOD` and in the makefile.
### Testing procedure
1. Use a `stm32f429i-disc1` board and test it in polling mode:
```
STMPE811_POLLING_MODE=1 BOARD=stm32f429i-disc1 make -C tests/drivers/stmpe811 flash term
```
It should work as expected.
```
main(): This is RIOT! (Version: 2023.10-devel-119-g26e7a-drivers/stmpe811_fix_cb_null)
STMPE811 test application
+------------Initializing------------+
Initialization successful
Pressed!
X: 113, Y:135
X: 113, Y:135
X: 113, Y:136
Released!
```
2. Checkout master branch and cerry-pick commit 691a5e6308426ddc685e5a2c297238529211c258. The test application `tests/drivers/stmpe811` will crash once a touch event occur:
```
main(): This is RIOT! (Version: 2023.10-devel-117-g91441)
STMPE811 test application
+------------Initializing------------+
Initialization successful
Stack pointer corrupted, reset to top of stack
FSR/FAR:
CFSR: 0x00020000
HFSR: 0x40000000
DFSR: 0x00000008
AFSR: 0x00000000
Misc
EXC_RET: 0xfffffff1
*** RIOT kernel panic:
HARD FAULT HANDLER
```
### Issues/PRs references
19892: pkg/tinydtls: allow to set buffer size from application again r=benpicco a=leandrolanzieri
### Contribution description
Currently the buffer size on tinydtls is set in its Makefile whenever `gcoap` module is present. This limits the ability of the user to override the value. This adds a pre-check of the `CFLAGS` to see if it was set before.
### Testing procedure
Try setting `CFLAGS += -DDTLS_MAX_BUF=<some_value>` on `examples/gcoap_dtls`, you should be able to override the default value without errors.
### Issues/PRs references
Reported in #19838
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Leandro Lanzieri <leandro.lanzieri@haw-hamburg.de>
The macro `AUTO_INIT_PRIO_MOD_TINYUSB` was being used, but not defined.
This patch includes the header where `AUTO_INIT_PRIO_MOD_TINYUSB` is
defined to fix the compiler error.
This fixes the dependencies of the `arduino_adafruit_sensor` package,
which previously relied on the `arduino` feature. This feature no longer
exists, as it was split into more fine granular features. However, the
module should never have used that feature directly in the first place,
but rather just use the arduino module. This in turn depends on the
correct features.
19634: tree-wide: mixed box of compilation fixes with clang r=benpicco a=maribu
### Contribution description
As the title says: This should increase the number of apps being able to build with clang quite a bit.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
LLVM was already blacklisted for some specific Cortex-M targets due
to register allocation failing. The issue now has spread. Rather than
starting a whack-a-mole game, let's disable LLVM altogether for that
package.
pkg/fff compiles fine with clang 16.0.0 and higher, but the CI currently
uses version 14.x.y which is incompatible. This disables LLVM in the CI
builds and prints a friendly error message when `TOOLCHAIN=llvm` is
used and clang is older than 16.0.0.
19798: cpu/nrf53: add I2C and SPI support r=benpicco a=dylad
### Contribution description
This PR provides support for nRF53 SPI and I2C.
It also moves common structs from each nRF CPU folder to `cpu/nrf5x_common` to avoid duplication.
Moreover, since nRF9160 and nRF5340 have shared IRQ for UART/SPI/I2C. Both this families now use a common file to register and manage these interrupts. Note that nRF9160 have different name for its interrupts than nRF5340 but they have the same purpose.
### Testing procedure
Since some structs were moved around, I think this PR should be carefully tested against nRF52, nRF53 and nRF9160 to avoid any issues.
On nRF5340DK-APP, SPI can be tested with its onboard SPI flash.
### Issues/PRs references
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
- periph/eeprom.c
- periph/wdt.c
- periph/gpio_ll_irq.c
removed unsupported cpuid and dpgpin feature for atmega8 cpu familly
pkg/qdsa: bump the commit hash bump the commit hash after RIOT-OS/qDSA#4
was merged
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>
