1. BLE基础概念：协议栈架构、物理层、链路层、主机控制接口
各位同学，咱们今天聊聊BLE最底层的那些事儿。说实话，很多做蓝牙开发的朋友，一上来就扎进应用层代码里，对底层协议栈一知半解。我个人习惯是，先把地基打牢，后面调性能、抠功耗的时候，你才知道问题出在哪。
1.1 BLE协议栈的整体架构
BLE协议栈，说白了就是一套分层的软件体系。它把复杂的无线通信拆成了几个清晰的层次，每一层只管自己的事儿，层与层之间通过标准接口通信。
我习惯把协议栈分成三大部分：
- 控制器（Controller）：负责最底层的射频收发、链路管理。包括物理层、链路层，以及主机控制接口的底层部分。
- 主机（Host）：负责上层协议，包括L2CAP、ATT、GATT、SM、GAP等。你平时调用的那些API，基本都在这一层。
- 主机控制接口（HCI）：连接控制器和主机的桥梁。它可以是UART、USB、SPI等物理总线，也可以是软件模拟的内部接口。
你想想看，为什么BLE能这么省电？很大程度上就是因为这套分层设计。控制器可以独立完成很多工作，主机该睡觉就睡觉，不用一直醒着。
核心要点：BLE协议栈的分层设计，本质上是把「实时性要求高的底层」和「灵活性要求高的上层」解耦。控制器负责硬实时任务，主机负责应用逻辑。
1.2 物理层（PHY）—— 信号在空气中怎么飞
物理层是协议栈的最底层，它直接跟天线打交道。我记得刚做蓝牙项目那会儿，总觉得物理层是硬件工程师的事儿，软件不用管。后来被坑过一次——天线匹配没做好，通信距离直接砍半。嗯，从那以后我再也不敢小看物理层了。
BLE的物理层有几个关键参数：
| 参数 | 说明 |
|---|---|
| 工作频段 | 2.4GHz ISM频段，2400-2483.5 MHz |
| 信道数量 | 40个信道，每个2MHz宽 |
| 调制方式 | GFSK（高斯频移键控） |
| 数据速率 | 1Mbps（LE 1M PHY）或 2Mbps（LE 2M PHY） |
| 发射功率 | 通常 -20dBm 到 +10dBm，部分芯片可达 +20dBm |
这里有个细节我想强调一下：BLE的40个信道，其中3个是广播信道（37/38/39），37个是数据信道。为什么这么设计？
说白了，就是为了避开Wi-Fi的干扰。2.4GHz频段上Wi-Fi占着20MHz宽的信道，BLE用2MHz窄信道，再加上跳频技术，就能在Wi-Fi的夹缝里生存。我在一个智能家居项目里遇到过，Wi-Fi和BLE同时跑，一开始连接总断，后来调整了信道映射，问题就解决了。
实战技巧：如果你的产品部署在Wi-Fi密集的环境（比如办公楼、商场），建议把BLE的广播信道避开Wi-Fi的1、6、11信道中心频率。具体做法是调整广播信道的发射时序，或者干脆用扩展广播。
1.3 链路层（LL）—— 连接的指挥官
链路层是BLE协议栈里最核心的一层。它负责管理设备的状态机、控制数据包的收发、处理加密和重传。我个人觉得，理解了链路层，你就理解了BLE为什么省电。
链路层定义了五种设备状态：
- 待机（Standby）：啥也不干，最省电
- 广播（Advertising）：向外发送广播包，让别人发现自己
- 扫描（Scanning）：监听广播包，找周围设备
- 发起（Initiating）：主动连接某个广播设备
- 连接（Connection）：已建立连接，可以收发数据
你可能会问：「为什么广播和扫描不能同时进行？」其实技术上可以，但功耗会翻倍。BLE的设计哲学就是——能不做的事就不做，能少做的事就少做。
链路层还有一个关键概念叫连接事件（Connection Event）。主设备和从设备约定好，每隔一段时间（连接间隔）交换一次数据。每次交换就是一个连接事件。在连接事件之间，设备可以进入休眠状态。
省电的核心秘密就在这里：连接间隔越长，设备休眠时间越长，平均功耗越低。但代价是数据延迟变大。这就是「性能与功耗的平衡艺术」最直接的体现。
我曾经做过一个穿戴设备项目，客户要求数据每秒更新一次，同时电池要撑一周。我算了一下，连接间隔设到100ms，功耗还是偏高。后来用了从设备延迟（Slave Latency）——允许从设备跳过一些连接事件，只在有数据时才响应。最终把平均电流从200μA降到了50μA。嗯，这就是链路层参数调优的价值。
1.4 主机控制接口（HCI）—— 上下层的翻译官
HCI是控制器和主机之间的通信接口。它定义了一套标准的命令、事件和数据包格式。不管底层是UART、USB还是SDIO，上层代码看到的HCI接口都是一样的。
HCI的数据包类型主要有四种：
- 命令包（Command Packet）：主机发给控制器，比如「开始扫描」、「建立连接」
- 事件包（Event Packet）：控制器发给主机，比如「扫描到设备」、「连接已断开」
- 数据包（Data Packet）：双向传输，承载应用数据
- 同步数据包（Synchronous Data Packet）：用于音频等实时数据流
避坑指南：我曾经在一个项目里，HCI用的是UART接口，波特率设了115200。结果发现数据量大时，UART成了瓶颈，导致连接不稳定。后来把波特率提到921600，问题解决。记住：HCI的传输速率必须大于应用数据速率，否则会丢包。
HCI还有一个容易被忽略的点——HCI流控。当主机发送数据太快，控制器处理不过来时，就需要流控机制来协调。标准HCI支持基于硬件（CTS/RTS）和软件（XON/XOFF）两种流控方式。我建议在量产产品里一定要启用硬件流控，软件流控在高速场景下容易出问题。
1.5 小结与思考
好了，咱们把BLE协议栈的底层骨架梳理了一遍。从物理层的射频信号，到链路层的连接管理，再到HCI的上下沟通，每一层都有自己的职责和设计哲学。
我个人觉得，理解这些基础概念最大的价值在于：当你遇到性能或功耗问题时，你能快速定位问题出在哪一层。是天线匹配不好（物理层）？还是连接间隔设置不合理（链路层）？或者是HCI通信有瓶颈？
下一章咱们会深入链路层的核心——连接管理与数据通道，到时候会讲更多实战调优的技巧。各位可以先想想：如果你的产品需要同时兼顾低功耗和低延迟，你会怎么设计连接参数？
课后练习：找一块BLE开发板，用抓包工具（比如Ellisys或nRF Sniffer）抓一下广播包和连接包。看看实际传输中，连接间隔、从设备延迟这些参数是怎么体现的。纸上得来终觉浅，动手抓一次包，比看十遍文档都管用。