2、蓝牙技术基础：BLE协议栈架构（Controller、Host、Application）、BLE与经典蓝牙区别、BLE应用场景

蓝牙技术自1994年由爱立信提出以来，已经演进出两条截然不同的技术路线：经典蓝牙（BR/EDR，Basic Rate/Enhanced Data Rate）和低功耗蓝牙（BLE，Bluetooth Low Energy）。在嵌入式开发中，BLE之所以能够以极低的功耗实现短距离无线通信，核心在于其协议栈的分层设计——这种设计将射频控制、链路管理与应用逻辑彻底解耦，使得开发者可以在不深入底层硬件细节的情况下，高效地完成设备开发。本章将围绕BLE协议栈的三层架构（Controller、Host、Application）展开，深入剖析其工作原理，并与经典蓝牙进行系统性对比，最后结合典型应用场景说明协议栈选型与移植的工程考量。

2.1 BLE协议栈架构：Controller、Host、Application三层解耦

2.1.1 核心原理：为什么需要分层？

BLE协议栈的设计哲学与经典蓝牙一脉相承，但针对低功耗场景做了大量简化。整个协议栈从下至上分为三层：Controller（控制器）、Host（主机）和Application（应用）。这种分层结构的核心价值在于物理隔离与逻辑解耦：Controller负责所有与射频硬件直接相关的操作，Host负责逻辑链路与协议管理，Application则完全面向业务。在实际芯片方案中，Controller通常集成在蓝牙SoC内部（如Nordic nRF52系列、TI CC2640），而Host既可以运行在同一颗芯片上（单核方案），也可以运行在外部MCU上（双核方案，如HCI UART连接）。

从数据流角度看，应用层通过GATT/API接口发起请求，Host层将请求封装为L2CAP数据包，再通过HCI接口下发到Controller，Controller的链路层（LL）负责将数据封装为物理层PDU（Protocol Data Unit），最终通过2.4GHz射频发送出去。接收方向则完全相反。理解这条数据链路，是后续进行FreeRTOS移植时任务划分的基础——例如，Host层任务优先级通常高于应用层任务，而Controller中断服务程序（ISR）又必须高于Host任务。

2.1.2 各层职责与关键子模块

这里需要特别强调GAP与GATT的区别：GAP（Generic Access Profile）定义了设备如何被发现、如何建立连接，它决定了设备是作为广播者（Peripheral）还是扫描者（Central）；而GATT（Generic Attribute Profile）定义了连接建立后数据如何组织与交换，它基于Attribute表结构，通过Service和Characteristic来暴露数据。初学者常将两者混淆，实际上GAP是“门卫”，GATT是“仓库管理员”。

2.1.3 案例拆解：nRF52832单芯片方案中的任务划分

以Nordic nRF52832为例，该芯片内部集成了完整的BLE Controller（硬件链路层）和Host协议栈（SoftDevice固件）。当我们在其上移植FreeRTOS时，典型的任务划分如下：

• 任务1（最高优先级）：SoftDevice回调处理（BLE事件派发），负责将Controller产生的事件（如连接建立、数据到达）传递给Host层。
• 任务2（中优先级）：GATT服务处理，处理读写请求、发送通知（Notification）。
• 任务3（低优先级）：应用业务逻辑，如传感器数据采集、状态机流转。

这种划分的工程依据是：BLE协议栈要求Host层事件必须在协议栈调度上下文中处理，不能直接在中断中调用。FreeRTOS通过提供专用的BLE协议栈任务（如ble_stack_task）来满足这一约束。如果应用层任务与协议栈任务共享优先级，可能导致事件处理延迟，进而触发链路层超时断开连接。

2.2 BLE与经典蓝牙的区别：不只是“低功耗”

2.2.1 核心原理：两种技术路线的本质差异

经典蓝牙（BR/EDR）和BLE虽然共享2.4GHz频段，但它们在设计目标上截然不同。经典蓝牙面向持续数据流（如音频通话、文件传输），强调高吞吐量和稳定的同步连接；BLE面向间歇性小数据包（如传感器读数、控制指令），强调极低的峰值功耗和快速连接。这种差异体现在物理层调制方式上：经典蓝牙使用GFSK（高斯频移键控）且支持DQPSK/8DPSK等增强速率，而BLE仅使用GFSK，符号速率固定为1Mbps（BLE 5.0后支持2Mbps）。

2.2.2 对比表：关键参数与行为差异

2.2.3 判断方法：如何选择BLE还是经典蓝牙？

在实际产品选型中，可以从以下三个维度进行判断：

1. 数据量：如果单次传输数据超过1KB且需要持续传输（如音频流），选择经典蓝牙；如果单次传输小于200字节且传输频率低（如温度上报），选择BLE。
2. 功耗预算：如果设备使用纽扣电池（如CR2032）且期望工作1年以上，必须选择BLE；如果设备有充电电池且可频繁充电，经典蓝牙也可接受。
3. 连接时延：如果用户期望“开箱即连”（如蓝牙耳机），经典蓝牙的快速连接体验更好；如果设备是传感器节点，允许几秒的扫描延迟，BLE更合适。

2.3 BLE应用场景与协议栈适配

2.3.1 典型应用场景分类

BLE的应用场景可以归纳为四大类：广播类（Beacon、室内定位）、连接类（可穿戴设备、HID外设）、Mesh类（智能照明、楼宇自动化）、广播+连接混合类（资产追踪标签）。每种场景对协议栈的配置要求不同：

• 广播类：只需启用Controller的广播功能，Host层可裁剪GATT服务，甚至不需要建立连接。此时FreeRTOS只需一个任务处理广播事件。
• 连接类：需要完整的GATT服务，且要处理连接参数更新（Connection Parameter Update）、MTU协商等。FreeRTOS需要至少两个任务（协议栈任务+应用任务）。
• Mesh类：需要额外的Mesh协议栈（如Nordic的nRF Mesh），这会在Host层之上增加一层，对内存和任务调度要求更高。

2.3.2 案例拆解：智能门锁的BLE协议栈配置

以一款基于BLE的智能门锁为例，其核心需求是：手机App（Central）通过BLE连接门锁（Peripheral），完成身份认证和开锁指令下发。门锁使用CR2电池供电，要求待机功耗低于5µA，开锁响应时间小于500ms。

初始现象与目标：门锁在待机时处于广播状态，但广播间隔设置为1秒，导致待机电流达到15µA，电池寿命仅6个月。目标是将待机电流降至5µA以下，同时保证手机靠近时能快速连接。

分析过程：通过功耗分析仪抓取电流曲线，发现广播事件（约2ms）平均电流8mA，1秒周期下平均电流约15µA。进一步分析发现，广播数据包长度为31字节，且包含完整的设备名称和Service UUID，这增加了广播时长。

优化操作：

1. 将广播间隔从1秒调整为500ms（降低广播频率），但保留快速广播（Fast Advertising）机制，即前30秒以100ms间隔广播，之后切换为1s间隔。
2. 精简广播数据：移除设备名称（通过扫描响应SCAN_RSP提供），广播包仅保留Service UUID和厂商自定义数据（共12字节）。
3. 在FreeRTOS中，将广播任务设计为“事件触发+定时器”模式：平时任务挂起，由RTC唤醒执行广播，广播完成后立即重新挂起。

结果对比：优化后待机电流降至4.2µA，电池寿命提升至约2年。手机靠近时，由于快速广播机制，连接建立时间仍保持在200ms以内。

复盘经验：BLE功耗优化不是单纯依赖协议栈，而是需要结合应用层调度（FreeRTOS任务管理）和广播参数配置。在移植FreeRTOS时，应使用vTaskDelayUntil实现精确的广播周期，避免使用vTaskDelay造成的累积误差。

2.3.3 常见误区与总结