19179: pkg/nanopb: bump version to 0.4.7 r=benpicco a=benpicco
19180: pkg/lz4: bump version to 1.9.4 r=benpicco a=benpicco
19183: pkg/minmea: bump version r=benpicco a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
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>
17066: sys/irq: Add C++ wrapper using RAII r=maribu a=jenswet
### Contribution description
This adds a C++ wrapper around the `irq.h` API. The wrapper uses RAII to accomplish a convenient and bug resistent use.
A little background: I'm currently writing my master thesis on using C++ for embedded development, at the working group that `@maribu` is part of. For that I will try to add better C++ support to several parts of RIOT and then do some benchmarking and metrics to compare it with the C implementation. For example, I also plan to add a wrapper around i2c, a std::cout drop-in replacement and probably some more about networks or threads.
### Testing procedure
I've added a unit test to verify that the IRQ wrapper calls the original `irq` functions as expected. As C++ and wrapper testing isn't done much so far in this project, I've added two additional headers to ease testing:
1. #17076 - fake functions framework, already merged
2. As there is no framework for C++ unit tests yet, I've added something for this too. Unfortunately the existing frameworks like GoogleTest, CppUTest or CppUnit don't easily compile for embedded or are difficult to integrate in to the RIOT build process. That's why I wrote some (simple) helper functions and macros inspired by the above frameworks. That allows to create C++ tests based on a fixture class with set up and tear down methods. It also allows some simple assertions and is easily extendable for other use cases. It wraps some of the fff functionality too.
Both of this is obviously not required for the initial reason of this PR. But I'd like to provide unit tests for the features that I suggest to introduce where possible. So I'd appreciate some feedback on that too. If you'd prefer a PR without or different tests please let me know.
You can run the test `irq_cpp` locally or on the CI to test the implementation.
Please feel free to give feedback or suggest improvements!
Co-authored-by: Jens Wetterich <jens@wetterich-net.de>
17460: pkg/arduino_adafruit_sensor: add Adafruit Unified Sensor Driver as package r=benpicco a=gschorcht
### Contribution description
This PR provides the [Adafruit Unified Sensor Driver](https://github.com/adafruit/Adafruit_Sensor) as package.
There are a number of Adafruit sensor drivers which all use a common base class `Adafruit_Sensor` from the [Adafruit Unified Sensor Driver](https://github.com/adafruit/Adafruit_Sensor). To support such drivers, the Adafruit Unified Sensor Driver is provided as package.
Adafruit sensor driver for ST LSM9DS0 will be provided as separat PR as package for demonstration and testing.
PR #12518 will be rebased for testing to have an Adafruit sensor driver for a sensor for which there is a native driver in RIOT.
### Testing procedure
Use a board that provides the `arduino` feature and flash
```
BOARD=... make -C tests/pkg_arduino_adafruit_sensor flash test
```
PR #12518 can be used as a more complex test for using the package.
### Issues/PRs references
Prerequisite for PR #12518
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Patching a package creates a new HEAD of the package repository. Using `git describe --tag` to generate a version string used for the ESP8266 bootloader therefore generates a different version string for each new compilation, which in turn results in different hash values of the binaries for the same application in subsequent compilations in CI. To use the commit in `git describe --tag` for commit used by the package, the commit has to specified in the command.
The macros CONCAT(), MIN(), and MAX() are defined over and over again in
RIOT's code base. This de-duplicates the code by moving the macros to a
common place.
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>
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.
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.
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.
18962: pkg/lwip: Force loglevel when using log module r=maribu a=yarrick
18999: Paho: Allow building for 8 and 16 bit platforms r=maribu a=OlegHahm
### Contribution description
Providing a patch to Paho upstream which uses fixed size integers (int32_t) instead of plain int whenever it is used to represent a size of an object.
This patch will allow to build the Paho package for platforms where an integer has a width of less than 32 bit.
This patch is also provided as a PR to the upstream version of Paho (https://github.com/eclipse/paho.mqtt.embedded-c/pull/238) but unfortunately the upstream seems to be unmaintained.
### Testing procedure
Build for a 8 or 16 bit platform that has enough memory for the example, e.g., https://api.riot-os.org/group__boards__atxmega-a1u-xpro.html:
BUILD_IN_DOCKER=1 BOARD=atxmega-a1u-xpro make clean all
Without this PR this build will fail, with the patches applied it will succeed.
### Issues/PRs references
This PR makes #18997 obsolete and thus reverts the change.
19034: boards/nucleo-l496zg: doc improvement r=maribu a=krzysztof-cabaj
### Contribution description
This PR adds to nucleo-l496zg documentation MCU table - similar to those, for example for, Nucleo F103RB, F302R8 or F446RE.
### Testing procedure
```
make doc
xdg-open doc/doxygen/html/group__boards__nucleo-l496zg.html
```
### Issues/PRs references
None
Co-authored-by: Erik Ekman <eekman@google.com>
Co-authored-by: Oleg Hahm <oleg@hobbykeller.org>
Co-authored-by: krzysztof-cabaj <kcabaj@gmail.com>
An alternative device configuration descriptor is required if multiple protocols, e.g. CDC ECM and RNDIS, should be used with same device interface. This commit is a prerequisite for the support of tinyusb netdev driver.
The commit includes the following changes:
- Remaining CONFIG_* symbols are moved to tinyusb_descriptors.h to be visible in all source files.
- Debug output is added to some descriptor callbacks.
- The conditional definitions of CFG_* symbols are changed to unconditional definitions to ensure that Kconfig CONFIG_* symbols are always used.
If the STM32 MCU does not have an internal D+ pullup and there is no dedicated GPIO on the board to simulate a USB disconnect, the D+ GPIO
has to be temporarily configured as an output and pushed down to simulate a disconnect/connect cycle to allow the host to recognize the device. This is done correctly in `cpu/stm32/periph/usbdev_fs.c` but not in tinyUSB STM32 hardware driver. That is, pressing the RESET button doesn't reset the USB connection.
fixup! pkg/tinyusb: fix reset for STM32 boards without internal D+ pullup
lwIP has already used its own log level when deciding what to print.
If we reach the LWIP_PLATFORM_DIAG message no further filtering should
happen, so set the log level to match the macro used.
This fixes the missing IP addresses from ifconfig. Before:
> ifconfig
Iface ET0 HWaddr: 24:0a:c4:e6:0e:9f Link: up State: up
Link type: wired
inet addr: mask: gw:
inet6 addr: scope: link state: valid preferred
inet6 addr: scope: global state: valid preferred
Iface ET1 HWaddr: 24:0a:c4:e6:0e:9c Link: up State: up
Link type: wireless
inet addr: mask: gw:
inet6 addr: scope: link state: valid preferred
inet6 addr: scope: global state: valid preferred
>
With this change:
> ifconfig
Iface ET0 HWaddr: 24:0a:c4:e6:0e:9f Link: up State: up
Link type: wired
inet addr: 10.4.4.81 mask: 255.255.254.0 gw: 10.4.4.1
inet6 addr: fe80:0:0:0:260a:c4ff:fee6:e9f scope: link state: valid preferred
inet6 addr: 2001:db8:0:0:260a:c4ff:fee6:e9f scope: global state: valid preferred
Iface ET1 HWaddr: 24:0a:c4:e6:0e:9c Link: up State: up
Link type: wireless
inet addr: 10.4.4.86 mask: 255.255.254.0 gw: 10.4.4.1
inet6 addr: fe80:0:0:0:260a:c4ff:fee6:e9c scope: link state: valid preferred
inet6 addr: 2001:db8:0:0:260a:c4ff:fee6:e9c scope: global state: valid preferred
>
The commit 98478e02fe removed the setting of the CFG_TUD_MAX_SPEED define to OPT_MODE_DEFAULT_SPEED. This setting is usually not required since CFG_TUD_MAX_SPEED is determined from CFG_TUSB_RHPORT{0,1}_MODE. However, this does not work for STM32F429I-DISC1 where the HS port is used via the internal FS-PHY. Therefore the default speed setting is added again.
With PR #18835, the automatic generation of descriptors for the most common device classes and their handling was introduced. The update of the documentation was forgotten.
This fixes compilation with GCC >= 12.x, which is unhappy about the use
after free:
/home/maribu/Repos/software/RIOT/build/pkg/ccn-lite/src/ccnl-core/src/ccnl-relay.c: In function 'ccnl_fib_rem_entry':
/home/maribu/Repos/software/RIOT/build/pkg/ccn-lite/src/ccnl-core/src/ccnl-relay.c:916:16: error: pointer 'fwd' used after 'free' [-Werror=use-after-free]
916 | if (fwd->face) {
| ~~~^~~~~~
In file included from /home/maribu/Repos/software/RIOT/build/pkg/ccn-lite/src/ccnl-core/src/ccnl-relay.c:33:
/home/maribu/Repos/software/RIOT/build/pkg/ccn-lite/src/ccnl-core/../ccnl-riot/include/ccn-lite-riot.h:52:41: note: call to 'free' here
52 | #define ccnl_free(p) free(p)
| ^~~~~~~
/home/maribu/Repos/software/RIOT/build/pkg/ccn-lite/src/ccnl-core/src/ccnl-relay.c:910:13: note: in expansion of macro 'ccnl_free'
910 | ccnl_free(fwd);
| ^~~~~~~~~
/home/maribu/Repos/software/RIOT/build/pkg/ccn-lite/src/ccnl-core/src/ccnl-relay.c: In function 'ccnl_fib_rem_entry':
/home/maribu/Repos/software/RIOT/build/pkg/ccn-lite/src/ccnl-core/src/ccnl-relay.c:916:16: error: pointer 'fwd' used after 'free' [-Werror=use-after-free]
916 | if (fwd->face) {
| ~~~^~~~~~
In file included from /home/maribu/Repos/software/RIOT/build/pkg/ccn-lite/src/ccnl-core/src/ccnl-relay.c:33:
/home/maribu/Repos/software/RIOT/build/pkg/ccn-lite/src/ccnl-riot/include/ccn-lite-riot.h:52:41: note: call to free' here
52 | #define ccnl_free(p) free(p)
| ^~~~~~~
/home/maribu/Repos/software/RIOT/build/pkg/ccn-lite/src/ccnl-core/src/ccnl-relay.c:910:13: note: in expansion of macro 'ccnl_free'
910 | ccnl_free(fwd);
| ^~~~~~~~~
This fixes a signature mismatch between forward declaration and
implementation, which in turn fixes the following error during
compilation:
/home/maribu/Repos/software/RIOT/build/pkg/wolfssl/wolfcrypt/src/ge_low_mem.c:179:30: error: argument 1 of type 'unsigned char[64]' with mismatched bound [-Werror=array-parameter=]
179 | void sc_reduce(unsigned char x[64])
| ~~~~~~~~~~~~~~^~~~~
In file included from /home/maribu/Repos/software/RIOT/build/pkg/wolfssl/wolfcrypt/src/ge_low_mem.c:34:
/home/maribu/Repos/software/RIOT/build/pkg/wolfssl/wolfssl/wolfcrypt/ge_operations.h:81:36: note: previously declared as 'byte *' {aka 'unsigned char *'}
81 | WOLFSSL_LOCAL void sc_reduce(byte* s);
| ~~~~~~^
There are STM32 families where all models use only the Synopsys DWC2 USB OTG core while others completely use only the USB Device FS core. For these families then either the driver `drivers/usbdev_synopsys_dwc2` or the driver `cpu/stm32/periph/usbdev` is used depending on the respective family. However, the STM32 families F1 and L4 use both cores. The correct driver must therefore be selected depending on the CPU line or CPU model.
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.
`CFG_TUD_MAX_SPEED` definition isn't required since tinyUSB derives it from `TUD_RHPORT_MODE` if not defined or uses the maximum speed the MCU supports by default.
The definition in `pkg/esp32_sdk/Makefile.include` was evaluated by
`make` after the include paths were already set, resulting in
`ESP32_SDK_DIR` being empty in
INCLUDES += -I$(ESP32_SDK_DIR)/components
[...]
This in turn resulted in
cc1: error: /components: No such file or directory [-Werror=missing-include-dirs]
[...]
The cpus for the sam*xpro series have some differences in make and Kconfig
Kconfig seems to be more verbose and make assumes samr34-xpro just uses saml21
Without initializing async_cb to NULL it might be a value != NULL,
which leads to sock->async_cb.gen() being called mistakenly in _netconn_cb.
gnrc_sock already does it with "reg->async_cb.generic = NULL;"
Makefiles don't do comments, so these were forwarded into the variable.
*Most* users would expand the arguments to a shell where it'd be
ignored, but not all of them.
Contributes-To: https://github.com/RIOT-OS/RIOT/pull/18489
(This is also where the one version that is added here was removed).
As a leftovers from https://github.com/RIOT-OS/RIOT/pull/18355 are still
present that check for `MODULE_SHELL_COMMANDS` rather than
`MODULE_SHELL_CMDS`. This updates the conditionals as needed.
- most were trivial
- missing group close or open
- extra space
- no doxygen comment
- name commad might open an implicit group
this hould also be implicit cosed but does not happen somtimes
- crazy: internal declared groups have to be closed internal
Otherwise if the cable is connected at boot the immediate NETDEV_EVENT_ISR
event signaling connection will not trigger the isr, and the netdev will not
clear its pending event.
This explains why the connect/rx event clash seen in "esp32/eth: Don't
overwrite queued event with RX packet" (95196fb7e4) only happened
with lwIP.
Now on my ESP32 board with Ethernet the issue was the opposite (since IDF
upgrade), the stuck connected event blocked receive from working. After
this change 95196fb7e4 can be reverted since even early events are
consumed properly.
Enables the SDL driver for LVGL to utilize a user prescribed width/height for display resolution when utilizing SDL, or rely on the SDL_HOR/VER_RES provided by lv_drv_conf.h in lv_drivers
The definition of gettimeofday in pkg/ccn-lite leads to multiple definitions on platforms where gettimeofday is compiled in in newlib. Therefore, the gettimeofday function in pkg/ccn-lite is declared as weak symbol.
The package uses the nRFx SDK package `nrfx`. In addition, the `mynewt-nimble` repository contains some files (`porting/nimble/src/hal_timer.c` and `porting/npl/riot/src/nrf5x_isr.c`) that are compilable only for nRF MCUs. To allow the compilation for other platforms, the use of the `nrfx` package and the compilation of these files are now dependent on the use of any nRF5x MCU.
If the package is used for a controller that supports the HCI UART H4 transport layer protocol, the functions implemented in `nimble/transport/common/hci_h4` are very useful to deal with H4 formatted packages. If required, they can be enabled by module `nimble_transport_hci_h4`.
Using a `BLE_ADDR_RANDOM` as the peer address type allows connecting only to peers that have a static random address. Deriving the peer address type from the peer address is simple and allows connections to be established with peers that have either a public or
static random address.
If the Bluetooth 5 Advertising Extension is enabled by the `nimble_adv_ext` module, up to 3 events come in from the controller during connection establishment before they are processed by the host. The default size of the event queue `MYNEWT_VAL_BLE_TRANSPORT_EVT_COUNT` with only 2 entries is therefore too small and the connection establishment fails.
To control the compilation of NimBLE modules `nimble_*_ext` that require the Bluetooth 5 Advertising Extension, the `ble_adv_ext` is introduced to indicate that a platform supports this feature.
The patches include the following changes:
- define ARRAY_SIZE in `component/spi_flash/spi_flash_timing_tuning.c` only if it is not yet defined by RIOT macros
- add alternative implementations for`spi_flash_disable_interrupts_caches_and_other_cpu` and `spi_flash_enable_interrupts_caches_and_other_cpu` if compiled for RIOT
- fix the undefined reference to `rtc_gpio_force_hold_en_all` in `components/driver/gpio.c`
- rename the bootloader patch to fix the serial number
This mostly converts switch statements from double indent style to
Linux kernel style, as required per the coding convention.
From the C compiler perspective, this is a whitespace only change.
It turns out that #18287 needs to be somewhat reverted.
The make behaviour requires use to add psuedomodules for packages
that are not compiled (ie header only).
The only difference from the revert is that the module is no longer
selected in Kconfig so it will match the modules used list.
There was a mismatch between Kconfig and make, after some digging it
appears that the make never used the emlearn module, only the package.
This removes the emlearn pseudomodule from make since nothing selects it
and removes the MODULE_EMLEARN from Kconfig to match the make dependency
resolution.
