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 | ||
| microbit_gatt.conf | ||
| nrf51_qfaa.conf | ||
| prj_bbc_microbit.conf | ||
| prj.conf | ||
| README.rst | ||
| sample.yaml | ||
.. _ble_mesh: Bluetooth: Mesh ############### Overview ******** This sample demonstrates Bluetooth Mesh functionality. It has several standard Mesh models, and supports provisioning over both the Advertising and the GATT Provisioning Bearers (i.e. PB-ADV and PB-GATT). The application also needs a functioning serial console, since that's used for the Out-of-Band provisioning procedure. On boards with LEDs, a Generic OnOff Server model exposes functionality for controlling the first LED on the board over the mesh. On boards with buttons, a Generic OnOff Client model will send Onoff messages to all nodes in the network when the button is pressed. Requirements ************ * A board with Bluetooth LE support, or * QEMU with BlueZ running on the host Building and Running ******************** This sample can be found under :zephyr_file:`samples/bluetooth/mesh` in the Zephyr tree. See :ref:`bluetooth samples section <bluetooth-samples>` for details on how to run the sample inside QEMU. For other boards, build and flash the application as follows: .. zephyr-app-commands:: :zephyr-app: samples/bluetooth/mesh :board: <board> :goals: flash :compact: Refer to your :ref:`board's documentation <boards>` for alternative flash instructions if your board doesn't support the ``flash`` target. Interacting with the sample *************************** The sample can either be provisioned into an existing mesh network with an external provisioner device, or self-provision through a button press. When provisioning with a provisioner device, the provisioner must give the device an Application key and bind it to both Generic OnOff models. When self-provisioning, the device will take a random unicast address and bind a dummy Application key to these models. Once provisioned, messages to the Generic OnOff Server will be used to turn the LED on or off, and button presses will be used to broadcast OnOff messages to all nodes in the same network.