📚 课程目录第1章蓝牙基础与协议栈概览

1、蓝牙基础与协议栈概览

各位同学，咱们今天正式开讲蓝牙。说实话，蓝牙这东西，我入行那会儿还是个「玄学」——连上了叫运气，连不上叫常态。但现在不一样了，尤其是 BLE（低功耗蓝牙）出来之后，整个物联网的玩法都变了。

这一章，我会带你从蓝牙的「前世今生」开始，把协议栈的骨架搭起来。你不需要死记硬背，但得理解每一层是干嘛的。我当年调试一个 BLE 广播包，死活收不到数据，最后发现是 Controller 层的时序配置错了——嗯，这种坑，我希望你别踩。

蓝牙技术从 1994 年诞生到现在，其实分了两条路：

我刚开始做项目时，总觉得 BLE 就是经典蓝牙的「省电版」。后来发现，这俩的协议栈几乎完全不同。BLE 的 Controller 和 Host 是分开的，而经典蓝牙是揉在一起的。你想想看，这直接决定了调试方式的不同。

我的经验： 选型时别只看「支持蓝牙」三个字。如果项目是纽扣电池供电，必须用 BLE。经典蓝牙的功耗，你扛不住的。

BLE 协议栈分三层：Controller、Host、Application。我习惯把它比作一个快递系统：

为什么这么分？因为很多芯片把 Controller 和 Host 做在不同的芯片上。比如你用一个 Nordic nRF52832，它俩都在一颗芯片里。但如果你用 TI CC2540，Host 跑在 MCU 上，Controller 跑在射频芯片上——调试时就得两边抓。

  核心要点： Controller 和 Host 之间通过 HCI（Host Controller Interface）通信。HCI 的调试，是嵌入式工程师的必修课。我曾经因为 HCI 的 UART 波特率配错，浪费了整整两天。

BLE 定义了四种角色。别被名字吓到，其实就两类：发广播的和收广播的，连上的和等连的。

我记得第一次做 BLE 项目，把 Peripheral 和 Broadcaster 搞混了。Peripheral 广播是为了让别人连，Broadcaster 广播完就完事了。你想想看，如果心率带只广播不连接，那手机怎么拿到实时数据？

注意： 一个设备可以同时支持多个角色。比如手机既是 Central（连手环），也可以是 Peripheral（被电脑连）。但功耗会翻倍，别乱开。

BLE 的通信流程，说白了就四步：广播 → 扫描 → 连接 → 数据传输。我画了一张图，你一看就明白。

具体每一步做什么？

广播：Peripheral 在三个广播信道（37/38/39）上发广播包。包里包含设备名称、服务 UUID、发射功率等。我习惯把广播包叫「名片」——你得让别人知道你是谁。
扫描：Central 在广播信道上监听。收到广播包后，可以发起扫描请求，获取更多信息。注意，扫描是有功耗代价的——一直开着扫描，电池扛不住。
连接：Central 发连接请求，Peripheral 接受。连接后，双方约定连接间隔（connection interval）。这个间隔很关键——间隔越短，延迟越低，但功耗越高。
数据传输：通过 GATT（通用属性协议）读写数据。GATT 把数据组织成 Service 和 Characteristic。比如一个温度传感器，有一个 Temperature Service，里面包含一个 Temperature Characteristic。

避坑指南： 我曾经把连接间隔设成 7.5ms，结果设备 3 小时就没电了。后来改成 100ms，续航直接到一周。你想想看，间隔差 13 倍，功耗差多少？

这一章，我们把蓝牙的底裤扒开了：