zephyr

History

Carles Cufi 9cf07bbdb5 bluetooth: Rename rpmsg HCI driver and sample to ipc The existing driver and sample: - drivers/bluetooth/hci/rpmsg - samples/bluetooth/hci_rpmsg are no longer correctly named, since they now use the IPC subsystem to send and receive data. The IPC subsystem can use RPMsg as a transport, but that is one of several selectable backends. I initially wanted to deprecated both the BT_RPMSG Kconfig option as well as the zephyr,bt-hci-rpmsg-ipc chosen node in Devicetree. However, this proved to be undoable in the case of the Kconfig option. This is because it's a choice option, and those have special behavior. In particular, the only practical way to deprecate would've been to keep the old Kconfig option outside the choice (much like it's done in this commit) but then also add a 'depends on !BT_RPMSG' on each of the remaining choice symbols except on the new BT_HCI_IPC one. This, however, only works correctly for .conf files. If a board instead sets the default BT_HCI_BUS_TYPE in the Kconfig.defconfig file then the Kconfig tree parsing would fail, because it'd try to set it to a value (BT_RPMSG) that is no longer part of the choice. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>		2023-11-02 08:32:20 +02:00
..
boards	drivers: pwm_nrf5_sw: Rename to pwm_nrf_sw	2023-08-16 16:33:03 +02:00
src	drivers: gpio: use gpio_is_ready_dt helper function	2023-08-28 08:48:35 -05:00
CMakeLists.txt	Bluetooth: Mesh: add tf-m support for ble mesh	2023-06-19 15:04:17 +02:00
prj.conf	Bluetooth: Mesh: add tf-m support for ble mesh	2023-06-19 15:04:17 +02:00
README.rst	bluetooth: Rename rpmsg HCI driver and sample to ipc	2023-11-02 08:32:20 +02:00
sample.yaml	Bluetooth: Mesh: add tf-m support for ble mesh	2023-06-19 15:04:17 +02:00

README.rst

.. _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.

To run the application on an :ref:`nrf5340dk_nrf5340`, a Bluetooth controller application
must also run on the network core. The :ref:`bluetooth-hci-ipc-sample` sample
application may be used. Build this sample with configuration
:zephyr_file:`samples/bluetooth/hci_ipc/nrf5340_cpunet_bt_mesh-bt_ll_sw_split.conf`
to enable mesh support.