mirror of
https://github.com/zephyrproject-rtos/zephyr
synced 2025-08-09 16:40:08 +00:00
An extended inquiry response or advertising data packet shall not contain more than one instance for each Service UUID data size. Change-Id: I41d1a25fdcb2987e8d0cadfb2110fd62b3685f17 Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
||
---|---|---|
.. | ||
beacon | ||
central | ||
init | ||
peripheral | ||
shell | ||
test_bluetooth | ||
bt_regression.sh | ||
README |
Bluetooth subsystem = Architecture = All processing is done in fibers. Basic structure for packet processing is bt_buf. Packets are queued to different queues and processed. Packet allocation is done through a free packets queue which gets populated during the initialization. = Building = Build host tools: $ make -C host/src Build samples $ make -C samples/bluetooth/<app> = Testing = Host Bluetooth controler is connected to the second qemu serial line through a UNIX socket (qemu option -serial unix:/tmp/bt-server-bredr). 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 Now qemu can connect serial line to the 'bt-server-bredr' UNIX socket with following command: For microkernel configuration run: $ make microkernel.qemu For nanokernel configuration run: $ make nanokernel.qemu Extra parameter to qemu might be added through QEMU_EXTRA_FLAGS. There is smoke test application in nanokernel and microkernel test directories which gets run in sanity check script: $ scripts/sanity_chk/sanity_chk -T gcc [-B <BSP>] For quick regression test use bt_regression, it only check Bluetooth test $ samples/bluetooth/bt_regression.sh