The CTE type is used in two ways by HCI layer: 1) single value representing particular CTE type: AoA, AoD 1 us, AoD 2 us 2) bit-filed where bits 0-2 represent particular CTE types AoA AoD 1 us, AoD 2 us The bit-field is used to inform Controller about allowed types of CTE, hence single value carries more than one value. To avoid confusion between these use cases in code that refers to case 1) all named cte_type (singular form). For case 2) cte_types (plural form) is used. There is an enumeration that is used for both cases: bt_df_cte_type. For cte_type only single value from the enumeration may be assigned to variable except BT_DF_CTE_TYPE_NONE and BT_DF_CTE_TYPE_ALL. For cte_types all enum members may be used. Ocasionally BT_DF_CTE_TYPE_NONE may be excluded. If that is true, it is described in code documentation. Thanks to that applications are released from requirement to include hci.h header file. Signed-off-by: Piotr Pryga <piotr.pryga@nordicsemi.no> |
||
|---|---|---|
| .. | ||
| beacon | ||
| broadcaster | ||
| central | ||
| central_hr | ||
| central_ht | ||
| central_iso | ||
| central_multilink | ||
| central_past | ||
| direction_finding_connectionless_rx | ||
| direction_finding_connectionless_tx | ||
| eddystone | ||
| handsfree | ||
| hci_pwr_ctrl | ||
| hci_rpmsg | ||
| hci_spi | ||
| hci_uart | ||
| hci_usb | ||
| hci_usb_h4 | ||
| ibeacon | ||
| ipsp | ||
| iso_broadcast | ||
| iso_broadcast_benchmark | ||
| iso_connected_benchmark | ||
| iso_receive | ||
| mesh | ||
| mesh_demo | ||
| mesh_provisioner | ||
| observer | ||
| periodic_adv | ||
| periodic_sync | ||
| peripheral | ||
| peripheral_csc | ||
| peripheral_dis | ||
| peripheral_esp | ||
| peripheral_hids | ||
| peripheral_hr | ||
| peripheral_ht | ||
| peripheral_identity | ||
| peripheral_iso | ||
| peripheral_ots | ||
| peripheral_past | ||
| peripheral_sc_only | ||
| scan_adv | ||
| st_ble_sensor | ||
| bluetooth.rst | ||