UWB与BLE协同模组开发及联调 - 第2节

BLE协议栈架构：从Controller到Application

BLE协议栈，说白了就是一套分层软件。我刚开始接触时也觉得层数太多，但后来发现，这种分层设计恰恰是BLE灵活性的根源。

整个协议栈分三层：Controller、Host、Application。每一层各司其职，层与层之间通过标准接口通信。嗯，这里要注意，不同芯片厂商的实现可能不一样，但逻辑分层是统一的。

Controller层：硬件的管家

Controller层负责最底层的射频操作。它直接跟硬件打交道，处理收包、发包、时序这些脏活累活。

• 物理层（PHY）：调制解调、频率选择。BLE在2.4GHz频段工作，有40个信道。
• 链路层（LL）：状态机管理。控制设备在五种状态间切换：Standby、Advertising、Scanning、Initiating、Connected。
• 直接测试模式：用于产测和认证，我一般用这个来快速验证射频性能。

Host层：协议的大脑

Host层跑在CPU上，处理更高层的逻辑。它跟Controller之间通过HCI（Host Controller Interface）通信。HCI可以是UART、USB或者SDIO，我项目里用得最多的是UART。

Host层包含这些关键组件：

• L2CAP：数据打包与分段重组。把上层大包切成小片，方便LL层传输。
• SM（安全管理层）：配对、绑定、加密。我踩过坑——配对失败往往不是SM的问题，而是LL层连接参数没协商好。
• ATT：属性协议。定义了客户端-服务器模型，用来读写小数据。
• GATT：基于ATT，定义了Profile和Service的结构。说白了，就是告诉别人「我这个设备能干什么」。
• GAP：通用访问规范。管广播、扫描、连接这些事。

Application层：你的业务代码

这一层就是开发者写代码的地方。你定义Service、Characteristic，实现具体的业务逻辑。比如一个温度计，Application层就负责读传感器、更新温度值、通知手机。

BLE角色：四种身份，各司其职

BLE定义了四种角色。我经常被问到：「我的设备该用哪种角色？」答案取决于你的应用场景。

你想想看，一个UWB定位标签，它应该是什么角色？如果它只需要上报位置，那Broadcaster就够了。但如果它需要接收配置参数，那就得是Peripheral，等手机来连。

BLE通信流程：从广播到数据传输

BLE的通信流程，我习惯把它拆成四个阶段。每个阶段都有它的技术细节和坑点。

第一阶段：广播

Peripheral（或Broadcaster）在三个广播信道（37/38/39）上发广播包。广播包分两种：

• 可连接广播：告诉别人「我可以被连」
• 不可连接广播：只发数据，不接受连接

广播间隔是个关键参数。间隔越短，被发现越快，但功耗越高。我一般设100ms到1s之间，看应用场景。

第二阶段：扫描

Central（或Observer）在广播信道上监听。扫描分两种模式：

• 被动扫描：只听，不发
• 主动扫描：听到广播后，发扫描请求，获取更多数据

嗯，这里要注意：主动扫描会多耗电，但能拿到设备名、服务UUID这些信息。

第三阶段：连接

Central发连接请求，Peripheral接受。连接建立后，双方在数据信道上通信。连接参数包括：

• 连接间隔：7.5ms到4s，决定了通信频率
• 延迟：允许Peripheral跳过几个连接事件来省电
• 超时时间：多久没收到包就断开

第四阶段：数据传输

连接建立后，通过GATT的Service和Characteristic来读写数据。常用操作：

• Read：Central读Peripheral的属性值
• Write：Central写数据到Peripheral
• Notify：Peripheral主动推数据给Central（不需要Central确认）
• Indicate：Peripheral主动推数据，Central必须确认

我项目中90%的场景用Notify就够了。Indicate虽然可靠，但吞吐量低一半，因为每次都要等确认。

BLE协议栈架构图

下面这张图是我自己画的，把协议栈分层和角色关系串在一起。你看完应该能对整个体系有个直观印象。

小结

BLE协议栈的分层设计，让开发者可以专注在Application层写业务，不用操心射频细节。四种角色覆盖了从单向广播到双向连接的所有场景。通信流程的四个阶段，每一步都有参数可以调优。

我个人觉得，理解这些基础概念，比背API更重要。API会变，但协议栈的架构和角色逻辑不会变。你把这些吃透了，后面做UWB+BLE协同开发时，就知道哪些事该BLE干，哪些事该UWB干。