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.
19066: examples/gnrc_border_router: Restore UHCP conditional default r=chrysn a=chrysn
The space inside the expression made the ifneq always non-equal; the intended behavior is "if we're using any of these interfaces, or REUSE_TAP is set".
Co-authored-by: chrysn <chrysn@fsfe.org>
The space inside the expression made the ifneq always non-equal; the
intended behavior is "if we're using any of these interfaces, or
REUSE_TAP is set".
18756: drivers/usbdev_synopsys_dwc2: add EFM32 support r=chrysn a=gschorcht
### Contribution description
This PR provides the changes for the Synopsys USB OTG IP core DWC2 driver for EFM32 MCUs. It also provides the changes of the board definition for `stk3600` and `stk3700` for testing.
### Testing procedure
`tests/usbus_hid` should work on the EFM32 boards `stk3600` (EFM32LG family) and `stk3700` (EFM32GG family).
It is already tested for a `sltb009a` board (EFM32GG12 family).
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
A number of Adafruit sensor drivers use the class Adafruit_Sensor from the Adafruit Unified Sensor Driver. To support such drivers, the Adafruit Unified Sensor Driver is imported as package.
19048: drivers/sht2x: some small improvements r=benpicco a=gschorcht
### Contribution description
This PR provides the following improvements for the SHT2x driver:
- migration to `ztimer` 8a605517f5 and 367549940de3bd8910052334c34af028d4992741
- floating point arithmetics replaced by integer arithmetics f424caebbfec9f2be56aa2337c6cc09dba5b97d6
- fix of sleep times (typical times replaced by maximum times as recommended by the datasheet) 13615c72094b8541ee62c3e8ed5a36dc4d725fd0
- release of the I2C bus during sleep 9415c216cfab734520ef98dd00b350c22f342c60
- Kconfig configuration of sensor parameters added dadbbcb4c328350893db53ba6743d03cb34ecc1c
- no-hold mode is now the default mode instead of the hold mode
Regarding the sleep times: The typical measurement times were used as sleep times. According to the datasheet, typical measurements are only recommended for calculating energy consumption, while maximum values should be used for calculating waiting times in communication. Therefore, the typical time values were replaced by maximum time values for the sleep in no-hold mode.
Regarding the hold mode: In hold mode, the sensor uses clock stretching until the measurement results can be read by the MCU. This blocks both the I2C bus and the MCU during the entire measurement, which can take up to 85 ms if I2C is not interrupt-driven. Therefore, the no-hold mode is now used by default, where the calling thread sleeps during the measurement, but the MCU is not completely blocked. Furthermore, the hold mode requires that the MCU supports clock stretching. Even if the MCU supports clock stretching, the hold mode with clock stretching doesn't seem to work with different MCUs. I couldn't get it working for STM32 and ESP32.
Regarding the I2C bus during sleep: If the no-hold mode is used and the calling thread sleeps up to 85 ms, it makes sense to release the I2C bus until the measurement results are available.
### Testing procedure
`tests/driver_sht2x` should still work.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
According to the data sheet, typical times are recommended for calculating energy consumption, while maximum values should be used for calculating waiting times in communication. Therefore, the typical time values are replaced by maximum time values for sleep.
19033: Fix soft spi bugs r=aabadie a=Enoch247
### Contribution description
This PR contains some small bug and spelling fixes I noticed while reading the soft_spi code while using it as an example for writing my own driver. See the commit comments for details of each change.
### Testing procedure
I compiled, but did not run, tests/driver_soft_spi. The change is minor and verifiable by simply looking at the code.
### Issues/PRs references
- None
Co-authored-by: Joshua DeWeese <jdeweese@primecontrols.com>
