📚 课程目录第1章课程导入

1. 课程导入

ESP32 之所以成为物联网终端的主力芯片，很大程度上得益于它把 Wi-Fi 与 Bluetooth LE 两套射频系统集成在同一颗芯片上。但“集成”并不等于“互不干扰”：Wi-Fi 与 BLE 共享 2.4 GHz 频段、共享射频前端与天线，还要在有限的功耗预算和实时性约束下轮流占用空中接口。因此，共存工程不是简单的“打开两个协议栈”，而是一套围绕时间、频率、功率、优先级和资源调度的系统设计方法。

本课程的目标，是让你从“能连上”进阶到“连得稳、切得快、耗得省”。学完之后，你应当能够独立完成 Wi-Fi 与 BLE 共存场景的方案设计、参数配置、性能测量与问题定位，而不是依赖试错。

一、学习目标：从会用走向可控

本课程围绕四个层次设定目标，层层递进：

认知层：理解 Wi-Fi 与 BLE 在 2.4 GHz 频段的信道分布、调制方式、占空比特征，以及它们为何会互相阻塞。
配置层：掌握 ESP-IDF 中软件共存（Software Coexistence）的使能方式、优先级策略、时间片参数与任务绑定。
测量层：能用日志、示波器、频谱仪和吞吐测试工具量化共存性能，例如 Wi-Fi 吞吐、BLE 连接间隔抖动、丢包率。
优化层：能针对具体业务（如 BLE 配网 + Wi-Fi 上云、BLE 传感器 + Wi-Fi 网关）做参数取舍与架构拆分。

核心判断标准：共存方案是否合格，不看“两个协议是否同时在线”，而看关键业务的时延、吞吐与功耗是否同时满足指标。

二、核心挑战：三组矛盾决定设计难度

ESP32 的共存问题可以归纳为三组根本矛盾，理解它们比记住 API 更重要。

第一，时间资源矛盾。 射频前端同一时刻只能服务一个协议。Wi-Fi 需要按 Beacon、ACK、重传等时序抢占信道，BLE 则依赖固定的连接事件（Connection Event）和广播间隔。两者时间窗口一旦重叠，就必须由共存仲裁器决定谁先使用射频。

第二，频率资源矛盾。 Wi-Fi 常用信道 1～13，BLE 广播占用 37、38、39 三个信道，数据信道分布在 0～36。Wi-Fi 的 20 MHz 带宽会覆盖多个 BLE 信道，造成带内干扰。选择 Wi-Fi 信道与 BLE 信道映射，是降低冲突的第一手段。

第三，功耗与实时性矛盾。 BLE 追求低占空比和长休眠，Wi-Fi 追求高吞吐和低时延。Modem-sleep、Light-sleep 与 Wi-Fi DTIM 策略会直接影响 BLE 连接事件的准时性。若 BLE 连接间隔设为 7.5 ms，而 Wi-Fi 正在突发传输，BLE 主从设备就可能错过事件而触发监督超时。

三、整体知识框架：四层结构

上图给出了本课程的知识框架，可以概括为四层：射频与协议基础层负责解释“为什么会冲突”；共存机制与配置层负责回答“用什么手段协调”；测量与调优层负责判断“当前方案好不好”；工程落地层负责把方法固化为可量产的产品行为。

四层之间不是并列关系，而是逐层支撑。跳过基础层直接抄配置，往往在换场景后失效；只做测量不做配置，则无法收敛问题。建议学习时始终带着一个具体业务场景，把每层知识映射到自己的产品上。

四、典型场景与参数取舍

下面这张清单列出了三类常见业务及其共存关注点，可作为你选择学习重点的参照。

业务场景	Wi-Fi 角色	BLE 角色	首要指标	关键取舍
BLE 配网 + Wi-Fi 上云	STA 连接路由器	GATT 服务端配网	配网成功率、上云时延	配网阶段优先 BLE，上云阶段优先 Wi-Fi
BLE 传感器 + Wi-Fi 网关	SoftAP 或 STA 回传	Central 扫描/连接	BLE 连接稳定性、Wi-Fi 吞吐	增大 BLE 连接间隔，避开 Wi-Fi 突发窗口
低功耗标签	偶发上报	广播/连接	平均功耗、唤醒时延	用 Modem-sleep 与 DTIM 平衡功耗和响应

五、常见误区与复盘要点

误区一：认为“共存开关打开就万事大吉”。软件共存只提供仲裁框架，具体时间片、优先级和信道仍需按业务配置。

误区二：只测 Wi-Fi 吞吐，不看 BLE 连接事件抖动。很多现场问题表现为 BLE 掉线，根因却是 Wi-Fi 突发占满射频。

误区三：把 Wi-Fi 信道固定在 1 或 11 就以为避开了 BLE。实际上 Wi-Fi 20 MHz 带宽仍会覆盖多个 BLE 数据信道，需要结合信道映射表分析。

复盘时建议固定记录四项数据：Wi-Fi 信道与带宽、BLE 连接间隔与从机延迟、共存优先级配置、测试时的并发业务类型。缺少任何一项，问题都难以复现和归因。

六、一个最小可运行的配置起点

在 ESP-IDF 中，共存能力通常通过 menuconfig 使能，并在初始化顺序上保证 Wi-Fi 与 BLE 控制器正确协作。下面是一个典型的配置与初始化片段，作为本课程的起点：

idf.py menuconfig

Component config → Wi-Fi →
  [*] Software Coexistence
  [*] Wi-Fi NVS Flash

Component config → Bluetooth →
  [*] Bluetooth
  [*] Bluetooth controller
      Bluetooth controller mode → BLE only

// 初始化顺序建议
esp_netif_init();
esp_event_loop_create_default();
nvs_flash_init();

// 先初始化 Wi-Fi 控制器，再启动 BLE 控制器
esp_wifi_init(&wifi_cfg);
esp_wifi_set_mode(WIFI_MODE_STA);
esp_wifi_start();

esp_bt_controller_init(&bt_cfg);
esp_bt_controller_enable(ESP_BT_MODE_BLE);
esp_bluedroid_init();
esp_bluedroid_enable();

初始化顺序、任务优先级和内存分配会直接影响共存稳定性。建议在项目早期就固定这套顺序，并在后续章节中逐步加入优先级与时间片调优。

从这一节开始，你需要的不是记住所有 API，而是建立一套判断框架：先看业务指标，再看时间与频率资源，最后才落到具体参数。接下来的章节会沿着这条路线，逐层展开射频基础、共存配置、测量方法与工程案例，帮助你把 ESP32 的双射频能力真正用稳、用好。