4、Deep Sleep原理：ESP32的睡眠模式（Modem Sleep、Light Sleep、Deep Sleep）区别与适用场景

在低功耗物联网终端的设计中，电池寿命往往直接决定产品的可用性与维护成本。ESP32 作为一颗集成 Wi-Fi/BLE 的 SoC，其默认运行功耗在 100mA 级别（Wi-Fi 开启时瞬时可达 240mA 以上），如果持续满负荷工作，普通 18650 电池也只能支撑数天。因此，理解并正确运用 ESP32 的多种睡眠模式，是低功耗联网 AI 应用（如周期唤醒传感器节点、电池供电的语音唤醒设备）的必修课。本章将深入剖析 Modem Sleep、Light Sleep 与 Deep Sleep 三种模式的硬件行为、功耗差异、唤醒机制及适用场景，并给出选型判断流程与实战案例。

上图展示了三种睡眠模式在功耗、唤醒延迟与适用场景上的核心差异。从工程角度看，选择哪种模式并非越省电越好，而是需要在响应速度、外设保留、数据保持与功耗之间做权衡。下面我们从硬件原理出发，逐一拆解。

4.1 核心原理：三种睡眠模式的硬件行为差异

ESP32 的电源管理由 RTC（Real-Time Clock）域和 数字内核域两部分组成。RTC 域始终由 RTC 电源供电（Deep Sleep 时依然工作），包含 RTC 定时器、ULP 协处理器、RTC 内存（8KB 快速 + 8KB 慢速）以及部分唤醒控制逻辑。数字内核域则包含 CPU、Wi-Fi/BT 基带、大部分 SRAM 和数字外设。三种睡眠模式本质上是“数字内核域”和“Wi-Fi/BT 射频前端”的断电/降频组合。

• Modem Sleep（调制解调器睡眠）：CPU 保持运行，仅关闭 Wi-Fi/BT 射频前端与基带时钟。此时系统仍可执行用户代码，但无法收发无线数据。电流约 15-30mA（取决于 CPU 频率与 Flash 访问）。该模式通常配合 esp_wifi_set_ps(WIFI_PS_MIN_MODEM) 使用，适用于需要保持 Wi-Fi 连接但数据流量极低的场景（如 TCP 长连接心跳）。
• Light Sleep（浅睡眠）：CPU 暂停执行，数字外设时钟可关闭，但 RTC 域与主内存（部分）保持供电。电流降至 0.8-2mA。唤醒后 CPU 从暂停点继续执行，无需重新初始化系统。该模式适合需要频繁唤醒（毫秒级响应）且对功耗要求中等的场景，例如按键唤醒的交互设备。
• Deep Sleep（深度睡眠）：数字内核域几乎完全断电，CPU、大部分 SRAM、Flash 均停止工作，仅保留 RTC 域（RTC 定时器、ULP 协处理器、RTC 内存）。电流可低至 5-10μA（使用 ULP 协处理器时约 5μA，纯定时器唤醒约 10μA）。唤醒后系统从 esp_sleep_wakeup_cause() 判断原因，重新执行 app_main()。这是电池供电周期推理设备的首选。

对比维度	Modem Sleep	Light Sleep	Deep Sleep
CPU 状态	运行	暂停	断电
Wi-Fi/BT 射频	关闭	可关闭	断电
典型电流	15-30 mA	0.8-2 mA	5-10 μA
唤醒延迟	微秒级	100-300 μs	1-3 ms
RAM 保持	全部保持	全部保持	仅 RTC 内存 (16KB)
唤醒源	定时器/中断	定时器/GPIO/UART	定时器/GPIO/ULP/Touch
代码恢复方式	继续执行	继续执行	重新启动 app_main()

4.2 判断方法：如何选择适合的睡眠模式

选择睡眠模式不能只看功耗数字，需要结合唤醒频率、数据保留需求、外设工作状态和启动延迟四个维度进行判断。以下是一个实用的决策流程：

1. 评估唤醒频率：如果唤醒间隔小于 10ms（如高频传感器采样），只能使用 Modem Sleep 或 Light Sleep，因为 Deep Sleep 的 1-3ms 启动时间会占据大部分周期。
2. 检查外设需求：如果需要在睡眠期间保持 UART 接收、I2C 从机或 ADC 连续采样，Light Sleep 是底线（Deep Sleep 下这些外设全部断电）。
3. 确认数据保持范围：如果需要在唤醒后快速访问大量数据（如神经网络权重），必须使用 Light Sleep（RAM 保持）或从 Flash 重新加载。Deep Sleep 只能保留 RTC 内存中的 16KB 数据。
4. 计算平均功耗：使用公式 平均功耗 = (睡眠电流 × 睡眠时间 + 唤醒电流 × 唤醒时间) / 总周期。例如，一个 10 秒周期的传感器节点，Deep Sleep 10μA 睡眠 9.9s + 80mA 唤醒 100ms，平均功耗约 0.8mA；而 Light Sleep 2mA 睡眠 9.9s + 80mA 唤醒 100ms，平均功耗约 2.8mA。差距显著。

4.3 案例拆解：电池供电的温湿度周期上报节点

我们设计一个实际项目：使用 ESP32 读取 SHT30 温湿度传感器，每 15 分钟通过 Wi-Fi 上报一次数据到云端，使用 1000mAh 锂电池供电，目标续航超过 6 个月。

初始方案与问题：工程师最初使用 Light Sleep，睡眠电流 1.5mA，唤醒后连接 Wi-Fi 发送数据耗时 2 秒（平均电流 120mA）。计算平均功耗：(1.5mA × 898s + 120mA × 2s) / 900s ≈ 1.76mA。1000mAh 电池理论续航约 568 小时（23.7 天），远不达标。

分析过程：问题在于 Light Sleep 的 1.5mA 基础电流在 15 分钟周期内占比过高。改用 Deep Sleep 后，睡眠电流降至 10μA（RTC 定时器唤醒），但需要解决两个问题：一是唤醒后 Wi-Fi 连接需要重新初始化（增加耗时），二是传感器数据需要保存在 RTC 内存中。

优化后方案：

// 进入 Deep Sleep 前保存数据到 RTC 内存
RTC_DATA_ATTR float last_temp;
RTC_DATA_ATTR float last_humidity;
RTC_DATA_ATTR int boot_count;

void app_main() {
    // 检查唤醒原因
    esp_sleep_wakeup_cause_t cause = esp_sleep_get_wakeup_cause();
    if (cause != ESP_SLEEP_WAKEUP_TIMER) {
        // 首次启动，初始化传感器
        sht30_init();
    }
    // 读取传感器
    sht30_read(&last_temp, &last_humidity);
    // 连接 Wi-Fi 并上报
    wifi_connect_and_send(last_temp, last_humidity);
    // 设置定时器 15 分钟
    esp_sleep_enable_timer_wakeup(15 * 60 * 1000000ULL);
    esp_deep_sleep_start();
}

结果对比：Deep Sleep 方案中，睡眠电流 10μA，唤醒后 Wi-Fi 连接 + 上报耗时 2.5 秒（平均电流 130mA）。平均功耗：(0.01mA × 897.5s + 130mA × 2.5s) / 900s ≈ 0.36mA。1000mAh 电池理论续航约 2777 小时（115.7 天），接近 4 个月。进一步优化（如使用 ULP 协处理器在睡眠期间预采样、减少 Wi-Fi 连接时间）可将续航提升至 6 个月以上。

4.4 常见误区与总结复盘

在实际项目中，工程师常犯以下错误：

• 误区一：所有场景都用 Deep Sleep。如果唤醒间隔短（<100ms），Deep Sleep 的启动时间反而会消耗更多能量。例如，10ms 唤醒一次，Deep Sleep 启动 2ms + 工作 8ms，平均功耗远高于 Light Sleep。
• 误区二：忽略 RTC 内存的 16KB 限制。当需要保存的数据超过 16KB 时，必须使用 NVS 或 Flash，这会增加写入功耗和延迟。
• 误区三：未关闭不必要的 RTC 外设。Deep Sleep 下，如果 ULP 协处理器未使用，应通过 esp_sleep_pd_config(ESP_PD_DOMAIN_RTC_SLOW_MEM, ESP_PD_OPTION_OFF) 关闭慢速内存以降低漏电流。
• 误区四：忽视 GPIO 上拉电阻的漏电。在 Deep Sleep 中，外部 GPIO 的上拉/下拉电阻可能产生额外电流。建议将未使用的 GPIO 配置为 GPIO_MODE_DISABLE 或设置为高阻态。