samples: bluetooth: central_iso: fix synchronization of data submission #72622
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,3 +1,6 @@ | ||
| CONFIG_BT=y | ||
| # Max 2 PDUs per SDU (BN = 2) | ||
| CONFIG_BT_ISO_TX_MTU=494 | ||
|
|
||
| CONFIG_LOG=y | ||
| CONFIG_BT_ISO_CENTRAL=y | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,21 +1,15 @@ | ||
| sample: | ||
| description: Bluetooth ISO central (client) sample | ||
| name: Bluetooth ISO central (client) sample | ||
| common: | ||
| harness: bluetooth | ||
| platform_allow: | ||
| - nrf52_bsim | ||
| - nrf52833dk/nrf52833 | ||
| integration_platforms: | ||
| - nrf52833dk/nrf52833 | ||
| tags: bluetooth | ||
| tests: | ||
| sample.bluetooth.central_iso: {} | ||
| sample.bluetooth.central_iso.bt_ll_sw_split: | ||
| extra_args: OVERLAY_CONFIG=overlay-bt_ll_sw_split.conf | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,33 @@ | ||
| /* | ||
| * Copyright 2024, Florian Grandel, grandcentrix GmbH | ||
| * | ||
| * SPDX-License-Identifier: Apache-2.0 | ||
| */ | ||
|
|
||
| /** | ||
| * @file | ||
| * | ||
| * @brief Bluetooth clock hardware abstraction for nRF5x | ||
| * | ||
| * @details Currently, there is no way to access the Bluetooth clock | ||
|
There was a problem hiding this comment. As you have seen earlier, the timestamps in the HCI packets are defined by the controller. Looking at this it looks like the only feasible way forward:
The drawback will be that the total end-to-end latency becomes slightly longer. There was a problem hiding this comment. I agree with @rugeGerritsen here As the current BT Core spec works w.r.t. ISO over HCI, we can't really make any (good) assumptions, and the best we really can do is just to always enqueue at least 2 SDUs and TX as fast as possible. There are no guarantees we can make without knowing the specific controller. I've recently refactored TX for a similar sample: #73406 Effectively moving a timer-based approach to just sending as fast and much as possible, based on the available buffers. Keep in mind that the buffer handling will also change as part of #72090 There was a problem hiding this comment. Agreed, see my comment re next steps. |
||
| * independently of its implementation. The following macros hide implementation | ||
| * details from the application. | ||
| */ | ||
|
|
||
| #include <stdint.h> | ||
|
|
||
| #include <hal/nrf_rtc.h> | ||
|
|
||
| #define BT_CLOCK_HAL_CNTR_MASK 0x00FFFFFF | ||
| #define BT_CLOCK_HAL_CNTR_UNIT_FSEC 30517578125UL | ||
|
|
||
| #define BT_CLOCK_HAL_FSEC_PER_USEC 1000000000UL | ||
|
|
||
| #define BT_CLOCK_HAL_TICKS_TO_US(x) \ | ||
| (((uint32_t)(((uint64_t)(x) * BT_CLOCK_HAL_CNTR_UNIT_FSEC) / BT_CLOCK_HAL_FSEC_PER_USEC))) | ||
|
|
||
| #define BT_CLOCK_HAL_WRAPPING_POINT_US (BT_CLOCK_HAL_TICKS_TO_US(BT_CLOCK_HAL_CNTR_MASK)) | ||
| #define BT_CLOCK_HAL_CYCLE_US (BT_CLOCK_HAL_WRAPPING_POINT_US + 1) | ||
|
|
||
| #define hal_ticker_now_ticks() nrf_rtc_counter_get(NRF_RTC0) | ||
| #define hal_ticker_now_usec() BT_CLOCK_HAL_TICKS_TO_US(hal_ticker_now_ticks()) | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I understand this.
CONFIG_BT_ISO_TX_MTU effectively reflects the maximum size of the SDUs. The SDUs can be any value below this, and thus increasing this size does not necessarily affect the number of PDUs per SDU.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The sample now counts up to 494 bytes, so two PDUs will effectively be required to transfer that SDU (as the MAX PDU size payload is limited in the sample to exactly half of this value). This is required to prove that timing will work even if SDU interval != ISO interval.