zephyr学习蓝牙部分（六） - Developing Bluetooth Applications

Bluetooth applications are developed using the common infrastructure and approach that is described in the Application Developmentsection of the documentation.

Additional information that is only relevant to Bluetooth applications can be found in this page.

Hardware setup

This section describes the options you have when building and debugging Bluetooth applications with Zephyr. Depending on the hardware that is available to you, the requirements you have and the type of development you prefer you may pick one or another setup to match your needs.

本节介绍使用Zephyr构建和调试蓝牙应用程序时的选项。根据您可用的硬件、您拥有的需求和您喜欢的开发类型，您可以选择一个或另一个设置来满足您的需要。

There are 4 possible hardware setups to use with Zephyr and Bluetooth:

1. Embedded
2. QEMU with an external Controller
3. Native POSIX with an external Controller
4. Simulated nRF52 with BabbleSim

Embedded

This setup relies on all software running directly on the embedded platform(s) that the application is targeting. All the Configurationsand Build Types are supported but you might need to build Zephyr more than once if you are using a dual-chip configuration or if you have multiple cores in your SoC each running a different build type (e.g., one running the Host, the other the Controller).

此安装程序依赖于直接在应用程序所针对的嵌入式平台上运行的所有软件。支持所有配置和构建类型，但如果您使用双芯片配置，或者如果您的SOC中有多个核心，每个核心运行不同的构建类型（例如，一个运行主机，另一个运行控制器），则可能需要多次构建Zephyr。

To start developing using this setup follow the Getting Started Guide, choose one (or more if you are using a dual-chip solution) boards that support Bluetooth and then run the application).

要开始使用此设置进行开发，请按照入门指南，选择一个（如果您使用的是双芯片解决方案，则选择多个）支持蓝牙的板，然后运行应用程序。

Embedded HCI tracing

When running both Host and Controller in actual Integrated Circuits, you will only see normal log messages on the console by default, without any way of accessing the HCI traffic between the Host and the Controller. However, there is a special Bluetooth logging mode that converts the console to use a binary protocol that interleaves both normal log messages as well as the HCI traffic. Set the following Kconfig options to enable this protocol before building your application:

在实际集成电路中同时运行主机和控制器时，默认情况下，您只能在控制台上看到正常的日志消息，而不能访问主机和控制器之间的HCI流量。但是，有一种特殊的蓝牙日志记录模式，它将控制台转换为使用一种二进制协议，该协议将正常日志消息和HCI流量交织在一起。在构建应用程序之前，请设置以下kconfig选项以启用此协议：

CONFIG_BT_DEBUG_MONITOR=y
CONFIG_UART_CONSOLE=n

Setting CONFIG_BT_DEBUG_MONITOR to y replaces the CONFIG_BT_DEBUG_LOG option, and setting CONFIG_UART_CONSOLE to n disables the default printk/printf hooks.

To decode the binary protocol that will now be sent to the console UART you need to use the btmon tool from BlueZ:

$ btmon --tty  --tty-speed 115200

QEMU with an external Controller

Note

This is currently only available on GNU/Linux

This setup relies on a “dual-chip” configuration which is comprised of the following devices:

1. A Host-only application running in the QEMU emulator
2. A Controller, which can be one of two types:
   • A commercially available Controller
   • A Controller-only build of Zephyr

Refer to Running on QEMU and Native POSIX for full instructions on how to build and run an application in this setup.

Native POSIX with an external Controller

Note

This is currently only available on GNU/Linux

The Native POSIX target builds your Zephyr application with the Zephyr kernel, and some minimal HW emulation as a native Linux executable. This executable is a normal Linux program, which can be debugged and instrumented like any other.

Just like with QEMU, you also need to use a combination of two devices:

1. A Host-only application running in native_posix as a Linux application
2. A Controller, which can be one of two types:
   • A commercially available Controller
   • A Controller-only build of Zephyr

Refer to Running on QEMU and Native POSIX for full instructions on how to build and run an application in this setup.

Simulated nRF52 with BabbleSim

Note

This is currently only available on GNU/Linux

The nrf52_bsim board, is a simulated target board which emulates the necessary peripherals of a nrf52 SOC to be able to develop and test BLE applications. This board, uses:

• BabbleSim to simulate the nrf52 modem and the radio environment.
• The POSIX arch to emulate the processor.
• Models of the nrf52 HW

Just like with the native_posix target, the build result is a normal Linux executable. You can find more information on how to run simulations with one or several devices in this board’s documentation

Currently, only Combined builds are possible, as this board does not yet have any models of a UART, or USB which could be used for an HCI interface towards another real or simulated device.

Initialization

The Bluetooth subsystem is initialized using the bt_enable() function. The caller should ensure that function succeeds by checking the return code for errors. If a function pointer is passed to bt_enable(), the initialization happens asynchronously, and the completion is notified through the given function.

Bluetooth Application Example

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.

/*
 * Set Advertisement data. Based on the Eddystone specification:
 * https://github.com/google/eddystone/blob/master/protocol-specification.md
 * https://github.com/google/eddystone/tree/master/eddystone-url
 */
static const struct bt_data ad[] = {
	BT_DATA_BYTES(BT_DATA_FLAGS, BT_LE_AD_NO_BREDR),
	BT_DATA_BYTES(BT_DATA_UUID16_ALL, 0xaa, 0xfe),
	BT_DATA_BYTES(BT_DATA_SVC_DATA16,
		      0xaa, 0xfe, /* Eddystone UUID */
		      0x10, /* Eddystone-URL frame type */
		      0x00, /* Calibrated Tx power at 0m */
		      0x00, /* URL Scheme Prefix http://www. */
		      'z', 'e', 'p', 'h', 'y', 'r',
		      'p', 'r', 'o', 'j', 'e', 'c', 't',
		      0x08) /* .org */
};

/* Set Scan Response data */
static const struct bt_data sd[] = {
	BT_DATA(BT_DATA_NAME_COMPLETE, DEVICE_NAME, DEVICE_NAME_LEN),
};

static void bt_ready(int err)
{
	if (err) {
		printk("Bluetooth init failed (err %d)\n", err);
		return;
	}

	printk("Bluetooth initialized\n");

	/* Start advertising */
	err = bt_le_adv_start(BT_LE_ADV_NCONN, ad, ARRAY_SIZE(ad),
			      sd, ARRAY_SIZE(sd));
	if (err) {
		printk("Advertising failed to start (err %d)\n", err);
		return;
	}

	printk("Beacon started\n");
}

void main(void)
{
	int err;

	printk("Starting Beacon Demo\n");

	/* Initialize the Bluetooth Subsystem */
	err = bt_enable(bt_ready);
	if (err) {
		printk("Bluetooth init failed (err %d)\n", err);
	}
}

The key APIs employed by the beacon sample are bt_enable() that’s used to initialize Bluetooth and then bt_le_adv_start() that’s used to start advertising a specific combination of advertising and scan response data.