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`.
Nightlies are currently failing as there is a difference between make
and kconfig.
This tries to match the kconfig with the makefile dep.
The only issue is the
```
ifneq (,$(filter netdev,$(USEMODULE)))
USEMODULE += netdev_ieee802154_submac
endif
```
which may have the same effect as select
HAVE_IEEE802154_RADIO_HAL_INTERFACE.
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.
- Explain the reason on why the test fails if it fails
- Relax offset for ZTIMER_USEC on native, as this depends on the jitter
emitted by the non-realtime OS native is running on
fixes issue #18490
Previously `tests/pkg_littlefs2` crashed on the `samr21-xpro`. This
now aligns the buffers in `littlefs2_desc_t` to the alignment
requirement of `uint32_t`.
Specifically the issue causing the crash at hand was that
`struct lfs_free::buffer` is of type `uint32_t *`, so access are
expected to be aligned to `uint32_t`. After this commit, this
assumption is fulfilled.
Previously `tests/pkg_littlefs` crashed on the `samr21-xpro`. This
now aligns the buffers in `littlefs_desc_t` to the alignment
requirement of `uint32_t`.
Specifically the issue causing the crash at hand was that
`lfs_free_t::buffer` is of type `uint32_t *`, so access are expected
to be aligned to `uint32_t`. After this commit, this assumption is
fulfilled.
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.
