1. 蓝牙技术概述：从1.0到5.4，经典与低功耗的博弈
各位同学，咱们今天聊聊蓝牙技术。说实话，我最早接触蓝牙是在2008年，那时候还在做功能机。当时蓝牙给我的印象就是——配对慢、功耗高、传输距离短。但十几年下来，蓝牙已经从一个“能用”的技术，变成了物联网时代不可或缺的基础设施。
这一章，我带你梳理蓝牙的发展脉络，搞清楚经典蓝牙和低功耗蓝牙到底差在哪，最后把协议栈的骨架搭起来。嗯，这些基础打不牢，后面移植和定制化开发你会很痛苦。
1.1 蓝牙发展史：从1.0到5.4，每一步都是血泪
蓝牙技术诞生于1994年，爱立信想搞一个替代RS232线缆的短距离无线通信方案。1998年，蓝牙特别兴趣小组（SIG）成立，1999年发布了蓝牙1.0规范。
蓝牙1.0/1.1（1999-2001）：说实话，这版本就是个半成品。设备之间互不兼容，配对流程极其繁琐。我记得有老工程师跟我吐槽过，当年两台蓝牙设备能连上，那得烧高香。
蓝牙1.2（2003）：引入了自适应跳频（AFH），抗干扰能力大幅提升。为什么？因为Wi-Fi和蓝牙都在2.4GHz频段，不跳频的话，你连个耳机都能被Wi-Fi干扰断连。我在项目中遇到过类似问题，后来发现是AFH算法没配置好。
蓝牙2.0/2.1（2004-2007）：2.0引入了EDR（增强数据率），速率从1Mbps提升到3Mbps。2.1则加入了安全简单配对（SSP），配对体验好了不少。但说实话，功耗问题依然没解决。
蓝牙3.0（2009）：这个版本有点意思，它引入了AMP（交替MAC/PHY），可以借用Wi-Fi的物理层来传输数据，理论速率能到24Mbps。但实际用的人很少，为什么？因为功耗太高了，而且需要双模芯片。
蓝牙4.0（2010）：这是蓝牙历史上最重要的一个版本。它首次引入了低功耗蓝牙（BLE）技术。我当年第一次看到BLE的功耗数据时，简直不敢相信——一颗纽扣电池能跑几个月甚至几年。从4.0开始，蓝牙分成了两条线：经典蓝牙（BR/EDR）和低功耗蓝牙（BLE）。
蓝牙4.1/4.2（2013-2014）：4.1让BLE可以和LTE共存，4.2则引入了LE安全连接和隐私保护。4.2还扩展了数据包长度，从27字节增加到251字节。嗯，这个改动对吞吐量提升很明显。
蓝牙5.0（2016）：又是一个里程碑。速率翻倍到2Mbps，距离提升4倍（理论可达300米），广播数据包容量提升8倍。还引入了LE Coded PHY，用冗余编码换距离。我在做智能家居项目时，就靠5.0的远距离特性，实现了整栋楼的传感器覆盖。
蓝牙5.1/5.2（2019-2020）：5.1加入了测向功能（AoA/AoD），可以实现厘米级定位。5.2则引入了LE Audio，这是音频领域的革命——LC3编解码器、多流音频、广播音频。我个人觉得，LE Audio会让传统蓝牙耳机彻底换代。
蓝牙5.3/5.4（2021-2023）：5.3优化了功耗和稳定性，5.4则加入了带响应的周期性广播（PAwR）和加密广播数据（EAD）。这些特性对电子货架标签（ESL）和工业传感器网络非常有用。
核心要点：蓝牙版本向下兼容，但新特性需要芯片和协议栈都支持。你移植协议栈时，一定要确认芯片硬件支持哪些版本特性。
1.2 经典蓝牙 vs 低功耗蓝牙：不是替代，是互补
很多初学者会问：BLE是不是蓝牙的升级版？其实不是。经典蓝牙（BR/EDR）和低功耗蓝牙（BLE）是两条不同的技术路线，各有各的适用场景。
| 对比项 | 经典蓝牙（BR/EDR） | 低功耗蓝牙（BLE） |
|---|---|---|
| 设计目标 | 连续数据流，如音频 | 低功耗、间歇性数据传输 |
| 功耗 | 高（mA级） | 极低（μA级） |
| 峰值速率 | 3Mbps（EDR） | 2Mbps（BLE 5.0） |
| 连接建立时间 | 约100ms | 约3ms |
| 数据包结构 | 复杂，面向连接 | 简单，面向广播和连接 |
| 典型应用 | 蓝牙耳机、车载免提 | 传感器、手环、信标 |
| 网络拓扑 | 微微网（1主7从） | 广播、连接、Mesh |
你想想看，为什么BLE能这么省电？说白了，BLE的物理层设计就是为“短时突发”服务的。它不传输数据时就深度睡眠，连接事件间隔可以配置到几百毫秒甚至几秒。而经典蓝牙需要维持一个连续的连接，功耗自然下不来。
我在项目中遇到过一个问题：客户想用经典蓝牙做传感器数据采集，结果电池两天就没电了。后来换成BLE，同样的数据量，电池撑了半年。这就是选错技术路线的代价。
避坑指南：如果你需要传输音频或大量连续数据，选经典蓝牙。如果你需要低功耗、小数据量、长待机，选BLE。两者不能互相替代。
1.3 蓝牙协议栈架构概览：Controller、Host、Application
蓝牙协议栈的架构，说白了就是分三层：Controller（控制器）、Host（主机）、Application（应用）。这个分层设计的好处是，你可以把Controller和Host分开实现，甚至跑在不同的芯片上。
Controller层：这是最靠近硬件的一层。它包含物理层（PHY）和链路层（LL）。PHY负责射频信号的收发，LL负责数据包的组装、拆解、重传、加密等。Controller通常由蓝牙芯片厂商提供，以固件形式存在。你移植协议栈时，Controller部分基本不用动，除非你要做芯片级别的定制。
Host层：这是协议栈的核心。它包含L2CAP（逻辑链路控制与适配协议）、SMP（安全管理器）、ATT（属性协议）、GATT（通用属性协议）等。Host层不关心物理层怎么收发数据，它只负责逻辑上的连接管理、数据分发、安全配对等。Host层通常以软件库的形式提供，你可以根据自己的需求裁剪。
Application层：这是你写业务逻辑的地方。通过GATT Profile来定义服务和特征值。比如一个温度传感器，你可以定义一个温度服务，包含一个温度特征值。应用层代码完全由你掌控。
我个人的习惯是，在移植协议栈时，先把Host层和Controller层的接口（HCI）调通。HCI是Host和Controller之间的桥梁，它定义了命令、事件、数据的交换格式。HCI调通了，剩下的就是配置Profile和写应用逻辑。
核心要点：蓝牙协议栈的移植工作，90%的精力花在Host层。Controller层通常由芯片厂商提供，你只需要确保HCI接口正确即可。
举个例子，假设你要移植一个BLE协议栈到STM32上。你需要做的是：
- 确认STM32的UART或SPI接口能正确收发HCI数据包
- 实现HCI的底层驱动（发送和接收）
- 将Host层代码编译进STM32工程
- 配置GATT Profile，编写应用回调
嗯，听起来简单，但实际做起来坑不少。比如HCI数据包的格式、流控机制、事件处理顺序，稍有不慎就会导致连接失败或数据错乱。我在第一次移植时，就因为HCI的流控没处理好，导致设备连上就断，折腾了两天才找到原因。
注意事项：不同芯片厂商的HCI实现可能有差异。比如TI的CC254x和Nordic的nRF52系列，HCI命令的时序要求就不一样。移植时一定要参考芯片厂商的参考手册。
好了，这一章的内容就到这里。蓝牙的发展史、经典与低功耗的区别、协议栈的三层架构，这些是后续所有章节的基础。下一章，我会带你手把手搭建开发环境，并跑通第一个BLE示例。到时候你会发现，理论懂了，动手做又是另一回事。