The Bluetooth subsystem is initialized using the :cbt_enable() function. The caller should ensure that function succeeds by checking the return code for errors. If a function pointer is passed to :cbt_enable(), the initialization happens asynchronously, and the completion is notified through the given function.
A simple Bluetooth beacon application is shown below. The application initializes the Bluetooth Subsystem and enables non-connectable advertising, effectively acting as a Bluetooth Low Energy broadcaster.
../../../samples/bluetooth/beacon/src/main.c
The key APIs employed by the beacon sample are :cbt_enable() that's used to initialize Bluetooth and then :cbt_le_adv_start() that's used to start advertising a specific combination of advertising and scan response data.
It's possible to test Bluetooth applications using QEMU. In order to do so, a Bluetooth controller needs to be exported from the host OS (Linux) to the emulator.
The host OS's Bluetooth controller is connected to the second QEMU serial line using a UNIX socket. This socket employs the QEMU option -serial unix:/tmp/bt-server-bredr. This option is already added to QEMU through QEMU_EXTRA_FLAGS in most Bluetooth sample Makefiles' and made available through the 'run' make target.
On the host side, BlueZ allows to export its Bluetooth controller through a so-called user channel for QEMU to use:
- Make sure that the Bluetooth controller is down
Use the btproxy tool to open the listening UNIX socket, type:
$ sudo tools/btproxy -u Listening on /tmp/bt-server-bredr
- Choose one of the Bluetooth sample applications located in
samples/bluetooth. To run Bluetooth application in QEMU, type:
$ make run
Running QEMU now results in a connection with the second serial line to the bt-server-bredr UNIX socket, letting the application access the Bluetooth controller.