mirror of
https://github.com/zephyrproject-rtos/zephyr
synced 2025-09-03 08:41:55 +00:00
824c2ebc58
Allocates segmented message buffers as slabs in a common pool for RX and TX. This reduces memory requirements for both TX and RX, as TX messages can be stored without the network and advertising buffer overhead, and RX can use only the slabs it needs, instead of allocating a full size segmented message. This approach also removes the need for decrypting the segments for each retransmission, reducing overall processing load. Slab based segmentation for tx also introduces queuing of segmented messages, which allows the application layer to send multiple messages to the same destination without violating Bluetooth Mesh specification v1.0.1, section 3.6.4.1. This mechanism is provided through a flag that blocks segmented messages to a destination which a message is already being sent to until the previous message finishes. This changes the SDU size configuration to a symmetrical RX_SEG_MAX/TX_SEG_MAX pair of configurations, plus a new segment pool side configuration. It also removes the binding between the TX_SEG_MAX config and the advertising buffers, reducing the minimum advertising buffer count from 6 to 3. Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@nordicsemi.no> |
||
|---|---|---|
| .. | ||
| src | ||
| CMakeLists.txt | ||
| prj_bbc_microbit.conf | ||
| prj_nrf51_blenano.conf | ||
| prj.conf | ||
| README.rst | ||
| rv32m1_vega_ri5cy.overlay | ||
| sample.yaml | ||
.. _ble_mesh_demo: Bluetooth: Mesh Demo #################### Overview ******** This sample is a Bluetooth Mesh application intended for demonstration purposes only. The application provisions and configures itself (i.e. no external provisioner needed) with hard-coded network and application key values. The local unicast address can be set using a NODE_ADDR build variable (e.g. NODE_ADDR=0x0001 for unicast address 0x0001), or by manually editing the value in the ``board.h`` file. Because of the hard-coded values, the application is not suitable for production use, but is quite convenient for quick demonstrations of Mesh functionality. The application has some features especially designed for the BBC micro:bit boards, such as the ability to send messages using the board's buttons as well as showing information of received messages on the board's 5x5 LED display. It's generally recommended to use unicast addresses in the range of 0x0001-0x0009 for the micro:bit since these map nicely to displayed addresses and the list of destination addresses which can be cycled with a button press. A special address, 0x000f, will make the application become a heart-beat publisher and enable the other nodes to show information of the received heartbeat messages. 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_demo` 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_demo :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.