1. 课程导入
低功耗蓝牙（BLE）协议栈，说白了就是一套分层的通信规范。我刚开始接触BLE时，面对一堆HCI、L2CAP、GATT这些缩写，说实话挺懵的。后来在几个项目中摸爬滚打，才慢慢体会到这套分层架构的精妙之处。
今天我们就从整体上看看BLE协议栈长什么样，每一层干什么活，以及为什么这么分层。
1.1 BLE协议栈的整体分层
BLE协议栈分为三大块：Controller（控制器）、Host（主机）和Application（应用）。Controller和Host之间通过HCI（Host Controller Interface）通信。
核心观点：分层设计的本质是解耦。射频硬件、链路控制、逻辑链路、属性协议、应用逻辑，每一层只关心自己的事，不越界。
我个人习惯把BLE协议栈想象成一个快递系统：
- Controller = 快递员（负责收发包裹，处理路况）
- Host = 快递分拣中心（负责拆包、打包、贴标签）
- Application = 收件人/发件人（只关心包裹内容）
这样一比喻，是不是清晰多了？
1.2 Controller层：离硬件最近的地方
Controller层包含物理层（PHY）和链路层（LL）。这是协议栈里最“硬”的部分，直接操作射频寄存器、处理时序、管理状态机。
| 子层 | 职责 | 关键参数 |
|---|---|---|
| PHY（物理层） | 调制解调、射频收发、跳频 | 2.4GHz ISM频段，40个信道，1Mbps/2Mbps |
| LL（链路层） | 连接管理、数据包组装/解析、重传、加密 | 连接间隔（connection interval）、监督超时（supervision timeout） |
我在项目中遇到过一个坑：某次产品在强干扰环境下频繁断连。排查到最后，发现是链路层的连接间隔设置得太短，导致重传窗口不够。后来把连接间隔从7.5ms调到15ms，问题就解决了。嗯，链路层的参数调优，真的不能只看理论值。
避坑指南：我曾经在调试时忽略了PHY层的跳频算法。BLE有37个数据信道，跳频顺序由链路层管理。如果你的设备在某个固定信道上丢包严重，别急着怀疑天线，先看看跳频映射表是不是被固件意外改写了。
1.3 Host层：协议栈的“大脑”
Host层包含多个子层，从下往上依次是：HCI、L2CAP、SM、ATT、GATT、GAP。
你想想看，Controller只负责收发裸数据包，Host层才真正理解这些数据包的含义。
1.3.1 HCI（主机控制器接口）
HCI是Controller和Host之间的桥梁。它定义了一套标准命令和事件，比如“扫描”、“连接”、“断开”。
- 物理接口：UART、USB、SPI
- 逻辑接口：命令包、事件包、数据包
我个人习惯在调试时先抓HCI日志。为什么？因为HCI是分界线——HCI以下的问题多半是硬件或时序问题，HCI以上的问题多半是协议栈配置或应用逻辑问题。
1.3.2 L2CAP（逻辑链路控制与适配协议）
L2CAP负责数据分包与重组，以及通道管理。BLE的L2CAP比经典蓝牙简单得多，只支持面向连接的通道（CoC）和固定通道（如ATT通道）。
提示：L2CAP的MTU（最大传输单元）很关键。默认是23字节，但你可以通过MTU协商提升到512字节甚至更大。我在一个数据采集项目中，把MTU从23提到247，吞吐量直接翻了10倍。
1.3.3 SM（安全管理器）
SM负责配对、绑定和加密。BLE的配对方式有三种：Just Works、Passkey Entry、Out of Band（OOB）。
- Just Works：无用户交互，安全性最低
- Passkey Entry：需要输入6位数字，安全性中等
- OOB：通过NFC等带外方式交换密钥，安全性最高
我曾经在智能锁项目里踩过坑：用了Just Works配对，结果被中间人攻击。后来改成Passkey Entry + 加密存储，才通过安全认证。
1.3.4 ATT（属性协议）与GATT（通用属性协议）
ATT定义了属性（Attribute）的读写规则。GATT在ATT之上定义了服务（Service）和特征（Characteristic）的层次结构。
说白了，ATT是“怎么读写数据”，GATT是“数据长什么样”。
| 概念 | 说明 | 类比 |
|---|---|---|
| Service（服务） | 一组相关功能的集合 | 一个抽屉 |
| Characteristic（特征） | 一个具体的数据点 | 抽屉里的一个文件 |
| Descriptor（描述符） | 特征的元数据 | 文件上的标签 |
1.3.5 GAP（通用访问协议）
GAP定义了设备的角色和广播/扫描/连接行为。BLE设备角色有：
- Broadcaster：只发广播，不连接
- Observer：只收广播，不连接
- Peripheral：从设备，可被连接
- Central：主设备，主动连接
你想想看，一个温度传感器只需要做Broadcaster，而手机App必须是Central。角色选错了，功耗和性能都会出问题。
1.4 分层设计的哲学：为什么这么分？
BLE协议栈的分层不是拍脑袋想出来的。它遵循几个核心原则：
- 关注点分离：射频工程师只管PHY，协议栈工程师只管Host，应用工程师只管GATT。各司其职。
- 可替换性：你可以换掉Controller芯片（比如从Nordic换成TI），只要HCI接口一致，Host层代码几乎不用改。
- 测试便利：每一层都可以独立测试。我在项目中经常用HCI模拟器来测试Host层逻辑，不用等硬件出来。
我的经验：分层设计最大的好处是调试效率。遇到问题，先定位到层，再定位到模块。比如连接断开了，先看HCI事件是“Connection Timeout”还是“Disconnect Complete”，前者是Controller问题，后者可能是Host主动断开。
1.5 BLE协议栈架构总览图
下面这张图展示了BLE协议栈的完整分层结构。我建议你把它存下来，后面每一章都会用到。
1.6 实际项目中的分层思维
说了这么多理论，咱们来点实际的。假设你要开发一个蓝牙温湿度传感器：
- PHY/LL：选择Nordic nRF52832，配置好射频参数和连接间隔
- HCI：使用SDK默认的UART HCI，不用改
- L2CAP：MTU设为247，提升数据传输效率
- GATT：定义温湿度Service，包含Temperature和Humidity两个Characteristic
- GAP：设备角色设为Peripheral，广播间隔设为100ms
- Application：每5秒读取传感器，更新GATT特征值
你看，每一层都有明确的配置项。如果出了问题，你也能快速定位：
- 手机搜不到设备？查GAP广播配置
- 能搜到但连不上？查LL连接参数
- 连上了读不到数据？查GATT Service UUID
- 数据读出来是乱码？查L2CAP MTU和分包逻辑
调试技巧：我习惯在代码里给每一层加独立的日志开关。比如：
#define LOG_PHY_ENABLE 0
#define LOG_LL_ENABLE 1
#define LOG_HCI_ENABLE 1
#define LOG_L2CAP_ENABLE 0
#define LOG_GATT_ENABLE 1
#define LOG_GAP_ENABLE 1
#define LOG_APP_ENABLE 1这样调试时可以只开需要的层，日志不会刷屏。
1.7 小结
BLE协议栈的分层设计，不是学术上的花架子。它是经过大量产品验证的工程实践。每一层都有明确的边界和接口，这让我们在开发时能分而治之。
我个人觉得，理解分层哲学比记住每一层的API更重要。因为API会变，但分层思想不会变。你掌握了这个思想，换芯片、换SDK、甚至换协议栈（比如从Nordic SoftDevice换到Zephyr），都能快速上手。
嗯，这一章就到这里。记住这张分层图，后面每一章都会回到它上面来。