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>
The code did not take into account that valid bus numbers are
0...(COUNT-1).
This patch corrects this. It also makes use of the newly introduced
SOFT_SPI_NUMOF define.
19039: Ensure C locale when querying the compiler for compile commands r=maribu a=janhenke
### Contribution description
This fixes generating the compile commands with localization enabled GCC and non-English shell locale. The python script uses regexes to extract the required information. These only match on the default English output. GCC supports localized output messages which break the regexes used. Instead of matching any possible localization, this fix forces the C locale for message output on the compiler invocation, thus ensuring the regexes can match.
### Testing procedure
Needed: arm-none-eabi.gcc with localization support and non-English system locale.
Invoke the compile-commands make target (`make compile-commands`).
It should generate the `compile_commands.json` file correctly.
### Issues/PRs references
None found, fix was trivial enough to fix it directly.
Co-authored-by: Jan Henke <Jan.Henke@taujhe.de>
GCC supports localized outputs, depending on the currently set locale.
This broke the compile-commands target, as the regexes only match the
English output. By invoking the compiler explicitly with the C locale,
it ensures the expected English language output.
19023: pkg/tinyusb: fix Kconfig problems r=maribu a=gschorcht
### Contribution description
This PR tries to fix the [problems with `tinyUSB` in nightlies](https://ci.riot-os.org/details/d11b383ba0cd45048ed6f8d98abbc0de).
- The `tinyusb_device` feature had to be moved from `boards/common/arduino-zero` definition to the `boards/arduino-zero` definition because the common `arduino-zero` features are also used by `wemos-zero` which uses the `highlevel_stdio` feature via the `stdio_cdc_acm` module.
- The `tinyusb_device` feature had to be removed from Kconfig of board `stm32f429i-disco` since it uses the `highlevel_stdio` feature via the `stdio_cdc_acm` module.
### Testing procedure
Green CI
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
