mirror of
https://github.com/zephyrproject-rtos/zephyr
synced 2025-09-04 13:51:57 +00:00
1f6841c9c1
We know the needed values at build-time, so there's no point in having a runtime mechanism of accessing them in the code. Having the values as defines makes it e.g. possible to use them as input for defining the size of buffer pools. Change-Id: Ib7556644719bfb631e638fa5bf29f3d1747a5072 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