2. 蓝牙协议栈详解：经典蓝牙(BR/EDR)与低功耗蓝牙(BLE)协议栈架构对比
说到蓝牙协议栈，很多刚入行的朋友容易搞混。经典蓝牙和低功耗蓝牙，虽然都叫蓝牙，但协议栈的架构差异其实挺大的。我最早接触蓝牙时也踩过坑——以为两者差不多，结果在项目选型时吃了亏。今天咱们就把这两套协议栈掰开揉碎了讲清楚。
2.1 经典蓝牙(BR/EDR)协议栈架构
经典蓝牙，也叫BR/EDR（Basic Rate / Enhanced Data Rate）。它最早是为了替代串口线而设计的。你想想看，当年用蓝牙耳机打电话、用蓝牙传文件，都是它的功劳。
它的协议栈长这样：
+-------------------------------+
| 应用层 (APP) |
+-------------------------------+
| RFCOMM / SDP |
+-------------------------------+
| L2CAP |
+-------------------------------+
| HCI (主机控制器接口) |
+-------------------------------+
| 链路管理器 (LM) / 链路控制器 |
+-------------------------------+
| 基带层 (Baseband) |
+-------------------------------+
| 射频层 (RF) |
+-------------------------------+我习惯把经典蓝牙协议栈分成三块来看：
- 控制器层：包括射频、基带、链路管理器。这部分负责物理传输和链路建立。
- 主机层：包括L2CAP、RFCOMM、SDP等。这部分负责数据封装和服务发现。
- 应用层：你写的蓝牙应用代码就在这层。
这里有个关键点——HCI接口。它把控制器和主机分开。我在做嵌入式项目时，经常看到有人把HCI理解成简单的串口通信，其实它定义了完整的命令、事件、数据包格式。嗯，这里要注意，HCI的传输方式可以是UART、USB或SDIO，选型时得看你的硬件资源。
核心特点：经典蓝牙支持面向连接的同步链路（SCO）和面向分组的异步链路（ACL）。SCO用于语音传输，ACL用于数据传输。说白了，打电话用SCO，传文件用ACL。
2.2 低功耗蓝牙(BLE)协议栈架构
BLE是后来才出现的。它的设计目标很明确——省电。我参与过一个穿戴设备项目，用经典蓝牙的话，电池撑不过一天。换成BLE后，续航直接拉到一周。差距就这么大。
BLE的协议栈架构：
+-------------------------------+
| 应用层 (APP) |
+-------------------------------+
| GATT / GAP |
+-------------------------------+
| ATT / SMP |
+-------------------------------+
| L2CAP |
+-------------------------------+
| HCI (可选，有些芯片集成) |
+-------------------------------+
| 链路层 (Link Layer) |
+-------------------------------+
| 物理层 (PHY) |
+-------------------------------+你看，BLE的协议栈比经典蓝牙精简了不少。它去掉了RFCOMM、SDP这些复杂的东西，换成了GATT和GAP。为什么？因为BLE的应用场景大多是传感器数据上报、设备控制这类轻量级通信，不需要那么复杂的协议支持。
我个人觉得，BLE协议栈最巧妙的设计是链路层。它定义了四种角色：
- 广播者（Broadcaster）：只发不连，比如信标设备
- 观察者（Observer）：只收不连，比如扫描设备
- 外设（Peripheral）：可被连接，比如传感器
- 中心（Central）：主动连接，比如手机
我曾经在调试一个BLE门锁项目时，发现外设老是连不上。查了半天，原来是广播间隔设得太长了。广播间隔短，功耗高但连接快；广播间隔长，省电但连接慢。这个平衡点，得根据实际场景来调。
避坑指南：BLE的GATT协议定义了服务和特征值的概念。我建议你在设计应用层时，先把服务UUID和特征值属性规划好。别像我早期那样，边写代码边改，最后发现特征值权限设错了，读写成问题。
2.3 两者核心差异对比
咱们直接上表格，一目了然：
| 对比项 | 经典蓝牙 (BR/EDR) | 低功耗蓝牙 (BLE) |
|---|---|---|
| 设计目标 | 高吞吐、连续传输 | 低功耗、间歇传输 |
| 物理层 | 79个信道，1MHz带宽 | 40个信道，2MHz带宽 |
| 调制方式 | GFSK，速率1-3Mbps | GFSK，速率1Mbps/2Mbps |
| 连接方式 | 点对点，主从架构 | 广播+连接，灵活拓扑 |
| 功耗 | 较高（mA级） | 极低（μA级） |
| 应用层协议 | RFCOMM、SPP、HFP等 | GATT、GAP |
| 典型场景 | 音频传输、文件传输 | 传感器、穿戴设备、信标 |
为什么BLE能这么省电？说白了，它的链路层设计了两种状态：连接状态和广播状态。不传数据时就睡觉，醒来发个广播包或者传完数据立刻睡。经典蓝牙则不同，它需要保持连接状态，即使没数据传，也得定时交换心跳包。
注意事项：别以为BLE一定比经典蓝牙好。如果你要传音频流或者大文件，经典蓝牙的吞吐量和稳定性更靠谱。我见过有人硬要用BLE传语音，结果延迟大得没法用。选型时一定要看业务需求，别盲目追新。
2.4 双模芯片的协议栈处理
现在很多芯片支持双模——经典蓝牙和BLE共存。比如我常用的某款芯片，内部其实跑了两套协议栈。它们共享射频前端，但链路层和上层协议是独立的。
双模芯片的工作模式：
- 交替模式：分时复用射频，一会儿跑BR/EDR，一会儿跑BLE
- 并行模式：同时处理两种协议，但需要更复杂的调度
我在做双模网关项目时，遇到过一个问题：经典蓝牙在传音频时，BLE的扫描响应变慢了。原因是射频资源被经典蓝牙占用了。解决办法是调整两种协议的优先级和时隙分配。嗯，这个调优过程挺折腾的，但搞明白了就一通百通。
2.5 我的选型建议
最后给点实在的建议：
- 纯数据上报场景（温湿度、心率等）：选BLE，省电是王道
- 音频传输场景（耳机、音箱）：选经典蓝牙，别犹豫
- 需要同时支持两种场景：选双模芯片，但要做好协议栈调度
- 低延迟控制场景（游戏手柄）：BLE的LE Audio或经典蓝牙都行，看生态
我记得有一次，客户非要在一个纽扣电池设备上用经典蓝牙传音频。我跟他解释了半天功耗问题，最后他妥协了，改成了BLE传输压缩音频。你看，技术选型有时候不是能不能做，而是值不值得做。
好了，经典蓝牙和BLE的协议栈对比就聊到这儿。下一章咱们深入BLE的GATT协议，讲讲服务和特征值到底怎么设计才合理。