BTstack与MSP430开发入门指南

1星需积分: 20 54 浏览量更新于2024-07-23 收藏 682KB PDF 举报

"蓝牙协议栈使用说明" 本文档是一份关于使用BTstack在MSP430微控制器上实现蓝牙功能的入门指南，由Dr.sc.Milanka Ringwald和Dr.sc.Matthias Ringwald撰写。BTstack是一个开源的蓝牙协议栈，适用于多种平台，包括MSP430系列芯片。以下是对文档内容的详细解释： 1. **开始使用BTstack和MSP-EXP430F5438+CC256x** - **硬件设置**：这部分指导用户如何配置硬件，包括连接MSP430微控制器和CC256x蓝牙模块。 - **通用工具**：介绍所需的软件工具，如编译器、调试器等。 - **从SVN获取BTstack**：说明如何从版本控制系统获取最新的BTstack源代码。 - **CC256x初始化脚本**：提供用于设置CC256x蓝牙芯片的脚本。 - **编译示例**：详细步骤来编译和构建BTstack的示例应用程序。 - **加载固件**：指导用户如何将编译好的固件烧录到MSP430中。 - **运行示例**：描述如何启动和测试编译后的蓝牙应用。 2. **BTstack架构** - **单线程设计**：BTstack采用单线程模型，简化了并发处理，降低编程复杂性。 - **无任何阻塞**：设计上避免了可能导致程序挂起的阻塞操作，确保实时性。 - **无人为限制的缓冲区/池**：内存管理灵活，不受预设缓冲区大小限制。 - **静态内存约束**：BTstack的内存使用量预先定义，确保系统稳定性。 3. **如何使用BTstack** - **协议和服务**：讲解如何利用BTstack实现各种蓝牙协议（如L2CAP、RFCOMM）和服务。 - **内存配置**：指导用户根据实际需求调整BTstack的内存分配。 - **运行循环**：BTstack依赖于一个运行循环来处理事件和任务。 - **BTstack初始化**：详细步骤来启动和配置BTstack。 - **数据包处理函数来源**：说明在哪里查找和定义处理蓝牙数据包的函数。 - **RFCOMM流控制**：解释如何在蓝牙串行端口配置中实现流控制。 4. **快速食谱** - **周期性时间处理器**：展示如何设置定期执行的任务。 - **自定义HCI命令模板**：说明如何定义和使用自定义的HCI（主机控制器接口）命令。 - **基于模板发送HCI命令**：教程如何根据预定义模板发送命令到蓝牙控制器。 - **单输出缓冲区应对策略**：在只有一个缓冲区的情况下处理蓝牙通信的策略。 - **成为可发现设备**：设备如何开启被其他蓝牙设备扫描和发现。 - **发现远程设备**：描述如何搜索和识别周围的蓝牙设备。 - **设备配对**：说明如何执行蓝牙设备间的配对过程。 - **访问远程设备的L2CAP服务**：教程如何通过L2CAP层与远程设备进行通信。 - 更多实践步骤，如连接到特定服务，读写数据等，继续在文档中详细阐述。这份文档是蓝牙开发者入门的宝贵资源，涵盖了从硬件配置到软件实现的全部流程，有助于理解并掌握蓝牙协议栈的使用。

3.1. Protocols and services. Figure 2 depicts protocols that BTstack imple-

ments: HCI, L2CAP, L2CAP-LE, RFCOMM, SDP, and ATT. The Host Con-

troller Interface (HCI) provides a command interface to the Bluetooth chipset.

The Logical Link Control and Adaptation Protocol (L2CAP) supports higher

level protocol multiplexing and reassembly. The L2CAP Low Energy (LE) vari-

ant is optimized for connectionless data used by Bluetooth Low Energy devices.

It is the base for the Attribute Protocol (ATT) of Bluetooth LE, which provides

access to Services and Characteristics. The Radio frequency communication

(RFCOMM) protocol provides emulation of serial ports over the L2CAP proto-

col. The Service Discovery Protocol (SDP) allows to discover services provided

by a Bluetooth device. BTstack’s API for HCI, L2CAP, RFCOMM and SDP is

provided in Appendix A.

One important construct of BTstack is service. A service represents a server

side component that handles incoming connections. So far, BTstack provides

L2CAP and RFCOMM services. An L2CAP service handles incoming connec-

tions for an L2CAP channel and is registered with its protocol service multiplexer

ID (PSM). Similarly, an RFCOMM service handles incoming RFCOMM connec-

tions and is registered with the RFCOMM channel ID. Outgoing connections

require no special registration, they are created by the application when needed.

#define HCI ACL PAYLOAD SIZE 52

#define MAX SPP CONNECTIONS 1

#define MAX NO HCI CONNECTIONS MAX SPP CONNECTIONS

#define MAX NO L2CAP SERVICES 2

#define MAX NO L2CAP CHANNELS (1+MAX SPP CONNECTIONS)

#define MAX NO RFCOMM MULTIPLEXERS MAX SPP CONNECTIONS

#define MAX NO RFCOMM SERVICES 1

#define MAX NO RFCOMM CHANNELS MAX SPP CONNECTIONS

#define MAX NO DB MEM DEVICE NAMES 0

#define MAX NO DB MEM LINK KEYS 3

#define MAX NO DB MEM SERVICES 1

Listing 1. Memory conﬁguration for an SPP service with a

minimal L2CAP MTU.

3.2. Memory conﬁguration. The structs for services, active connections and

remote devices can be allocated in two diﬀerent manners:

• statically from an individual memory pool, whose maximal number of

elements is deﬁned in the conﬁg ﬁle. To initialize the static pools, you

need to call btstack memory init function. An example of memory con-

ﬁguration for a single SPP service with a minimal L2CAP MTU is shown

in Listing 1.

• dynamically using the malloc/free functions, if HAVE MALLOC is de-

ﬁned in conﬁg ﬁle.

If both HAVE MALLOC and maximal size of a pool are deﬁned in the conﬁg

ﬁle, the statical allocation will take precedence. In case that both are omitted,

an error will be raised.

The memory is set up by calling btstack memory init function:

bt st a ck me mo r y i ni t ( ) ;

3.3. Run loop. BTstack uses a run loop to handle incoming data and to sched-

ule work. The run loop handles events from two diﬀerent types of sources: data

sources and timers. Data sources represent communication interfaces like an

UART or an USB driver. Timers are used by BTstack to implement various

Bluetooth-related timeouts. They can also be used to handle periodic events.

Data sources and timers are represented by the structs data source t and

timer source t respectively. Each of these structs contain a link list node and a

pointer to a callback function. All active timers and data sources are kept in

link lists. While the list of data sources is unsorted, the timers are sorted by

expiration timeout for eﬃcient processing.

The complete run loop cycle looks like this: ﬁrst, the callback function of

all registered data sources are called in a round robin way. Then, the callback

functions of timers that are ready are executed. Finally, it will be checked if

another run loop iteration has been requested by an interrupt handler. If not,

the run loop will put the MCU into sleep mode.

Incoming data over the UART, USB, or timer ticks will generate an inter-

rupt and wake up the microcontroller. In order to avoid the situation where

a data source becomes ready just before the run loop enters sleep mode, an

interrupt-driven data source has to call the embedded trigger function. The call

to embedded trigger sets an internal ﬂag that is checked in the critical section

just before entering sleep mode.

Timers are single shot: a timer will be removed from the timer list before

its event handler callback is executed. If you need a periodic timer, you can

re-register the same timer source in the callback function, see Section 4.1 for an

example. Note that BTstack expects to get called periodically to keep its time,

see Section 6.1 for more on the tick hardware abstraction.

The Run loop API is provided in Appendix C. To enable the use of timers,

make sure that you deﬁned HAVE TICK in the conﬁg ﬁle.

In your code, you’ll have to conﬁgure the run loop before you start it as shown

in Listing 23. The application can register data sources as well as timers, e.g.,

periodical sampling of sensors, or communication over the UART.

The run loop is set up by calling run loop init function for embedded systems:

r u n l o o p i n i t (RUN LOOP EMBEDDED) ;

3.4. BTstack initialization. To initialize BTstack you need to initialize the

memory and the run loop as explained in Sections 3.2 and 3.3 respectively, then

setup HCI and all needed higher level protocols.

The HCI initialization has to adapt BTstack to the used platform and requires

four arguments. These are:

• Bluetooth hardware control: The Bluetooth hardware control API can

provide the HCI layer with a custom initialization script, a vendor-speciﬁc

baud rate change command, and system power notiﬁcations. It is also

used to control the power mode of the Bluetooth module, i.e., turning

it on/oﬀ and putting to sleep. In addition, it provides an error handler

error that is called when a Hardware Error is reported by the Blue-

tooth module. The callback allows for persistent logging or signaling of

this failure.

Overall, the struct bt control t encapsulates common functionality that

is not covered by the Bluetooth speciﬁcation. As an example, the bt con-

trol cc256x in-stance function returns a pointer to a control struct suit-

able for the CC256x chipset.

b t c o n t r o l t ∗ c o n t r o l = b t c o n t r o l c c 2 5 6 x i n s t a n c e ( ) ;

• HCI Transport implementation: On embedded systems, a Bluetooth mod-

ule can be connected via USB or an UART port. BTstack implements two

UART based protocols: HCI UART Transport Layer (H4) and H4 with

eHCILL support, a lightweight low-power variant by Texas Instruments.

These are accessed by linking the appropriate ﬁle (src/hci_transport_

h4_dma.c resp. src/hci_transport_h4_ehcill_dma.c) and then get-

ting a pointer to HCI Transport implementation. For more information

on adapting HCI Transport to diﬀerent environments, see Section 6.3.

h c i t r a n s p o r t t ∗ t r a n s p o r t = h c i t r a n s p o r t h 4 d m a i n s t a n c e ( ) ;

• HCI Transport conﬁguration: As the conﬁguration of the UART used in

the H4 transport interface are not standardized, it has to be provided by

the main application to BTstack. In addition to the initial UART baud

rate, the main baud rate can be speciﬁed. The HCI layer of BTstack will

change the init baud rate to the main one after the basic setup of the

Bluetooth module. A baud rate change has to be done in a coordinated

way at both HCI and hardware level. First, the HCI command to change

the baud rate is sent, then it is necessary to wait for the conﬁrmation

event from the Bluetooth module. Only now, can the UART baud rate

changed. As an example, the CC256x has to be initialized at 115200 and

can then be used at higher speeds.

h c i u a r t c o n f i g t ∗ c o n f i g = h c i u a r t c o n f i g c c 2 5 6 x i n s t a n c e ( ) ;

• Persistent storage - speciﬁes where to persist data like link keys or remote

device names. This commonly requires platform speciﬁc code to access

the MCU’s EEPROM of Flash storage. For the ﬁrst steps, BTstack

provides a (non) persistent store in memory. For more see Section 6.4.

r e m o t e d e v ic e d b t ∗ remote db = &remote device db memory ;

剩余50页未读，继续阅读

jsa158

粉丝: 24
资源: 12

BTstack与MSP430开发入门指南

nordic的蓝牙协议栈

蓝牙协议栈文档

杰理的蓝牙协议栈开发资源

ios 蓝牙协议通信文档

蓝牙通信的详细设计说明书

Linux蓝牙应用程序开发

ESP32 BLUEDROID 层次关系中 ESP_API 和 BTA_API的说明

STC8a8k64d4怎么用蓝牙模块连接手机

手机为什么可以连接多个蓝牙耳机设备，为什么，请详细按点说明

stm32 hc05蓝牙驱动程序

最新资源