1. BLE协议栈概述：从技术演进到实战选型
各位同学，咱们今天聊聊BLE协议栈。说实话，我入行那会儿，蓝牙还是2.0时代，功耗高、配对慢，跟现在完全不是一个概念。后来低功耗蓝牙（BLE）一出来，整个物联网行业都炸了——功耗降了几个数量级，纽扣电池能跑一年，这谁顶得住？
我个人习惯，学任何协议栈之前，先搞清楚它为什么这么设计。你想想看，BLE要解决的核心问题是什么？说白了就三个：低功耗、低成本、易连接。传统蓝牙像个体力劳动者，啥活都干；BLE像个精明的管家，只在你需要的时候出现。
1.1 BLE技术演进：从4.0到5.4，我踩过的坑
BLE从4.0开始，一路走到现在的5.4。每个版本我都跟过项目，有些坑现在想起来还头疼。
| 版本 | 核心特性 | 我的实战感受 |
|---|---|---|
| 4.0/4.1 | 基础BLE，1Mbps，广播+连接 | 配对慢，兼容性差，我调过一款手环，跟某品牌手机死活连不上 |
| 4.2 | LE Secure Connections，数据长度扩展 | 安全性提升明显，但有些老芯片不支持，踩过坑 |
| 5.0 | 2Mbps，LE Coded PHY，广播扩展 | 速度翻倍，但穿墙能力还是弱，我在工厂项目里吃过亏 |
| 5.1/5.2 | 方向定位，LE Audio，等时信道 | 音频应用开始爆发，但协议栈复杂度也上来了 |
| 5.3/5.4 | 周期性广播增强，加密改进 | 目前最新，但生态还不成熟，建议观望 |
避坑指南： 我曾经在一个项目中选了5.0的芯片，结果发现广播扩展（Advertising Extensions）在密集场景下冲突严重。后来被迫降级到4.2的经典广播模式才稳定。所以，别盲目追新，稳定才是王道。
1.2 协议栈架构：Controller、Host、Application，谁管谁？
BLE协议栈分三层，这个架构我画过不下百遍。你想想看，它就像个公司：
- Controller（底层员工）：管物理层和链路层。说白了就是发数据、收数据、做时序。这部分通常固化在芯片里，你改不了。
- Host（中层管理）：管L2CAP、ATT、GATT、SM、GAP。这是协议栈的核心，也是我们移植和调优的主战场。
- Application（老板）：管业务逻辑。你定义服务、特征值、连接策略，全在这层。
为什么这么分？我个人的理解是——为了解耦。芯片厂商管Controller，协议栈厂商管Host，你做Application。各司其职，出了问题也好定位。
关键点： Host和Controller之间通过HCI（Host Controller Interface）通信。HCI可以是UART、USB、SPI，甚至共享内存。我在一个项目中用过UART HCI，波特率设到2Mbps才勉强够用，后来换成SPI才解决吞吐瓶颈。
1.3 常见协议栈对比：Zephyr、NimBLE、TI、Nordic，我该选哪个？
这个问题，几乎每个学员都问过我。说实话，没有最好的，只有最合适的。我列个表，你们自己品：
| 协议栈 | 开源/商业 | 特点 | 适合场景 | 我的评价 |
|---|---|---|---|---|
| Zephyr | 开源（Apache 2.0） | 模块化，支持多架构，社区活跃 | 复杂产品，多芯片平台 | 功能全，但学习曲线陡，我花了两个月才上手 |
| NimBLE | 开源（Apache 2.0） | 轻量，内存占用小，易移植 | 资源受限设备，RTOS环境 | 我的最爱，在STM32上跑过，RAM只用了8KB |
| TI（CC13xx/CC26xx） | 商业（部分开源） | 稳定，文档全，工具链成熟 | 工业级产品，量产项目 | 文档确实好，但闭源部分调试起来很痛苦 |
| Nordic（SoftDevice） | 商业（闭源） | 性能强，生态好，nRF5 SDK成熟 | 可穿戴，低功耗传感器 | 闭源是双刃剑，出了问题只能找FAE |
我的建议： 如果你刚开始学BLE，从NimBLE入手。它轻量、干净，代码量不到Zephyr的十分之一。等你把协议栈的脉络摸清了，再去看Zephyr或者TI的复杂实现，会轻松很多。
1.4 实战选型：我踩过的三个坑
嗯，这里我得说点掏心窝子的话。协议栈选型，我栽过三次：
- 第一次： 选了个功能最全的协议栈，结果芯片Flash只有128KB，编译完直接超了。后来换NimBLE，省了60KB空间。
- 第二次： 迷信大厂，选了某商业协议栈。结果有个bug，官方拖了三个月才修。从那以后，我优先选开源方案，至少自己能改。
- 第三次： 没考虑RTOS兼容性。项目后期要加FreeRTOS，结果协议栈不支持，只能重写调度层。现在我的习惯是，先确认协议栈的OS抽象层是否完善。
所以，选协议栈之前，先问自己三个问题：
- 我的芯片资源够不够？（Flash、RAM、时钟）
- 我的团队有没有能力改源码？（开源还是商业？）
- 我的RTOS是什么？（裸机、FreeRTOS、Zephyr？）
想清楚这些，再下手。别像我当年一样，先选再改，最后改到怀疑人生。
总结一下： BLE协议栈的移植和调优，说白了就是理解架构、选对方案、避开坑。后面的章节，我会带大家一步步把NimBLE移植到STM32上，从HCI层到GATT层，手把手调通。准备好了吗？咱们开始干。