Designated initializers make the code much more readable and are part
of the C standard since C99. C++ with C++20 finally caught up.
Until we switch to that C++ version, let's disable the annoying
warning rather than reducing the code quality for the sake of
strict C++ compatibility of our headers.
With GCC, the C++ compiler knows all builtin C include paths *and*
all builtin C++ include paths, but the C compiler only knows the
C include paths. Hence, let's use the C++ compiler to collect
the include paths.
19764: drivers/shield_w5100: add module for the W5100 Ethernet Shield r=benpicco a=maribu
### Contribution description
This module provides no more than the correct configuration parameters for the `w5100` driver using the Arduino I/O mapping features. But by doing so, it will work out of the box with every mechanically and electrically compatible board for which the Arduino I/O mapping features are implemented.
19781: cpu/nrf{53,9160}: add pwm support r=benpicco a=dylad
### Contribution description
This PR moves the nRF52 PWM driver to `cpu/nrf5x_common` to allow nRF9160 and nRF53 to use this driver.
IP is identical on these families.
I didn't test on nRF9160DK and I didn't test if there is any regression on nRF52-based board as I don't have any so tests are welcome !
However it works fine on nRF53-based board.
### Testing procedure
Flash the `tests/periph/pwm` test application on `nrf5340dk` or `nrf9160dk`.
You can then use the `osci` command to make the onboard LEDs "breath".
You can also attach an oscilloscope and/or logic analyzer to watch the signal.
### Issues/PRs references
~~Based on #19769~~
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Co-authored-by: dylad <dylan.laduranty@mesotic.com>
This module provides no more than the correct configuration parameters
for the `w5100` driver using the Arduino I/O mapping features. But
by doing so, it will work out of the box with every mechanically and
electrically compatible board for which the Arduino I/O mapping
features are implemented.
19791: makefiles/arch/riscv.inc.mk: speed up toolchain detection r=benpicco a=maribu
### Contribution description
- Use a sane (a.k.a. simply expanded) variable for the `$(TARGET_ARCH)` instead of an insane (a.k.a. recursive expended) variable - The toolchain detection will now happen only once, rather than each and every time `$(TARGET_ARCH)` is referenced
- Use a single call to `which` rather than one per possible target triple
Fixes https://github.com/RIOT-OS/RIOT/issues/19788
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
19733: cpu/msp430: reorganize code r=maribu a=maribu
### Contribution description
RIOT supports two distinct families of the MSP430: The [MSP430 x1xx] MCU family and the [MSP430 F2xx/G2xx] MCU family. For both incompatible MCU families the code was located in the msp430fxyz folder, resulting in case of the UART driver in particularly bizarre code looking roughly like this:
```C
#ifndef UART_USE_USCI
/* implementation of x1xx peripheral ... */
#else
/* implementation of F2xx/G2xx peripheral ... */
#endif
/* zero shared code between both variants */
```
This moves peripheral drivers shared between the two families to msp430_common and splits the SPI and UART driver into two MCU families.
In addition, it cleans up the `msp430_regs.h` by dropping most of it and using the macros and symbols provided by the vendor header files. There is little reason for us to maintain constants when TI is already doing that.
[MSP430 x1xx]: https://www.ti.com/lit/ug/slau049f/slau049f.pdf
[MSP430 F2xx/G2xx]: https://www.ti.com/lit/ug/slau144k/slau144k.pdf
19747: gnrc/ipv6/nib: reset rs_sent counter also for not-6LN interfaces r=maribu a=fabian18
19769: cpu/nrf53: add initial support with nRF5340DK-APP board r=maribu a=dylad
### Contribution description
This PR adds support for nRF5340 MCU and its associated Nordic development board, nRF5340DK.
This MCU provides a dual Cortex-M33, one application core running at up to 128MHz, and one network core running at up to 64MHz.
Peripherals are inherited from others Nordic MCUs families so it shouldn't be hard to add more of them in followup PRs.
For now, only the minimal set of peripherals is supported:
- GPIO / GPIO_IRQ
- UART
- TIMER
### Testing procedure
Build the usual test application for the supported peripherals and flash the board.
nRF5340DK provides two serial ports on its embedded debugger. RIOT's shell should be available on the first one (/dev/ttyACM0)
### Issues/PRs references
#18576#19267
19782: cpu/msp430: fix for ti's msp430-gcc-opensource package ld version r=maribu a=hugueslarrive
### Contribution description
My msp430 toolchain (https://www.ti.com/tool/MSP430-GCC-OPENSOURCE) was broken by #19484:
```
hugues@p700:~/github/cpu_msp430_common/RIOT$ BOARD=msb-430 make -j64 -C examples/hello-world
make : on entre dans le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
Building application "hello-world" for "msb-430" with MCU "msp430fxyz".
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core/lib
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers/periph_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/auto_init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/div
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/libc
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/malloc_thread_safe
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/newlib_syscalls_default
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz/periph
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/preprocessor
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/stdio_uart
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common/periph
/opt/ti/msp430-gcc/bin/../lib/gcc/msp430-elf/9.3.1/../../../../msp430-elf/bin/ld: .rodata not found for insert
collect2: error: ld returned 1 exit status
make: *** [/home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world/../../Makefile.include:761 : /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world/bin/msb-430/hello-world.elf] Erreur 1
make : on quitte le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
hugues@p700:~/github/cpu_msp430_common/RIOT$ /opt/ti/msp430-gcc/msp430-elf/bin/ld --version
GNU ld (Mitto Systems Limited - msp430-gcc 9.3.1.11) 2.34
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
hugues@p700:~/github/cpu_msp430_common/RIOT$ /opt/ti/msp430-gcc/msp430-elf/bin/ld --version | grep -Eo '[0-9]\.[0-9]+'
9.3
1.11
2.34
hugues@p700:~/github/cpu_msp430_common/RIOT$ /opt/ti/msp430-gcc/msp430-elf/bin/ld --version | grep -Eo '[0-9]\.[0-9]+$'
2.34
```
### Testing procedure
```
hugues@p700:~/github/cpu_msp430_common/RIOT$ BOARD=msb-430 make -j64 -C examples/hello-world
make : on entre dans le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
Building application "hello-world" for "msb-430" with MCU "msp430fxyz".
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core/lib
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers/periph_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/auto_init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/div
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/libc
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/malloc_thread_safe
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/newlib_syscalls_default
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/preprocessor
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/stdio_uart
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz/periph
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common/periph
text data bss dec hex filename
8612 722 866 10200 27d8 /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world/bin/msb-430/hello-world.elf
make : on quitte le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
```
### Issues/PRs references
Introduced by #19484, highlighted in #16727.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
Co-authored-by: Fabian Hüßler <fabian.huessler@ml-pa.com>
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Co-authored-by: Hugues Larrive <hlarrive@pm.me>
The MSP430 vendor files already provide macros containing register
constants and symbols (provided via linker scripts) containing addresses
of peripheral registers. So lets make use of that rather than
maintaining a long list of constants.
- Use a sane (a.k.a. simply expanded) variable for the `$(TARGET_ARCH)`
instead of an insane (a.k.a. recursive expended) variable
- The toolchain detection will now happen only once, rather than
each and every time `$(TARGET_ARCH)` is referenced
- Use a single call to `which` rather than one per possible target
triple
Fixes https://github.com/RIOT-OS/RIOT/issues/19788
19712: cpu/riscv: Add PMP driver r=MrKevinWeiss a=Teufelchen1
### Contribution description
Hi! 🐘
this adds a basic RISC-V physical memory protection (PMP) driver to RIOT. Well, 'driver' might be a stretched, feels more like a little utility :)
EDIT: Also added a no-execute RAM option for the hifive & a corresponding test
Since I only have an Hifive rev b, it's only enabled on this board / cpu. I also tested the code on an ESP32-C but the feature can't be enabled there, as `cpu/riscv_common/` is not used by the ESP32...
### Testing procedure
* Grab a hifive rev b
* go to `examples/hello-world`
* Add `USEMODULES += periph_pmp` to the `Makefile`
* Include `pmp.h` in `main.c`
* Add code e.g. `print_pmpcfg(0);`
* compile & flash & term
You should see something like this:
```
# Hello World!
# You are running RIOT on a(n) hifive1b board.
# This board features a(n) fe310 MCU.
# pmp00cfg: - R-X OFF 0x00000000 - 0x00000000
```
Co-authored-by: Teufelchen1 <bennet.blischke@outlook.com>
This allows using the arduino_pwm feature (which is translated into a
module) without the arduino module; e.g. for only using the Arduino
I/O mapping but not the Arduino API.
RIOT supports two distinct families of the MSP430: The [MSP430 x1xx]
MCU family and the [MSP430 F2xx/G2xx] MCU family. For both incompatible
MCU families the code was located in the msp430fxyz folder, resulting
in case of the UART driver in particularly bizarre code looking roughly
like this:
#ifndef UART_USE_USCI
/* implementation of x1xx peripheral ... */
#else
/* implementation of F2xx/G2xx peripheral ... */
#endif
/* zero shared code between both variants */
This splits the peripheral drivers for USCI and USART serial IP blocks
into separate files and relocates everything in cpu/msp430, similar to
how cpu/stm32 is organized.
[MSP430 x1xx]: https://www.ti.com/lit/ug/slau049f/slau049f.pdf
[MSP430 F2xx/G2xx]: https://www.ti.com/lit/ug/slau144k/slau144k.pdf
19703: cpu/sam0_eth: interrupt based link detection/auto-negotiation r=benpicco a=benpicco
19724: dist/tools/openocd: add OPENOCD_SERVER_ADDRESS variable r=benpicco a=fabian18
19735: nrf5x_common: Clear I2C periph shorts r=benpicco a=bergzand
### Contribution description
The I2C peripheral's shortcuts are used with the read and write register to automatically stop the I2C transaction or to continue with the next stage.
With simple I2C read and write bytes these shorts are not used, but are also not cleared by the function in all cases, causing it to use the shortcut configuration set by a previous function call. This patch ensures that the shorts are always set by the read and write functions
### Testing procedure
Should be possible to spot with a logic analyzer and the I2C periph test. Maybe the HIL test can also detect it :)
### Issues/PRs references
None
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Fabian Hüßler <fabian.huessler@ml-pa.com>
Co-authored-by: Koen Zandberg <koen@bergzand.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.
19556: tools/mspdebug: fix `make debug` and `make debugserver` r=aabadie a=maribu
### Contribution description
The semantics of `make debug` and `make debugserver` have changed in the years since the MSP430 integration. This brings the implementation back into line with the current semantics
- `make debug` now starts both mspdebug and GDB, no need to run `make debugserver` prior to `make debug` anymore
- `make debug` no longer flashes the target to not waste flash erase cycles
- GDB mutliarch support is added
- support for selecting a debug adapter by its serial is added
19662: driver/lc709203f: remove unnecessary use of float r=aabadie a=kfessel
### Contribution description
removes a unnecessary use of float
### Testing procedure
read and test if you got that hardware (I don't)
### Issues/PRs references
#19614
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Karl Fessel <karl.fessel@ovgu.de>
The semantics of `make debug` and `make debugserver` have changed in
the years since the MSP430 integration. This brings the implementation
back into line with the current semantics
- `make debug` now starts both mspdebug and GDB, no need to
run `make debugserver` prior to `make debug` anymore
- `make debug` no longer flashes the target to not waste flash erase
cycles
- GDB mutliarch support is added
- support for selecting a debug adapter by its serial is added
The coreclk shell command now prints the CPU frequency in Hz, which
can be useful for boards with RC generated CPU frequency (e.g.
RP2040, FE310, or MPS430Fx1xx MCUs allow this) which may quite a bit
off the target frequency.
19565: tests: move core related applications to their own tests/core/ folder r=maribu a=aabadie
19568: tests: move remaining driver related applications to tests/drivers r=maribu a=aabadie
19574: cpu/stm32/periph_gpio: reset PU/PD for ADC channels r=maribu a=gschorcht
### Contribution description
This PR provides a small fix that is relevant when a GPIO has been used as input/output with a pull resistor before it is initialized as an ADC channel.
The PU/PD configuration has to be `0b00` for analog outputs which is corresponds to the reset state. However, if the GPIO is not in the reset state but was used digital input/output with any pull resistor, the PU/PD configuration has also to be reset to use it as ADC channel.
### Testing procedure
- Green CI
- The `periph_adc` test application should still work for any board that supports the `periph_adc` feature.
### Issues/PRs references
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19484: makefiles/arch/msp430.inc.mk: Fix compilation issues with GCC 12 r=maribu a=maribu
### Contribution description
This fixes the following compilation issues:
/home/maribu/Repos/software/RIOT/cpu/msp430fxyz/periph/gpio.c: In function 'gpio_periph_mode':
/home/maribu/Repos/software/RIOT/cpu/msp430fxyz/periph/gpio.c:95:15: error: array subscript 0 is outside array bounds of 'msp_port_isr_t[0]' [-Werror=array-bounds]
95 | sel = &(isrport->SEL);
| ^~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
by adding `CFLAGS += --param-min-pagesize=0` for GCC 12 (same issue as already fixed for AVR).
and:
/usr/lib/gcc/msp430-elf/12.2.0/../../../../msp430-elf/bin/ld: warning: /home/maribu/Repos/software/RIOT/cpu/msp430_common/ldscripts/xfa.ld contains output sections; did you forget -T?
by adding the missing `-T`.
### Testing procedure
The following should still work:
- `make BOARD=msb-430 -C examples/hello-world`
- `make BOARD=msb-430 -C tests/xfa flash test`
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
GCC 12 gives out of bounds warnings when the resulting address is out
of bounds of what GCC assumes to be the valid address space. It seems
that by default the address 0x0 is not considered valid (which would
be a NULL pointer and typically not mapped in a userspace behind an MMU
scenario), but in fact is valid on bare metal hardware. At least on
AVR and MSP430 this needs to be set. On many Cortex M MCUs 0x0 is also
a valid address (e.g. often the flash is mapped there), but seemingly
for them `--param=min-pagesize=0` is already the default. In any case,
it won't hurt to set it explicit for them as well.
An `INSERT AFTER` directive no longer can refer to a different linker
script included with `-T path/to/script.ld`. Instead, this adds wrapper
linker scripts that just `INCLUDE` the three individual linker scripts.
This way, the xfa.ld can safely refer back to sections defined in
the vendor linker script.
For some reason, this approach cause the exact issue it fixes for
binutils 2.40 with the binutils in the CI. We stick with the old
linker flags with binutils prior 2.40 to be compatible with both
conflicting behaviors.
The best approach would be to come up with something that works across
different versions of binutils; but no such solution materialized.
There seems to be a consensus to go for a more ELF centric approach
whenever possible. J-Link seems to work fine with ELF files, so let's
avoid the extra step to create a bin file from the ELF file prior to
flashing.
While testing examples/micropython I notice that the default of miniterm.py is actually miniterm.
To simplify user setups, this checks for miniterm.py first then falls back to miniterm.
19374: makefiles/boards/stm32: fix DFU_USB_ID handling r=benpicco a=gschorcht
### Contribution description
This PR fixes the still existing problem that an application can't be flashed to a STM32 board if it uses `riotboot_dfu` with default VID/PID (1209:7d02).
In PR #18964 item 1, the problem was already described that an application can't be flashed on a board that is using `riotboot_dfu`. Using for example
```python
FEATURES_REQUIRED+=riotboot USEMODULE+=usbus_dfu make -C examples/saul BOARD=nucleo-f767zi \
PROGRAMMER=dfu-util all riotboot/flash-slot0
```
always leads to error
```python
/home/gs/src/RIOT-Xtensa-ESP.esp-idf-4.4/makefiles/boards/stm32.inc.mk:28: *** DFU_USB_ID is not set. Stop.
/home/gs/src/RIOT-Xtensa-ESP.esp-idf-4.4/makefiles/boot/riotboot.mk:87: recipe for target 'riotboot/bootloader/binfile' failed
```
even if `DFU_USB_ID` variable is set as described in documentation.
```python
FEATURES_REQUIRED+=riotboot USEMODULE+=usbus_dfu make -C examples/saul BOARD=nucleo-f767zi \
PROGRAMMER=dfu-util DFU_USB_ID=1209:7d02 all riotboot/flash-slot0
```
The reason is that the variable `DFU_USB_ID` isn't exported and the check 8dc8bf3567/makefiles/boards/stm32.inc.mk (L27-L29) sees an empty `DFU_USB_ID` variable here. It prevents to use `dfu-util` event though the following `dfu-util.mk` will generate a default value for this variable from the `USB_VID` and `USB_PID` variables if necessary.
Commit 6a76b94c6e0ae97bc743cc90d0811e691a35869e of PR #18964 tried to fix this problem but wasn't merged for any reason.
To fix this problem, the check is completely removed. If a board such as `weact-f4x1cx` uses a DFU boorloader and requires a certain VID/PID combination, board's makefile is responsible to set `DFU_USB_ID` variable.
### Testing procedure
It is not necessary to use a real boad, checking the compilation process is sufficient.
1. Using default VID/PID as described in documentation:
```python
FEATURES_REQUIRED+=riotboot USEMODULE+=usbus_dfu make -C examples/saul BOARD=nucleo-f767zi \
PROGRAMMER=dfu-util all riotboot/flash-slot0
```
can't be compiled without this PR but calls `dfu-util` correctly with this PR using the default VID/PID:
```python
dfu-util --device 1209:7d02 --alt 0 --download examples/saul/bin/nucleo-f767zi/riotboot_files/slot0.1678440536.bin
```
2. Using a VID/PID as described in documentation:
```python
FEATURES_REQUIRED+=riotboot USEMODULE+=usbus_dfu make -C examples/saul BOARD=nucleo-f767zi \
DFU_USB_ID=1209:affe PROGRAMMER=dfu-util all riotboot/flash-slot0
```
can't be compiled without this PR but calls `dfu-util` correctly with this PR using the default VID/PID:
```python
dfu-util --device 1209:affe --alt 0 --download examples/saul/bin/nucleo-f767zi/riotboot_files/slot0.1678440536.bin
```
3. Compiling a board with DFU bootloader
```python
make -C examples/saul flash BOARD=weact-f411ce
```
should still call dfu-util with correct VID/PID:
```python
dfu-util --device 0483:df11 --alt 0 --download /home/gs/src/RIOT-Xtensa-ESP.esp-idf-4.4/examples/saul/bin/weact-f411ce/saul_example.bin --dfuse-address 0x8000000:leave
```
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
The variable `DFU_USB_ID` is used by `dfu-util` to specify the device to be flashed. The STM32 make system prevents `dfu-util` from being used as programmer if this variable is not set, although `dfu-util.mk` generates a default value for this variable from the `USB_VID` and `USB_PID` variables if necessary. Therefore, checking the `DFU_USB_ID` variable is removed here. If a board requires a specific combination of VID/PID for `dfu_util`, it is responsible for setting the `DFU_USB_ID` variable.
Whenever the module of a peripheral driver, i.e., periph_* should be used, the corresponding entry in the
FEATURES_REQUIRED should be added. Conflicts between these modules are
only checked when this entry is present.
17091: USBUS: Add URB support r=benpicco a=bergzand
### Contribution description
This commit adds support for URBs (USB Request/Response Blocks). These
allow for submitting multi-transfer sized buffers with USBUS handling
the individual usbdev xmits. Multiple URBs can be queued at once for a
single endpoint and USBUS will handle them in the order of submission.
OUT endpoint URBs must always consist of a whole number of full-sized
transfers (N x MaxEndpointSize). They will automatically finish after
the endpoint received a transfer less than the endpoint size.
IN endpoints can be arbitrary-sized and do not have to consist of a
whole number of full-sized transmissions. They support a flag to
indicate that the last transfer in the sequence must be less than a full
sized transfer (USBUS_URB_FLAG_AUTO_ZLP) and this adds a zero length
transfer at the end of the transmissions if the last transfer was equal
to the maximum transfer size.
URBs can be cancelled, but if the URB is already being processed it will
be cancelled after the current transmission within the URB is finished.
If it is still in the queue it will immediately be removed from the
queue.
### Testing procedure
- `tests/usbus_cdc_ecm` should still work. Testing one of the usbdev-supported platform should be sufficient here.
### Issues/PRs references
Needs #17064
18148: sys/flash_utils: helpers to store data in flash r=benpicco a=maribu
### Contribution description
This helpers that allow storing, accessing, and working with data in flash that works for both classical Harvard architectures (which do not map flash also into the address space) as well as modern Harvard architectures and von-Neumann architectures.
With this, `examples/default` again runs on the Arduino Uno / Nano. Since this board is still the "entry kit" for many people to embedded hardware, it would be nice to support it with our default example.
### Testing procedure
`examples/default` should run and work on ATmega boards (especially ATmega328P and ATmega32U4 based boards) as well on all other boards now.
### Issues/PRs references
None
Co-authored-by: Koen Zandberg <koen@bergzand.net>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
This commit adds support for URBs (USB Request/Response Blocks). These
allow for submitting multi-transfer sized buffers with USBUS handling
the individual usbdev xmits. Multiple URBs can be queued at once for a
single endpoint and USBUS will handle them in the order of submission.
OUT endpoint URBs must always consist of a whole number of full-sized
transfers (N x MaxEndpointSize). They will automatically finish after
the endpoint received a transfer less than the endpoint size.
IN endpoints can be arbitrary-sized and do not have to consist of a
whole number of full-sized transmissions. They support a flag to
indicate that the last transfer in the sequence must be less than a full
sized transfer (USBUS_URB_FLAG_AUTO_ZLP) and this adds a zero length
transfer at the end of the transmissions if the last transfer was equal
to the maximum transfer size.
URBs can be cancelled, but if the URB is already being processed it will
be cancelled after the current transmission within the URB is finished.
If it is still in the queue it will immediately be removed from the
queue.
18682: pkg/lwext4: add lightweight implementation of the ext2/3/4 filesystem r=benpicco a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Boards with an integrated debugger/programmer that also provides the
serial as UART <--> USB adapter, the TTY serial matches the serial of
the programmer.
This adapts the `serial.inc.mk` to set the `DEBUG_ADAPTER_ID` to the
TTY serial if (and only if) `MOST_RECENT_PORT` *and*
`DEBUG_ADAPTER_ID_IS_TTY_SERIAL` both have a value of `1`. Boards with
an integrated programmer are expected to set
`DEBUG_ADAPTER_ID_IS_TTY_SERIAL` to `1` in their `Makefile.include`.
The previous servo driver didn't provide any benefit over using PWM
directly, as users controlled the servo in terms of PWM duty cycles.
This changes the interface to provide a high level interface that
abstracts the gory PWM details.
In addition, a SAUL layer and auto-initialization is provided.
Co-authored-by: benpicco <benpicco@googlemail.com>
Before the build system used something like
echo "int main(){} void _exit(int n) {(void)n;while(1);}" | LC_ALL=C $(LINK) -xc - -o /dev/null -lc -Wall -Wextra -pedantic <FLAGS_TO_TEST>
to check for flags supported by the compiler (used as linker frontend).
This however no longer works with newlib 4.3.0, which requires the
symbols `_sbrk_r`, `_close_r`, `_lseek_r`, `_read_r`, and `_write_r` to
be present. Instead, now a new file `minimal_linkable.c` was added that
adds all the missing symbols and is used in the linker feature tests
instead.
19057: fuzzing: Add uri_parser setup r=benpicco a=Teufelchen1
Hello!
### Contribution description
This PR is a replacement for PR #18802
In this contribution:
* The variable `AFL_FLAGS` is renamed to `FLAGS_FOR_AFL` because AFL is always complaining that `AFL_FLAGS` is not a valid env var for it. While this is not a bug nor an issue, I found it to be annoying.
* A generic input reader is added to simplify building a test harness
* The usage of this reader is demonstrated by adding a harness for fuzzing the uri_parser
(needs squashing after review)
### Testing procedure
Go to `fuzzing/uri_parser` and run `make all-asan` and `make fuzz` to get some action going.
Also mildly interesting: `./dist/tools/compile_test/compile_like_murdock.py -b native -a fuzzing/uri_parser`
### Issues/PRs references
The original PR #18802 is replaced because the generic input reader is present in both PRs but this PoC harness is much simpler.
19151: examples/gcoap: Fix shell parameter validation r=benpicco a=maribu
### Contribution description
Executing the shell command with an URI-Path that doesn't start with a slash results in an assertion error while composing the client side message. This is suboptimal user experience, so add an explicit check for a valid URI-Path and a dedicated error message.
### Testing procedure
#### In `master`
```
$ make BOARD=microbit-v2 -C examples/gcoap flash term
[...]
2023-01-15 22:23:32,512 # coap get [::1] /.well-known/core
2023-01-15 22:23:32,516 # gcoap_cli: sending msg ID 52272, 23 bytes
2023-01-15 22:23:32,520 # gcoap: response Success, code 2.05, 46 bytes
2023-01-15 22:23:32,524 # </cli/stats>;ct=0;rt="count";obs,</riot/board>
> coap get [::1] foo
2023-01-15 22:23:34,763 # coap get [::1] foo
2023-01-15 22:23:34,763 # 2329
2023-01-15 22:23:34,765 # *** RIOT kernel panic:
2023-01-15 22:23:34,767 # FAILED ASSERTION.
2023-01-15 22:23:34,767 #
2023-01-15 22:23:34,775 # pid | name | state Q | pri | stack ( used) ( free) | base addr | current
2023-01-15 22:23:34,784 # - | isr_stack | - - | - | 512 ( 200) ( 312) | 0x20000000 | 0x200001c8
2023-01-15 22:23:34,793 # 1 | main | running Q | 7 | 1536 ( 1072) ( 464) | 0x200006c0 | 0x2000095c
2023-01-15 22:23:34,802 # 2 | 6lo | bl rx _ | 3 | 1024 ( 328) ( 696) | 0x200036c0 | 0x200039c4
2023-01-15 22:23:34,810 # 3 | ipv6 | bl rx _ | 4 | 1024 ( 460) ( 564) | 0x20001294 | 0x20001574
2023-01-15 22:23:34,819 # 4 | udp | bl rx _ | 5 | 512 ( 300) ( 212) | 0x20003e98 | 0x20003f9c
2023-01-15 22:23:34,828 # 5 | coap | bl anyfl _ | 6 | 1112 ( 704) ( 408) | 0x20000e38 | 0x200011c4
2023-01-15 22:23:34,837 # 6 | nrf802154 | bl anyfl _ | 2 | 896 ( 288) ( 608) | 0x20001a90 | 0x20001d54
2023-01-15 22:23:34,843 # | SUM | | | 6616 ( 3352) ( 3264)
2023-01-15 22:23:34,843 #
2023-01-15 22:23:34,844 # *** halted.
2023-01-15 22:23:34,844 #
```
#### This PR
```
$ make BOARD=microbit-v2 -C examples/gcoap flash term
[...]
make: Entering directory '/home/maribu/Repos/software/RIOT/examples/gcoap'
/home/maribu/Repos/software/RIOT/dist/tools/pyterm/pyterm -p "/dev/ttyACM0" -b "115200"
2023-01-15 22:22:27,842 # Connect to serial port /dev/ttyACM0
Welcome to pyterm!
Type '/exit' to exit.
coap get [::1] /.well-known/core
2023-01-15 22:22:40,042 # coap get [::1] /.well-known/core
2023-01-15 22:22:40,046 # gcoap_cli: sending msg ID 25182, 23 bytes
2023-01-15 22:22:40,050 # gcoap: response Success, code 2.05, 46 bytes
2023-01-15 22:22:40,054 # </cli/stats>;ct=0;rt="count";obs,</riot/board>
> coap get [::1] foo
2023-01-15 22:22:43,858 # coap get [::1] foo
2023-01-15 22:22:43,862 # ERROR: URI-Path must start with a "/"
2023-01-15 22:22:43,866 # usage: coap <get|post|put|ping|proxy|info>
```
### Issues/PRs references
None
Co-authored-by: Teufelchen1 <bennet.blischke@haw-hamburg.de>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
19010: bootloaders/riotboot: add tinyUSB DFU support r=benpicco a=gschorcht
### Contribution description
This PR provides
- the tinyUSB DFU and DFU Runtime support and
- the `riotboot_tinyusb_dfu` bootloader that uses the tinyUSB DFU mode to flash new application images.
~This PR includes PR #18983 for now to be compilable.~
### Testing procedure
1. Use any board that supports the `riotboot´ and `tinyusb_device` features and flash the bootloader first, for example
```
BOARD=nucleo-f767zi make -C bootloaders/riotboot_tinyusb_dfu flash
```
and check that the `riotboot_tinyusb_dfu` bootloader is in DFU mode:
```
dfu-util --list
```
3. Flash a first application using the following command:
```
FEATURES_REQUIRED=riotboot USEMODULE=tinyusb_dfu BOARD=nucleo-f767zi \
make -C tests/saul PROGRAMMER=dfu-util riotboot/flash-slot0
```
and check that the application starts and is seen as upgradable:
```
dfu-util --list
```
4. Restart the node in bootloader DFU mode by:
```
dfu-util -e
```
Flash a second application, for example
```
FEATURES_REQUIRED=riotboot USEMODULE=tinyusb_dfu BOARD=nucleo-f767zi \
make -C tests/shell PROGRAMMER=dfu-util riotboot/flash-slot1
```
and check that the second application starts and is seen as upgradable:
```
dfu-util --list
```
### Issues/PRs references
~Depends on PR #18983~
19149: SECURITY: Describe that declassification is an option r=benpicco a=chrysn
### Contribution description
Our security policy does not contain provisions for the case when what is reported is not what we consider an actual security issue. As it is described now, everything reported through security@ would go through the full treatment, including a point release.
I'm not sure it belongs into the text itself (as it's more about how security reporters interact with the project than internals), but declassification should IMO be backed at least by 3 maintainers, and no strong NACK.
### Issues/PRs references
#19141 followed that procedure after some chat on it on the maintainers channel. (In the discussion, I proposed declassification, with 2.5 people supporting it and one "I was about to, but can we be sure nobody is using it?" voice).
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: chrysn <chrysn@fsfe.org>
With b30efeeb65 a warning was introduced when using `make term` without
the proper toolchain installed (e.g. when using BUILD_IN_DOCKER, but
`term` outside of the docker). This removes this warning
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>
The Makefile function `version_is_greater_or_equal` is used to check if
a version of GNU Make is at least the required one. However, it has
the built-in assumption the version numbers have to format x.y.z,
but Alpine Linux currently ships GNU Make 4.4. This results in
`$(call _pad_number,3,)` which runs `printf '$03d' ''` in the shell,
which is not valid.
This fixes the issue by making `_pad_number` more robust by fall back to
printing `0` with the given padding, if the number given to print is
empty.
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.
This adds the configuration to allow choosing the XDS110 used in
cc13xx-launchpad and cc26xx-launchpad boards via the
`OPENOCD_DEBUG_ADAPTER` variable.
Update the list of target triples to match
`makefiles/arch/riscv.inc.mk`. This fixes compilation with toolchains
other than the obsolete toolchain that uses the incorrect
`riscv-none-embed` triple.
19030: tests/periph_timer_short_relative_set: improve test r=benpicco a=maribu
### Contribution description
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.
### Testing procedure
The test application should consistently fail or succeed, rather than occasionally passing.
### Issues/PRs references
None
19085: makefiles/tests/tests.inc.mk: fix test/available target r=benpicco a=maribu
### Contribution description
`dist/tools/compile_and_test_for_board/compile_and_test_for_board.py` relies on `make test/available` to check if a test if available. However, this so far did not take `TEST_ON_CI_BLACKLIST` and `TEST_ON_CI_WHITELIST` into account, resulting in tests being executed for boards which they are not available. This should fix the issue.
### Testing procedure
#### Expected to fail
```
$ make BOARD=nrf52840dk -C tests/gcoap_fileserver test/available
$ make BOARD=microbit -C tests/log_color test/available
```
(On `master`, they succeed, but fail in this PR.)
#### Expected to succeed
```
$ make BOARD=native -C tests/gcoap_fileserver test/available
$ make BOARD=nrf52840dk -C tests/pkg_edhoc_c test/available
$ make BOARD=nrf52840dk -C tests/log_color test/available
```
(Succeed in both `master` and this PR.)
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
dist/tools/compile_and_test_for_board/compile_and_test_for_board.py
relies on `make test/available` to check if a test if available.
However, this so far did not take `TEST_ON_CI_BLACKLIST` and
`TEST_ON_CI_WHITELIST` into account, resulting in tests being executed
for boards which they are not available. This should fix the issue.
19074: cpu/esp8266: build the SDK bootloader from source r=benpicco a=gschorcht
### Contribution description
This PR is a takeover of PR #17043, which is rebased to the current master and includes some corrections that became necessary after rebasing.
**Copied from description of PR #17043:**
We had four versions of pre-built bootloaders for the esp8266 with different settings of logging and color logging. These bootloaders were manually built from the SDK and shipped with RIOT-OS source code. However there are more settings that affect the bootloader build that are relevant to the app or final board that uses this bootloader. In particular, flash size and flash speed is important for the bootloader to be able to load an app from a large partition table at the fastest speed supported by the board layout and flash chip.
Another example is the UART baudrate of the logging output from the bootloader. The boot ROM will normally start at a baud rate of 74880 (depending on the crystal installed), so it might make sense to keep the UART output at the same speed so we can debug boot modes and bootloader with the same terminal.
This patch builds the `bootloader.bin` file from the ESP8266 SDK source code. The code is built as a module (`esp8266_bootloader`) which at the moment doesn't generate any object code for the application and only produces a `bootloader.bin` file set to the `BOOTLOADER_BIN` make variable for the `esptool.inc.mk` to flash.
The code needs to be compiled and linked with custom rules defined in the module's Makefile since the `bootloader.bin` is its own separate application.
The `BOOTLOADER_BIN` variable is changed from a path relative to the `$(RIOTCPU)/$(CPU)/bin/` directory to be full path. This makes it easier for applications or board to provide their own bootloader binary if needed.
As a result of building the bootloader from source we fixed the issue of having a large partition table.
### Testing procedure
Use following command to flash the application with STDIO UART baudrate of 115200 baud.
```
BAUD=74880 USEMODULE=esp_log_startup make -C tests/shell BOARD=esp8266-esp-12x flash
```
Connect with a terminal programm of your choice (unfortunatly `picocom` and `socat` don't support a baudrate close to 74880), for example:
```
python -m serial.tools.miniterm /dev/ttyUSB0 74880
```
On reset, the `esp8266-esp-12x` node shows the ROM bootloader log output
```
ets Jan 8 2013,rst cause:2, boot mode:(3,7)
load 0x40100000, len 6152, room 16
tail 8
chksum 0x6f
load 0x3ffe8008, len 24, room 0
tail 8
chksum 0x86
load 0x3ffe8020, len 3408, room 0
tail 0
chksum 0x79
```
as well as the second-stage bootloader built by this PR (`ESP-IDF v3.1-51-g913a06a9ac3`) at 74880 baudrate.
```
I (42) boot: ESP-IDF v3.1-51-g913a06a9ac3 2nd stage bootloader
I (42) boot: compile time 11:25:03
I (42) boot: SPI Speed : 26.7MHz
...
I (151) boot: Loaded app from partition at offset 0x10000
```
The application output is seen as garbage since the `esp8266-esp-12x` uses 115200 as baurate by default.
To see all output at a baudrate of 74880 baud, you can use the following command:
```
CFLAGS='-DSTDIO_UART_BAUDRATE=74880' BAUD=74880 USEMODULE=esp_log_startup make -C tests/shell BOARD=esp8266-esp-12x flash
```
If the application is built without options, the ROOM bootloader output will be 74880 baud and the second stage bootloader and application output will be 115200 baud.
### Issues/PRs references
Fixes issue #16402
Co-authored-by: iosabi <iosabi@protonmail.com>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Instead of using a fixed position of the image file in the flash, the variable `FLASHFILE_POS` is used which allows to override the default position of the image in the flash at 0x10000.
We had four versions of pre-built bootloaders for the esp8266 with
different settings of logging and color logging. These bootloaders were
manually built from the SDK and shipped with RIOT-OS source code.
However there are more settings that affect the bootloader build that
are relevant to the app or final board that uses this bootloader. In
particular, flash size and flash speed is important for the bootloader
to be able to load an app from a large partition table at the fastest
speed supported by the board layout and flash chip.
Another example is the UART baudrate of the logging output from the
bootloader. The boot ROM will normally start at a baud rate of 74880
(depending on the crystal installed), so it might make sense to keep
the UART output at the same speed so we can debug boot modes and
bootloader with the same terminal.
This patch builds the bootloader.bin file from the ESP8266 SDK source
code. The code is built as a module (esp8266_bootloader) which at the
moment doesn't generate any object code for the application and only
produces a bootloader.bin file set to the BOOTLOADER_BIN make variable
for the esptool.inc.mk to flash.
The code needs to be compiled and linked with custom rules defined in
the module's Makefile since the bootloader.bin is its own separate
application.
The `BOOTLOADER_BIN` variable is changed from a path relative to the
`$(RIOTCPU)/$(CPU)/bin/` directory to be full path. This makes it easier
for applications or board to provide their own bootloader binary if
needed.
As a result of building the bootloader from source we fixed the issue of
having a large partition table. Fixes#16402.
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).
Boards that are shipped with a DFU bootloader define the `dfu-util` configuration in their `Makefile.include`. However, when `riotboot_dfu` is used as the DFU bootloader, the board's `dfu-util` configuration must be overridden by the configuration as required by `riotboot_dfu` to use it to flash applications. Therefore, all `dfu-util` configurations are defined as overridable in the board's `Makefile.include` and the configuration as required by `riotboot_dfu` is included before the board's `Makefile.include`.
When trying to compile `examples/hello-world` on my 465 MHz Mendocino
I got
/home/benpicco/dev/RIOT/makefiles/toolchain/gnu.inc.mk:29: extraneous text after 'ifneq' directive
Turns out the version of `make` on Archlinux32 is newer than that in
Ubuntu 22.04, which somehow ignored the extra parenthesis.
Turns out this (t)rusty old machine is still good for writing patches :D
Hooking into the existing wrappers for `malloc()`, `calloc()`,
`realloc()`, and `free()`, the new (pseudo) module `malloc_tracing`
prints out the calls to the given functions, the program counter of
the caller, as well as the return result.
The intent is to aid debugging double-frees, invalid frees, or memory
leaks.
Modern binutils complain about segments with RWX permissions. While
this is indeed a bad habit, RIOT ignores segments permissions anyway.
(We do have a `mpu_noexec_ram` module to disable execution of all of
RAM, which would do so regardless of the segment permission.) So for
now, we can safely just disable the warning.
This fixes:
/usr/lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld: warning: /home/maribu/Repos/software/RIOT/examples/default/bin/nucleo-f767zi/default.elf has a LOAD segment with RWX permissions
collect2: error: ld returned 1 exit status
The test for the requirement of disabling wchar_t size warnings assumed
that $(CC) is used for linking, instead of $(LINK). With GCC $(LINK)
and $(CC) happen to be (in most cases) identical, but with LLVM they
are not. This results in issues with compiling with LLVM.
GCC on some platforms does need an executable stack to generate
trampoline code, but use of nested functions is not allowed in
RIOT's code base anyway.
This allows including C headers from C++. It sadly reduced the
diagnostics on C++ code as well, were there warning may make sense as
unintended side effect. We may be able to drop that later on, when more
C APIs are properly wrapped in native C++ APIs, so that C headers do no
longer need to be compatible with C++ compilers.
In an ideal world everyone would just install `gdb-multiarch` and be
happy. However, some MCUs need magic GDB versions sprinkled with
unicorn-stardust-Espressif-patches...
Since there is little reason to have `$(target)-gdb` installed in
addition to `gdb-multiarch` if `gdb-multiarch` would work fine, let's
assume the user wants to use `$(target)-gdb` when present over
`gdb-multiarch`.
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Add USE_MODULE += "stdio_uart_onlcr" to enable it.
This is named after the "onlcr" stty flag, which does the same thing.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Model the LoRaWAN integration to GNRC's netif command (ifconfig) as
submodule of it, namely `shell_cmd_gnrc_netif_lorawan`.
This should fix a regression introduced by
https://github.com/RIOT-OS/RIOT/pull/18355
When using podman instead of docker the registry is not set by default.
Docker has a builtin registry default "docker.io". Podman does not have a
default. By specifying the registry explicitly both tools can be used.
With RISC-V being a relatively young toolchain, a lot of inconsistencies
between different toolchains are to be found that differ in the target
triple and the flags supported. This build system performs run-time
tests to detect the toolchain and supported flags.
With `BUILD_IN_DOCKER=1` issues arise, as this checks are performed
outside of the docker container. However, the host may have no RISC-V
toolchain installed or a different toolchain, so there is little reason
in performing this detection then. Instead, a hard coded target triple
and supported flags are provided when using `BUILD_IN_DOCKER=1`.
If `AVRDUDE_PROGRAMMER` is already set to a programmer that is also
capable of debugging, we can assume that typically the user will want
to use the same hardware for debugging. Thus, let `AVR_DEBUGDEVICE`
default to the matching hardware.
`tiny_strerror()` is a drop-in replacement for `strerror()`, but
instead of a long help message it returns the much shorter macro name
matching the given number.
The (pseudo-)module `tiny_strerror_as_strerror` can be used to
replace all calls to `strerror()` with calls to `tiny_strerror()`.
Previously `shell_commands` was a "catch-all" module that included
shell commands for each and every used module that has a shell
companion. Instead, the new `shell_cmds` module is now used to provide
shell commands as individually selectable submodules, e.g.
`cmd_gnrc_icmpv6_echo` now provides the ICMPv6 echo command (a.k.a.
ping).
To still have a "catch all" module to pull in shell commands of modules
already used, `shell_cmds_default` was introduced. `shell_commands`
depends now on `shell_cmds_default` for backward compatibility, but
has been deprecated. New apps should use `shell_cmds_default`
instead.
For a handful of shell commands individual selection was already
possible. Those modules now depend on the corresponding `cmd_%` module
and they have been deprecated.
Add tracing support via GPIOs to trace the basic state of the Ethernet
peripheral. The following signals are provided:
- One GPIO pin is toggled on entry of the Ethernet ISR
- On TX start an GPIO is set, on TX completion it is cleared
- On RX complete an GPIO is set, once this is passed to the upper layer
the GPIO is cleared again
In order to reduce the overhead, GPIO LL is used. By default the
on-board LEDs are used as tracing GPIOs. This makes it easy to debug
when the state machine gets stuck without the need to attach a scope or
logic analyzer.
JLink presumably has information about the device's RAM available
internally. Not passing the precise symbol area (which would be
available in the ELF file) because a) that'd make the terminal break
when the flashed firmware does not equal the built one, and b) that
would introduce a dependency from `term` to the ELF file that other
terminals don't have.
When `stdio_cdc_acm` is used, assume `"RIOT-os\.org"` as vendor string
and `$(BOARD)` being used as model string. This is the default
behavior in RIOT since eaace28804
After introducing #18423 there are occasional messages that still happen.
These messages cause a diff output when testing with TEST_KCONFIG=1.
This then causes a failure when comparing make/kconfig modules and packages.
A if `netdev_driver_t::confirm_send()` is provided, it provides the
new netdev API. However, detecting the API at runtime and handling
both API styles comes at a cost. This can be optimized in case only
new or only old style netdevs are in use.
To do so, this adds the pseudo modules `netdev_legacy_api` and
`netdev_new_api`. As right now no netdev actually implements the new
API, all netdevs pull in `netdev_legacy_api`. If `netdev_legacy_api` is
in used but `netdev_new_api` is not, we can safely assume at compile
time that only legacy netdevs are in use. Similar, if only
`netdev_new_api` is used, only support for the new API is needed. Only
when both are in use, run time checks are needed.
This provides two helper function to check for a netif if the
corresponding netdev implements the old or the new API. (With one
being the inverse of the other.) They are suitable for constant folding
when only new or only legacy devices are in use. Consequently, dead
branches should be eliminated by the optimizer.
Allow issuing a reset to bootloader sequence by abusing the RTS and
the DTR pins of a TTL adapter. This makes flashing via UART much
more convenient, as no jumpers need to be placed to select booting to
the bootloader / flash and no reset buttons need to be pressed.
