This commits add documentation to the HDC1000 params and adds generic
exclude patters to the doc check, so that when boards provide custom
HDC1000 params they do not need to document them again. The reasoning
is that the documentation in the central place is sufficient.
This commits add documentation to the FXOS8700 params and adds generic
exclude patters to the doc check, so that when boards provide custom
FXOS8700 params they do not need to document them again. The reasoning
is that the documentation in the central place is sufficient.
In addition, a generic exclude patter is added to match FXOS8700_REG_*,
as the register names are relatively self-explaining and an
implementation detail of the driver that doesn't need public
documentation.
This commits add documentation to the AT86RF2xx params and adds generic
exclude patters to the doc check, so that when boards provide custom
AT86RF2xx params they do not need to document them again. The reasoning
is that the documentation in the central place is sufficient.
Add generic patterns to allow XTIMER_DEV, XTIMER_HZ, XTIMER_WIDTH,
XTIMER_CHAN, XTIMER_BACKOFF, and XTIMER_ISR_BACKOFF to be undocumented.
The reasoning is that having them documented once is enough and warnings
for missing doc in every boards is just noise.
This commits add documentation to the TMP00X params and adds generic
exclude patters to the doc check, so that when boards provide custom
TMP00X params they do not need to document them again. The reasoning is
that the documentation in the central place is sufficient.
This commits add documentation to the pulse counter params and adds
generic exclude patters to the doc check, so that when boards provide
custom pulse counter params they do not need to document them again. The
reasoning is that the documentation in the central place is sufficient.
This commits add documentation to the PIR params and adds generic
exclude patters to the doc check, so that when boards provide custom PIR
params they do not need to document them again. The reasoning is that
the documentation in the central place is sufficient.
19031: cpu/stm32/periph_timer: implement timer_set() r=benpicco a=maribu
### Contribution description
The fallback implementation of timer_set() in `drivers/periph_common` is known to fail on short relative sets. This adds a robust implementation.
### Testing procedure
Run `tests/periph_timer_short_relative_set` at least a few dozen times (or use https://github.com/RIOT-OS/RIOT/pull/19030 to have a few dozen repetitions of the test case in a single run of the test application). It should now succeed.
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
18632: tests/thread_float: do not overload slow MCUs with IRQs r=kaspar030 a=maribu
### Contribution description
If the regular context switches are triggered too fast, slow MCUs will be able to spent little time on actually progressing in the test. This will scale the IRQ rate with the CPU clock as a crude way too keep load within limits.
### Testing procedure
The unit test should now pass on the Microduino CoreRF
```
$ make BOARD=microduino-corerf AVRDUDE_PROGRAMMER=dragon_jtag -C tests/thread_float flash test
make: Entering directory '/home/maribu/Repos/software/RIOT/tests/thread_float'
Building application "tests_thread_float" for "microduino-corerf" with MCU "atmega128rfa1".
[...]
text data bss dec hex filename
12834 520 3003 16357 3fe5 /home/maribu/Repos/software/RIOT/tests/thread_float/bin/microduino-corerf/tests_thread_float.elf
avrdude -c dragon_jtag -p m128rfa1 -U flash:w:/home/maribu/Repos/software/RIOT/tests/thread_float/bin/microduino-corerf/tests_thread_float.hex
[...]
Welcome to pyterm!
Type '/exit' to exit.
READY
s
START
main(): This is RIOT! (Version: 2022.10-devel-858-g18566-tests/thread_float)
THREADS CREATED
Context switch every 3125 µs
{ "threads": [{ "name": "idle", "stack_size": 192, "stack_used": 88 }]}
{ "threads": [{ "name": "main", "stack_size": 640, "stack_used": 220 }]}
THREAD t1 start
THREAD t2 start
THREAD t3 start
t1: 141.443770
t3: 141.466810
t1: 141.443770
t3: 141.466810
t1: 141.443770
t3: 141.466810
t1: 141.443770
t3: 141.466810
t1: 141.443770
t3: 141.466810
t1: 141.443770
t3: 141.466810
t1: 141.443770
make: Leaving directory '/home/maribu/Repos/software/RIOT/tests/thread_float'
```
(~~Note: The idle thread exiting is something that should never occur. I guess the culprit may be `cpu_switch_context_exit()` messing things up when the main thread exits. But that is not directly related to what this PR aims to fix. Adding a `thread_sleep()` at the end of `main()` does indeed prevent the idle thread from exiting.~~
Update: That's expected. The idle thread stats are printed on exit of the main thread, the idle thread does not actually exit.)
### Issues/PRs references
Fixes https://github.com/RIOT-OS/RIOT/issues/16908 maybe?
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
19087: cpu/qn908x/periph_timer: Implement timer_set() r=kaspar030 a=maribu
### Contribution description
This fixes test failures in tests/periph_timer_short_relative_set.
Note: This differs a bit from the implementation in e.g. nRF5x or STM32 in that it always briefly pauses the timer. The issue is that when running the timer can take a few ticks to actually react to the new compare target. So even if the previously written target is still in the future, the timer may not fire anyway. Pausing the timer while setting and setting the target at least one higher than the current count reliably triggers the IRQ.
### Testing procedure
Run `tests/periph_timer_short_relative_set` at least a few dozen times (or use https://github.com/RIOT-OS/RIOT/pull/19030 to have a few dozen repetitions of the test case in a single run of the test application). It should now succeed.
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
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>
18950: tests/unittests: add unit tests for core_mbox r=benpicco a=maribu
### Contribution description
As the title says
### Testing procedure
The test cases are run on `native` by Murdock anyway.
### Issues/PRs references
Split out of https://github.com/RIOT-OS/RIOT/pull/18949
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
This fixes test failures in tests/periph_timer_short_relative_set.
Note: This differs a bit from the implementation in e.g. nRF5x or STM32
in that it always briefly pauses the timer. The issue is that when
running the timer can take a few ticks to actually react to the new
compare target. So even if the previously written target is still in
the future, the timer may not fire anyway. Pausing the timer while
setting and setting the target at least one higher than the current
count reliably triggers the IRQ.
If the regular context switches are triggered too fast, slow MCUs
will be able to spent little time on actually progressing in the
test. This will scale the IRQ rate with the CPU clock as a crude way
too keep load within limits.
19037: sys/usb, pkg/tinyusb: move USB board reset from highlevel STDIO to CDC ACM r=dylad a=gschorcht
### Contribution description
The USB board reset function `usb_board_reset_coding_cb` can be used on any CDC-ACM interface, even if the CDC ACM interface is not used as high-level STDIO. Therefore, this PR provides the following changes:
- The call of the board reset function `usb_board_reset_coding_cb` from USBUS stack has been moved from the STDIO CDC ACM implementation to the CDC ACM implementation and is thus a feature of any USBUS CDC ACM interface which does not necessarily have to be used as highlevel STDIO.
- The call of the board reset function `usb_board_reset_coding_cb` from tinyUSB stack been moved from module `tinyusb_stdio_cdc_acm` to module `tinyusb_contrib` and is compiled in if the `tinyusb_class_cdc` module is used together the `tinyusb_device` module. Thus, it is now a feature of the tinyUSB CDC ACM interface, which does not necessarily have to be used as highlevel STDIO.
- The `usb_board_reset` module defines the `usb_board_reset_in_bootloader` function as a weak symbol to be used when reset in bootloader if no real implementation of this function is compiled in and the `riotboot_reset` module is not used. It only prints an error message that the reset in bootloader is not supported. This is necessary if the module `usb_board_reset` is used to be able to restart the board with an application via a USB CDC ACM interface, but the board's bootloader does not support the reset in bootloader feature.
- A test application has been added that either uses the highlevel STDIO `stdio_acm_cdc` or creates a CDC-ACM interface to enable board resets via USB. If the `usbus_dfu` module is used, it also initializes the DFU interface to be able to work together with the `riotboot_dfu` bootloader.
### Testing procedure
1. Use a board with a bootloader that supports the reset in bootloader via USB, but don't use the highlevel STDIO to check that it works with `usbus_cdc_acm`, for example:
```python
USEMODULE=stdio_uart BOARD=arduino-mkr1000 make -C tests/usb_board_reset flash
```
After reset in application with command
```python
stty -F /dev/ttyACM0 raw ispeed 600 ospeed 600 cs8 -cstopb ignpar eol 255 eof 255
```
command `dmesg` should give an output like the following with RIOT's test VID/PID:
```python
dmesg
[1745182.057403] usb 1-4.1.2: new full-speed USB device number 69 using xhci_hcd
[1745182.160386] usb 1-4.1.2: New USB device found, idVendor=1209, idProduct=7d01, bcdDevice= 1.00
[1745182.160390] usb 1-4.1.2: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[1745182.160392] usb 1-4.1.2: Product: arduino-mkr1000
[1745182.160393] usb 1-4.1.2: Manufacturer: RIOT-os.org
[1745182.160395] usb 1-4.1.2: SerialNumber: 6B6C2CA5229020D8
[1745182.170982] cdc_acm 1-4.1.2:1.0: ttyACM0: USB ACM device
```
After reset in bootloader with command
```python
stty -F /dev/ttyACM0 raw ispeed 1200 ospeed 1200 cs8 -cstopb ignpar eol 255 eof 255
```
command `dmesg` should give an output like the following with vendor VID/PID:
```python
[1746220.443792] usb 1-4.1.2: new full-speed USB device number 70 using xhci_hcd
[1746220.544705] usb 1-4.1.2: New USB device found, idVendor=2341, idProduct=024e, bcdDevice= 2.00
[1746220.544708] usb 1-4.1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[1746220.553471] cdc_acm 1-4.1.2:1.0: ttyACM0: USB ACM device
```
2. Test the same as in 1., but this time use the highlevel STDIO to check that there is no regression and it still works with `stdio_cdc_acm`, for example:
```python
BOARD=arduino-mkr1000 make -C tests/usb_board_reset flash
```
3. Use a board that supports `riotboot_dfu` but doesn't use the highlevel STDIO and flash the `riotboot_dfu` bootloader, for example:
```python
BOARD=stm32f429i-disc1 make -C bootloaders/riotboot_dfu flash term
```
Once the bootloader is flashed, command `dfu-util --list` should give something like the following:
```python
Found DFU: [1209:7d02] ver=0100, devnum=14, cfg=1, intf=0, path="1-2", alt=1, name="RIOT-OS Slot 1", serial="6591620BCB270283"
Found DFU: [1209:7d02] ver=0100, devnum=14, cfg=1, intf=0, path="1-2", alt=0, name="RIOT-OS Slot 0", serial="6591620BCB270283"
```
If the output gives only
```python
Found Runtime: [1209:7d00] ver=0100, devnum=123, cfg=1, intf=0, path="1-2", alt=0, name="RIOT-OS bootloader", serial="6591620BCB270283"
```
an application is already running in DFU Runtime mode. Use `dfu-util -e` to restart it in bootloader DFU mode.
Then flash the test application, for example:
```python
FEATURES_REQUIRED=riotboot USEMODULE='usbus_dfu riotboot_reset' \
BOARD=stm32f429i-disc1 make -C tests/usbus_board_reset PROGRAMMER=dfu-util riotboot/flash-slot0
```
Once the test application is flashed, command `dfu-util --list` should give:
```python
Found Runtime: [1209:7d00] ver=0100, devnum=123, cfg=1, intf=0, path="1-2", alt=0, name="RIOT-OS bootloader", serial="6591620BCB270283"
```
Now, use command
```python
stty -F /dev/ttyACM1 raw ispeed 600 ospeed 600 cs8 -cstopb ignpar eol 255 eof 255
```
to restart the board in application. Command `dfu-util --list` should give again the following:
```python
Found Runtime: [1209:7d00] ver=0100, devnum=123, cfg=1, intf=0, path="1-2", alt=0, name="RIOT-OS bootloader", serial="6591620BCB270283"
```
That is, the application is running in DFU Runtime mode. Then use command
```python
stty -F /dev/ttyACM1 raw ispeed 1200 ospeed 1200 cs8 -cstopb ignpar eol 255 eof 255
```
to restart the board in bootloader DFU mode. Command `dfu-util --list` should now give the following:
```python
Found DFU: [1209:7d02] ver=0100, devnum=50, cfg=1, intf=0, path="1-2", alt=1, name="RIOT-OS Slot 1", serial="7D156425A950A8EB"
Found DFU: [1209:7d02] ver=0100, devnum=50, cfg=1, intf=0, path="1-2", alt=0, name="RIOT-OS Slot 0", serial="7D156425A950A8EB"
```
That is, the bootloader is in DFU mode and another application can be flash.
4. After a hard reset of the board under 3., try the commands `reboot` and `bootloader`.
5. To check the same for tinyUSB, use the existing tinyUSB application with a CDC ACM interface and add module `usb_board_reset`, for example:
```python
USEMODULE=usb_board_reset BOARD=stm32f429i-disc1 make -C tests/pkg_tinyusb_cdc_msc flash term
```
After flashing, it should be possible to restart the application with command:
```python
stty -F /dev/ttyACM1 raw ispeed 600 ospeed 600 cs8 -cstopb ignpar eol 255 eof 255
```
When using command
```python
stty -F /dev/ttyACM1 raw ispeed 1200 ospeed 1200 cs8 -cstopb ignpar eol 255 eof 255
```
the following error message should be shown in terminal
```python
[cdc-acm] reset in bootloader is not supported
```
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19084: .github/tools-buildtest: use latest version of riot-action and fix build issue with mosquitto.rsmb r=aabadie a=aabadie
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
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.
19083: build system: Fix parallel build with clean r=kaspar030 a=maribu
### Contribution description
It turns out that `make clean all -j 16` previously failed every second time, as a dependency to a generated header (`preprocessor_succesor.h` in this case) is checked and considered to be up to date before running the `clean` target. However, after the `clean` target it is removed.
This fixes:
```
$ BOARD=nrf52840dk make -C examples/emcute_mqttsn clean all --jobs 16
make: Entering directory '/home/maribu/Repos/software/RIOT/examples/emcute_mqttsn'
make: Circular clean <- clean dependency dropped.
Building application "emcute_mqttsn" for "nrf52840dk" with MCU "nrf52".
[...]
cc1: error: /home/maribu/Repos/software/RIOT/examples/emcute_mqttsn/bin/nrf52840dk/preprocessor: No such file or directory [-Werror=missing-include-dirs]
[...]
```
### Testing procedure
Run
```
$ BOARD=nrf52840dk make -C examples/emcute_mqttsn clean all --jobs 16
```
a few times. For me it fails every second time on `master`, but succeeds with this PR every time.
### Issues/PRs references
I was too lazy to open an issue for this :)
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
The test application either uses the USBUS highlevel STDIO module `stdio_acm_cdc` or it creates a CDC ACM interface to enable board reset via USBUS CDC ACM. If the `usbus_dfu` module is used together with the `riotboot_dfu` bootloader, it also initializes the USBUS DFU Runtime interface.
The board reset function can be used on any CDC ACM interface. It is not necessary that the tinyUSB CDC ACM STDIO is used. Therefore, the board reset function is now a feature of the CDC ACM interface that don't require any other functionality.
Definition of a function as weak symbol for reset in bootloader which prints an error message if no real implementation is compiled in and
the module `riotboot_reset` is not used. This is required if the module `usb_board_reset` is used to restart the board with an application via an USB CDC ACM interface, but the board's bootloader does not support a reset in the bootloader.
It turns out that `make clean all -j 16` previously failed every second
time, as a dependency to a generated header (`preprocessor_succesor.h`
in this case) is checked and considered to be up to date before running
the `clean` target. However, after the `clean` target it is removed.
This fixes:
```
$ BOARD=nrf52840dk make -C examples/emcute_mqttsn clean all --jobs 16
make: Entering directory '/home/maribu/Repos/software/RIOT/examples/emcute_mqttsn'
make: Circular clean <- clean dependency dropped.
Building application "emcute_mqttsn" for "nrf52840dk" with MCU "nrf52".
[...]
cc1: error: /home/maribu/Repos/software/RIOT/examples/emcute_mqttsn/bin/nrf52840dk/preprocessor: No such file or directory [-Werror=missing-include-dirs]
[...]
```
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>
19078: cpu/esp32: define FLASHFILE_POS r=benpicco a=gschorcht
### Contribution description
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.
This PR is a prerequisite for the `periph_flashpage` implementation PR #19079.
### Testing procedure
Flashing a ESP32x SoC should work with `FLASHFILE_POS=0x20000`, for example:
```
USEMODULE=esp_log_startup FLASHFILE_POS=0x20000 BOARD=esp32-wroom-32 make -j8 -C tests/shell flash
```
The bootloader output should give `00020000` as offset for the `factory` partition
```
I (75) boot: Partition Table:
I (78) boot: ## Label Usage Type ST Offset Length
I (84) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (91) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (97) boot: 2 factory factory app 00 00 00020000 000199b0
I (104) boot: End of partition table
```
and
```
I (125) esp_image: segment 0: paddr=00020020 vaddr=3f400020 size=02140h ( 8512) map
```
during the load of the image.
### Issues/PRs references
Prerequisite for PR #19079
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19077: cpu/esp32: configurable linker scripts r=benpicco a=gschorcht
### Contribution description
This PR provides configurable linker scripts for ESP32x SoCs.
Using the vendor `memory.ld.in` file and a `sections.ld.in` file instead of the static versions of these files, from which the actual used `memory.ld` and `sections.ld` are generated using the C preprocessor, allows to use the configuration in `sdkconfig.h` as well as Kconfig to define a custom memory layout. For example, it is no longer necessary to maintain different `memory.ld` files for the ESP32 BLE module, since the memory layout is now defined from the values of the configuration.
Note for the review: The `memory.ld.in` files are now simply copies of the manufacturer's `memory.ld.in` files. However, it is not possible to use the vendor's `memory.ld.in` files directly, because they have to be extended further on, e.g. for the `periph_flashpage` implementation.
This PR is prerequisite for the `periph_flashpage` support in PR #19079.
### Testing procedure
Green CI.
### Issues/PRs references
Prerequisite for PR #19079
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Using `sectoins.ld.in` instead of a static `sections.ld`, from which the actual used `sections.ld` is generated with the C preprocessor, allows to use the configuration in `sdkconfig.h` as well as Kconfig to use a custom section layout.
Using the vendor `memory.ld.in` instead of a static `memory.ld`, from which the actual used `memory.ld` is generated with the C preprocessor, allows to use the configuration in `sdkconfig.h` as well as Kconfig to use a custom memory layout. For example, it is no longer necessary to maintain different `memory.ld` files for the ESP32 BLE module, since the memory layout is now defined from the values of the configuration.
The additional dependency of the ELFFILE variable on a LD_SCRIPTS variable allows to define rules for the generation of the used ld files from configurable LD templates.
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.
19064: native: Remove code used for __MACH__ target r=benpicco a=Teufelchen1
### Contribution description
This PR removes code that was used to support macOS as native target.
macOS / `__MACH__` is no longer supported by RIOT on master.
### Testing procedure
If murdock is happy, that should be enough.
Co-authored-by: Teufelchen1 <bennet.blischke@haw-hamburg.de>
19075: drivers/ds3231 fix docs, alarms are supported r=benpicco a=jdavid
### Contribution description
Two changes:
- Remove the text stating that setting alarms is not yet supported, because it is, since PR #16180
- Document DS3231_PARAM_INT_PIN
### Testing procedure
This is only a documentation fix, so there is not code to test.
### Issues/PRs references
Support for setting alarms was implemented in PR #16180
Co-authored-by: J. David Ibáñez <jdavid.ibp@gmail.com>
19035: cpu/nrf5x_common: implement timer_set() r=maribu a=maribu
### Contribution description
The fallback implementation of timer_set() in `drivers/periph_common` is known to fail on short relative sets. This adds a robust implementation.
### Testing procedure
Run `tests/periph_timer_short_relative_set` at least a few dozen times (or use https://github.com/RIOT-OS/RIOT/pull/19030 to have a few dozen repetitions of the test case in a single run of the test application). It should now succeed.
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
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.
