2、ESP32与BLE基础：芯片架构、BLE协议栈、GATT与GAP概念，以及BLE在物联网中的角色
在边缘AI课程中，ESP32之所以成为首选平台，是因为它在成本、功耗、算力与无线连接能力之间取得了极佳的平衡。本章将深入剖析ESP32的芯片架构、BLE协议栈的分层结构、GATT与GAP两大核心协议，并阐明BLE在物联网生态中的定位。理解这些底层机制，是后续实现“蓝牙传感器数据采集+模型推理”的基础——只有清楚数据从传感器到手机App的完整路径，才能在设计边缘AI应用时做出合理的架构决策。
2.1 ESP32芯片架构：边缘AI的硬件基石
ESP32系列芯片由乐鑫科技设计，其核心架构围绕双核处理器、丰富外设和无线通信单元展开。对于边缘AI应用而言，理解芯片架构有助于合理分配计算资源、优化功耗，并避免外设冲突。
核心处理器与存储
ESP32搭载两个Xtensa LX6微处理器核心，主频最高240MHz。在典型应用中，一个核心负责无线协议栈（BLE/Wi-Fi）和网络任务，另一个核心运行传感器数据采集与AI推理算法。这种双核分工模式能有效避免无线通信阻塞导致的数据丢失。芯片内置520KB SRAM和8KB RTC存储器，外部可连接Flash（通常4MB~16MB）用于存储固件和模型参数。
外设接口与传感器接入
ESP32提供丰富的外设接口，包括：
- I2C：连接温湿度传感器（如SHT30）、气压计（BMP280）等低速设备
- SPI：连接高速传感器（如IMU MPU9250）或外部Flash
- UART：连接GPS模块、调试串口
- ADC：采集模拟信号（如电池电压、光敏电阻）
- DAC/I2S：音频输出或波形生成
在边缘AI场景中，传感器数据通过上述接口进入ESP32，经过预处理（滤波、归一化）后送入AI模型进行推理。推理结果可以通过BLE发送至手机或云端。
2.2 BLE协议栈：分层架构与数据流
BLE协议栈采用分层设计，每一层负责特定的功能，层与层之间通过标准接口通信。理解协议栈的分层结构，有助于定位通信问题并优化数据传输效率。
| 协议层 | 功能 | 关键点 |
|---|---|---|
| 物理层 (PHY) | 2.4GHz射频收发，1Mbps/2Mbps | 调制方式GFSK，发射功率可调 |
| 链路层 (LL) | 数据包封装、重传、加密 | 连接事件、跳频、白名单 |
| HCI | 主机与控制器之间的接口 | 在ESP32中为内部接口 |
| L2CAP | 数据封装、多路复用 | MTU协商（默认23字节，可扩展） |
| ATT | 属性协议，定义数据读写规则 | 句柄、UUID、读写/通知操作 |
| GATT | 服务与特征值的组织框架 | 服务、特征、描述符的层级结构 |
| GAP | 设备发现、连接管理 | 广播、扫描、连接参数 |
BLE协议栈在ESP32中的实现
ESP32使用Bluedroid（经典蓝牙+BLE）或NimBLE（轻量级BLE）协议栈。对于边缘AI应用，推荐使用NimBLE，因为它占用资源更少（约50KB RAM），启动更快，且支持最新的BLE 5.0特性。NimBLE提供了简洁的API，支持广播、扫描、GATT Server/Client等完整功能。
// NimBLE 初始化示例（ESP-IDF框架）
#include "nimble/nimble_port.h"
#include "nimble/nimble_port_freertos.h"
void ble_init(void) {
nimble_port_init();
// 配置GAP服务
ble_svc_gap_init();
// 配置GATT服务
ble_svc_gatt_init();
// 启动BLE
nimble_port_freertos_init(host_task);
}2.3 GATT与GAP：BLE应用的核心协议
GAP（Generic Access Profile）和GATT（Generic Attribute Profile）是BLE应用开发中最常接触的两个协议层。GAP负责设备如何被发现和连接，GATT负责连接建立后如何组织和交换数据。
GAP：设备发现与连接管理
GAP定义了设备角色：广播者（Broadcaster）、观察者（Observer）、外围设备（Peripheral）和中心设备（Central）。在ESP32边缘AI场景中，ESP32通常作为Peripheral（从机）广播数据，手机作为Central（主机）扫描并连接。
- 广播数据：包含设备名称、服务UUID、厂商自定义数据。广播间隔通常为20ms~10.24s，间隔越短发现越快但功耗越高。
- 连接参数：连接间隔（7.5ms~4s）、从机延迟（0~499）、超时时间。合理的参数设置可以平衡功耗与实时性。
- 安全模式：支持无安全、加密、配对等模式。对于传感器数据，通常使用加密连接防止数据被窃听。
GATT：数据组织与交互
GATT采用层级结构组织数据：服务（Service）→ 特征（Characteristic）→ 描述符（Descriptor）。每个特征包含值（Value）和属性（Properties），属性决定了该特征支持的操作（读、写、通知、指示）。
| GATT元素 | 示例 | 说明 |
|---|---|---|
| 服务 (Service) | 0x180D (心率服务) | 一组相关特征的集合 |
| 特征 (Characteristic) | 0x2A37 (心率测量) | 包含实际数据值 |
| 描述符 (Descriptor) | 0x2902 (客户端特征配置) | 控制通知/指示的开关 |
2.4 BLE在物联网中的角色与选型考量
BLE在物联网生态中占据独特地位，它填补了Wi-Fi（高功耗、高带宽）和Zigbee（需要网关）之间的空白。对于边缘AI应用，BLE的优势在于：
- 低功耗：峰值电流约15mA，平均功耗可低至µA级，适合电池供电设备
- 手机直连：无需网关，手机原生支持BLE，降低部署成本
- 足够带宽：2Mbps物理层速率，实际吞吐量约1.4Mbps，足以传输传感器数据和推理结果
- 拓扑灵活：支持一对多广播、星型连接、Mesh网络（BLE 5.0+）
BLE与其他无线技术的对比
| 技术 | 功耗 | 速率 | 传输距离 | 适用场景 |
|---|---|---|---|---|
| BLE | 极低 | 1-2 Mbps | 10-100m | 可穿戴、传感器、手机交互 |
| Wi-Fi | 高 | 50-200 Mbps | 50-100m | 视频流、大文件传输 |
| Zigbee | 低 | 250 Kbps | 10-100m | 智能家居Mesh网络 |
| LoRa | 极低 | 0.3-50 Kbps | 1-10km | 远距离、低速率传感 |
2.5 案例拆解：BLE环境监测节点的设计与实现
以一个典型的BLE边缘AI应用为例——智能温湿度监测节点，该节点部署在数据中心机房，每5秒采集一次温湿度数据，在本地进行异常检测（边缘AI推理），并通过BLE将数据与告警信息发送至运维人员的手机。
系统架构与硬件选型
- 主控：ESP32-WROOM-32E（双核、4MB Flash）
- 传感器：SHT30（I2C接口，精度±0.2°C / ±2%RH）
- 电源：3.7V锂电池 + 低功耗LDO（RT9013）
- 天线：PCB天线，增益2dBi
软件设计要点
// GATT服务定义（简化）
static const ble_uuid128_t gatt_svc_env_uuid =
BLE_UUID128_INIT(0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08,
0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10);
// 温度特征：Notify属性
static const ble_uuid128_t gatt_chr_temp_uuid =
BLE_UUID128_INIT(0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18,
0x19, 0x1A, 0x1B, 0x1C, 0x1D, 0x1E, 0x1F, 0x20);
// 湿度特征：Notify属性
static const ble_uuid128_t gatt_chr_humi_uuid =
BLE_UUID128_INIT(0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28,
0x29, 0x2A, 0x2B, 0x2C, 0x2D, 0x2E, 0x2F, 0x30);
// 告警特征：Read + Notify
static const ble_uuid128_t gatt_chr_alarm_uuid =
BLE_UUID128_INIT(0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38,
0x39, 0x3A, 0x3B, 0x3C, 0x3D, 0x3E, 0x3F, 0x40);关键参数配置与调试过程
在调试过程中，我们遇到了两个典型问题：
- 广播数据被手机扫描不到：原因是广播间隔设置过短（20ms），导致射频拥塞。调整为100ms后解决。
- 数据传输延迟高：连接间隔设置为100ms，导致数据通知延迟。通过将连接间隔调整为30ms，延迟从100ms降至30ms，但功耗增加了约15%。
性能测试结果
| 指标 | 实测值 | 说明 |
|---|---|---|
| 待机电流 | 12 µA | 深度睡眠模式，RTC定时唤醒 |
| 工作电流 | 28 mA | 传感器采集 + BLE广播 + AI推理 |
| 数据传输延迟 | 30 ms | 从传感器采样到手机收到通知 |
| 电池续航 | 约45天 | 1000mAh锂电池，5秒采集周期 |
复盘与经验总结
2.6 常见误区与设计建议
在ESP32 BLE开发中，开发者常陷入以下误区：
- 误区一：广播数据越大越好。广播包最大31字节，超过后需要扩展广播（BLE 5.0）。建议只广播必要信息（设备名、服务UUID），详细数据通过连接后读取。
- 误区二：所有数据都用Notify。Notify需要手机端使能CCCD（0x2902描述符），且频繁通知会增加功耗。对于低频数据（如每分钟一次），使用Read更合适。
- 误区三：忽略MTU协商。默认MTU为23字节，实际有效数据仅20字节。通过协商MTU至247字节，可显著提升大包传输效率。
- 误区四：不处理连接断开。BLE连接可能因距离、干扰等原因断开，需要实现自动重连机制，并考虑断线期间的数据缓存。