9cf07bbdb5
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> |
||
---|---|---|
.. | ||
boards | ||
src | ||
CMakeLists.txt | ||
Kconfig | ||
nrf5340_hci_ipc.conf | ||
nrf5340_hci_ipc_cpunet.conf | ||
overlay-le-audio.conf | ||
overlay-mesh-v1d1.conf | ||
overlay-mesh.conf | ||
prj.conf | ||
README | ||
testcase.yaml |
Title: Bluetooth tester application Description: Tester application uses binary protocol to control Zephyr stack and is aimed at automated testing. It requires two serial ports to operate. The first serial is used by Bluetooth Testing Protocol (BTP) to drive Bluetooth stack. BTP commands and events are received and buffered for further processing over the same serial. BTP specification can be found in auto-pts project repository: https://github.com/intel/auto-pts The auto-pts is an automation framework for PTS Bluetooth testing tool provided by Bluetooth SIG. See https://docs.zephyrproject.org/latest/guides/bluetooth/index.html for full documentation about how to use this test. -------------------------------------------------------------------------------- Supported Profiles: GAP, GATT, SM -------------------------------------------------------------------------------- Building and running on QEMU: QEMU should have connection with the external host Bluetooth hardware. The btproxy tool from BlueZ can be used to give access to a Bluetooth controller attached to the Linux host OS: $ sudo tools/btproxy -u Listening on /tmp/bt-server-bredr /tmp/bt-server-bredr option is already set in Makefile through QEMU_EXTRA_FLAGS. To build tester application for QEMU use BOARD=qemu_cortex_m3 and CONF_FILE=qemu.conf. After this qemu can be started through the "run" build target. Note: Target board have to support enough UARTs for BTP and controller. We recommend using qemu_cortex_m3. 'bt-stack-tester' UNIX socket (previously set in Makefile) can be used for now to control tester application. -------------------------------------------------------------------------------- Next, build and flash tester application by employing the "flash" build target. Use serial client, e.g. PUTTY to communicate over the serial port (typically /dev/ttyUSBx) with the tester using BTP.