6483e12a8a
Refactor and simplify the bluetooth buffer configurations to improve the easy of configurations and eliminate invalid ones. By moving configurations out of host and controller specific configurations and into a common one it becomes easier to configure the host and controller separately as the same configurations can be used as would be for a combined build. All HCI configurations are now given exluding the matching HCI header, which eases the configuration as the application don't have to know the different header sizes. The BT_RX_BUF_LEN is split into ACL and Event, as well as the suprising use of Command size. BT_L2CAP_RX_MTU is removed as the stack does not support reassembling of HCI ACL data to larger L2CAP PDUs. The application will have to set ACL RX size and account for the L2CAP PDU header itself. BT_EATT_RX_MTU was removed as it is only used for setting a different default value for another option which leads to the stuck kconfig symbol problem. The configurations can be updated according to the table below: ** New configuration | ** Old configuration All configurations BT_BUF_ACL_RX_SIZE | BT_L2CAP_RX_MTU + 4 BT_BUF_ACL_RX_SIZE | BT_RX_BUF_LEN - 4 BT_BUF_EVT_RX_SIZE | BT_RX_BUF_LEN - 2 BT_BUF_CMD_TX_SIZE | BT_RX_BUF_LEN - 3 BT_BUF_CMD_TX_COUNT | BT_HCI_CMD_COUNT BT_BUF_EVT_RX_COUNT | BT_RX_BUF_COUNT BT_BUF_ACL_RX_COUNT | BT_RX_BUF_COUNT BT_BUF_ACL_RX_COUNT | BT_ACL_RX_COUNT BT_BUF_EVT_DISCARDABLE_SIZE | BT_DISCARDABLE_BUF_SIZE - 2 BT_BUF_EVT_DISCARDABLE_COUNT | BT_DISCARDABLE_BUF_COUNT Controller-build BT_BUF_ACL_TX_SIZE | BT_CTLR_TX_BUFFERS_SIZE BT_BUF_ACL_TX_COUNT | BT_CTLR_TX_BUFFER HCI-bridge BT_BUF_ACL_TX_SIZE | BT_HCI_ACL_DATA_SIZE BT_BUF_ACL_TX_COUNT | 6 Fixed invalid configurations setting either BT_L2CAP_RX_MTU or BT_CTLR_DATA_LENGTH_MAX larger than BT_RX_BUF_LEN could lead to buffer overruns. Fix advertising report max data length calculation. This always used the BT_DISCARDABLE_BUF_SIZE macro but this feature can be turned off and advertising reports will be allocated from the RX buffer in that case. Also controller-build does not have this buffer (in hci_raw.c). Also the wrong HCI header was used in the calculation, HCI event header should have been used instead of HCI ACL header. Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no> |
||
|---|---|---|
| .. | ||
| boards | ||
| src | ||
| CMakeLists.txt | ||
| prj.conf | ||
| README.rst | ||
| sample.yaml | ||
.. _bluetooth-hci-spi-sample: Bluetooth: HCI SPI ################## Overview ******** Expose Zephyr Bluetooth Controller support over SPI to another device/CPU using the Zephyr SPI HCI transport protocol (similar to BlueNRG). Requirements ************ A board with SPI slave, GPIO and Bluetooth Low Energy support. Building and Running ******************** You then need to ensure that your :ref:`devicetree <dt-guide>` defines a node for the HCI SPI slave device with compatible :dtcompatible:`zephyr,bt-hci-spi-slave`. This node sets an interrupt line to the host and associates the application with a SPI bus to use. See :zephyr_file:`boards/nrf51dk_nrf51422.overlay <samples/bluetooth/hci_spi/boards/nrf51dk_nrf51422.overlay>` in this sample directory for an example overlay for the :ref:`nrf51dk_nrf51422` board. You can then build this application and flash it onto your board in the usual way; see :ref:`boards` for board-specific building and flashing information. You will also need a separate chip acting as BT HCI SPI master. This application is compatible with the HCI SPI master driver provided by Zephyr's Bluetooth HCI driver core; see the help associated with the :option:`CONFIG_BT_SPI` configuration option for more information. Refer to :ref:`bluetooth-samples` for general Bluetooth information, and to :ref:`96b_carbon_nrf51_bluetooth` for instructions specific to the 96Boards Carbon board.