mirror of
https://github.com/zephyrproject-rtos/zephyr
synced 2025-09-04 00:31:56 +00:00
Now that we have the buffer type enum as part of the HCI driver API we can take advantage of it to pass the buffer type information and not have to have two separate callbacks. Change-Id: Ib2ee5b1540e532c9b27903e97660a276c1293fbc Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> |
||
---|---|---|
.. | ||
beacon | ||
central | ||
init | ||
peripheral | ||
shell | ||
test_bluetooth | ||
tester | ||
README |
Bluetooth subsystem = Building = Build samples $ make -C samples/bluetooth/<app> = Bluetooth Sample application = Host Bluetooth controller is connected to the second qemu serial line through a UNIX socket (qemu option -serial unix:/tmp/bt-server-bredr). This option is already added to qemu through QEMU_EXTRA_FLAGS in Makefile. On the host side BlueZ allows to "connect" Bluetooth controller through a so-called user channel. Use the btproxy tool for that: $ sudo tools/btproxy -u Listening on /tmp/bt-server-bredr Note that before calling btproxy make sure that Bluetooth controller is down. Now running qemu result connecting second serial line to 'bt-server-bredr' UNIX socket. When Bluetooth (CONFIG_BLUETOOTH) and Bluetooth HCI UART driver (CONFIG_BLUETOOTH_UART) are enabled, Bluetooth driver registers to the system. From now on Bluetooth might be used by the application. To run application in the qemu run: $ make qemu = Bluetooth sanity check = There is smoke test application in nanokernel and microkernel test directories which gets run in sanity check script: $ scripts/sanity_chk/sanity_chk [-P <platform>] For quick regression test use bt_regression, it only check Bluetooth test $ samples/bluetooth/bt_regression.sh