zephyr/samples/bluetooth/mesh_provisioner
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
src
CMakeLists.txt
README.rst bluetooth: Rename rpmsg HCI driver and sample to ipc 2023-11-02 08:32:20 +02:00
prj.conf
sample.yaml

README.rst

.. _ble_mesh_provisioner:

Bluetooth: Mesh Provisioner
###########################

Overview
********

This sample demonstrates how to use the Bluetooth mesh APIs related to
provisioning and using the Configuration Database (CDB). It is intended
to be tested together with a device capable of being provisioned. For
example, one could use the sample in
:zephyr_file:`samples/bluetooth/mesh`
or :zephyr_file:`tests/bluetooth/mesh_shell`.

The application provisions itself and loads the CDB with an application
key, then waits to receive an Unprovisioned Beacon from a device. If the
board has a push button connected via GPIO and configured using the
``sw0`` :ref:`devicetree <dt-guide>` alias, the application then waits
for the user to press the button, which will trigger provisioning using
PB-ADV. If the board doesn't have the push button, the sample will
provision detected devices automatically. Once provisioning is done, the
node will be present in the CDB but not yet marked as configured. The
application will notice the unconfigured node and start configuring it.
If no errors are encountered, the node is marked as configured.

The configuration of a node involves adding an application key, getting
the composition data, and binding all its models to the application key.

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_provisioner` 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_provisioner
   :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.