19526: boards/arduino-mkrwan1300: update board name to correct one r=aabadie a=FlapKap
Co-authored-by: Kasper Hjort Berthelsen <kasper.berthelsen@hotmail.com>
19525: semtech-loramac: extend list of supported radio with sx1261, sx1262 and sx1268 r=maribu a=aabadie
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
19528: treewide: fix typos and false positives found by codespell r=aabadie a=maribu
### Contribution description
This fixes some typos and adds one correctly used abbreviation to the ignore list.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
The current implmentation right shifted the 16 bit value passed into
`dac_set()` down to the 12 bits that the DAC is actually capable of.
This patch drops the shift and instead writes the 16 bit value to the
DAC's left aligned 12 bit wide data holding register.
It is not necessary to hold a complete copy `sdcard_spi_params_t` in the device descriptor. Constant parameters can be used directly from ROM instead. This saves 24 bytes of RAM.
19516: cpu/rpx0xx: add initial ADC support r=dylad a=dylad
### Contribution description
This PR adds initial support for RP2040 ADC peripheral.
It is rather minimalist, and only use oneshot trigger to perform a single acquisition.
I've tested this PR using a potentiometer connected between GND and 3V3.
GP26, GP27, GP28 has been tested.
### Testing procedure
Select `ADC_RES_12BIT` and flash `tests/periph_adc`
`make BOARD=rpi-pico -C tests/periph_adc`
### Issues/PRs references
None.
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
19346: pkg/tinydtls: allow build for AVR r=benpicco a=benpicco
19512: SUBSYSTEMS.md: add jia200x to subsystems r=benpicco a=jia200x
19513: boards/nrf52840dongle/doc: Update nrfutil pointers r=benpicco a=chrysn
### Contribution description
Nordic changed its nrfutil; this change adjust to it.
I'm not fully happy with recommending that tool at all due to its bad quality (see rambling in https://github.com/RIOT-OS/RIOT/issues/19511), but short of soldering on a debug header or touch-probing it with wires it's the only way in to the device. I may later add follow-up recommendations to switch to riotboot, but this now at least fixes the immediate issue.
### Testing procedure
* Look at the updated documentation.
### Issues/PRs references
Closes: https://github.com/RIOT-OS/RIOT/issues/19511
19514: dist/testbed-support: remove obsolete boards from iotlab archi r=benpicco a=aabadie
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Jose Alamos <jose@alamos.cc>
Co-authored-by: chrysn <chrysn@fsfe.org>
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
19515: drivers/servo: Fix missing dep r=maribu a=maribu
### Contribution description
The servo test app uses `USEMODULE += servo` and lets the build system pick automatically the best suitable backend. If one explicitly chooses a backend e.g. via `USEMODULE += servo_timer`, this currently requires adding `USEMODULE += servo` in addition. This commit fixes the issue.
### Testing procedure
The app provided in https://github.com/RIOT-OS/RIOT/issues/19474 should now compile. (It does so for me.)
### Issues/PRs references
Fixes https://github.com/RIOT-OS/RIOT/issues/19474
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
The servo test app uses `USEMODULE += servo` and lets the build system
pick automatically the best suitable backend. If one explicitly chooses
a backend e.g. via `USEMODULE += servo_timer`, this currently requires
adding `USEMODULE += servo` in addition. This commit fixes the issue.
Fixes https://github.com/RIOT-OS/RIOT/issues/19474
19507: cpu/cc26x0_cc13x0: Drop feature cortexm_mpu r=maribu a=maribu
### Contribution description
At least the CC2650 doesn't have an MPU, I assume this is also true for the rest of the family.
The CC2652 does have an MPU according to the datasheet. So I keep the feature there in place.
### Testing procedure
E.g.
```
make BOARD=cc2650-launchpad -C tests/mpu_noexec_ram flash test
```
fails. (Note: A successful test run would also crash but with a mem manage handler rather than a hardfault due to an invalid instruction on the stack being executed.)
It would be nice to also test the same for a `cc2652-launchpad`, for which the MPU should work.
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
At least the CC2650 doesn't have an MPU, I assume this is also true
for the rest of the family.
The CC2652 does have an MPU according to the datasheet. So I keep the
feature there in place.
