定时唤醒功能执行周期任务-优快云博客

定时唤醒功能执行周期任务：嵌入式系统中低功耗与实时性的协同设计

你有没有遇到过这样的场景？一个小小的温湿度传感器，装在森林深处、农田角落，没人维护、不通市电，却要连续工作好几年。它每天只“醒”几十毫秒，采集一次数据，发个无线信号，然后又沉沉睡去——像一只电子冬眠的熊 🐻。

这背后靠的不是魔法，而是 定时唤醒 + 周期任务 这套精妙的低功耗设计逻辑。今天我们就来拆解这个“节能秘籍”，看看嵌入式系统是如何在 超低功耗 和 准时响应 之间走钢丝的 ⚖️。

RTC：那个永远在线的“小闹钟”

实时时钟（RTC）可能是MCU里最不起眼但最关键的模块之一。它不参与主运算，也不驱动外设，只是默默地数着秒、分、时、日……哪怕整个系统都断电了，只要VBAT还有一口气，它就能继续走。

💡 想象一下：主CPU是公司CEO，平时高薪养着，能耗巨大；而RTC就像那个24小时值班的前台保安，工资极低，但从不迟到早退。你需要开会时，他准时打个电话把你叫醒 —— 这就是RTC闹钟的本质。

为什么非得用RTC？

普通定时器依赖主时钟，一旦进入Stop或Standby模式，主时钟停摆，定时器也就“死机”了。而RTC由32.768kHz晶振独立驱动，功耗可以低到 1μA以下 ，月误差不到1秒（配合温补晶振甚至可达±2ppm），简直是为长期值守量身定做的。

来看看典型的RTC唤醒流程：

// 设置10分钟后唤醒
void schedule_next_wakeup(uint32_t delay_seconds) {
    RTC_AlarmTypeDef alarm = {0};
    RTC_TimeTypeDef time;
    HAL_RTC_GetTime(&hrtc, &time, RTC_FORMAT_BIN);

    uint32_t total_sec = time.Seconds + time.Minutes*60 + time.Hours*3600 + delay_seconds;

    alarm.AlarmTime.Seconds   = total_sec % 60;
    alarm.AlarmTime.Minutes   = (total_sec / 60) % 60;
    alarm.AlarmTime.Hours     = (total_sec / 3600) % 24;
    alarm.AlarmMask           = RTC_ALARMMASK_DATEWEEKDAY; // 不关心日期
    alarm.Alarm               = RTC_ALARM_A;

    HAL_RTC_SetAlarm_IT(&hrtc, &alarm, RTC_FORMAT_BIN);
}

这段代码干了啥？
👉 计算当前时间+10分钟后的具体时刻
👉 配置RTC闹钟中断
👉 然后放心大胆地让MCU睡觉去吧 💤

等到时间一到，RTC就会拉响警报，把MCU从深度睡眠中拽出来干活。整个过程就像设定手机闹钟起床一样自然。

✅ 小贴士：如果你的应用需要保持上下文（比如缓存未发送的数据），记得别进 Standby模式 ！那玩意儿会清空SRAM，相当于“完全重启”。推荐使用 Stop模式 + RTC唤醒 ，既能省电又能保留内存状态。

WDT也能当“闹钟”？没错，而且还不贵！

说到看门狗定时器（WDT），大家第一反应是“防死机复位”。但你知道吗？有些MCU的WDT其实是个隐藏的“周期唤醒神器” 😎。

比如TI的MSP430、NXP的Kinetis系列，它们的独立看门狗支持一种“中断模式”：计数溢出时不复位，而是触发一个中断。这样我们就可以把它当成一个粗糙但够用的定时器来用了。

WDT vs RTC：谁更适合你？

特性	RTC	WDT
功耗	~1μA	~1.5μA
精度	±2~20 ppm（极高）	±10%~20%（较低）
可调周期	秒级任意设置	固定档位（如1s、2s）
外围电路	需32.768kHz晶振	内部RC，无需外部元件
成本	略高	极低成本

所以问题来了：什么时候该用WDT？

举个例子🌰：你做一个空气质量检测仪，每分钟读一次PM2.5传感器，允许±5秒偏差。这种对精度要求不高、追求极致成本控制的项目，WDT反而比RTC更合适！

毕竟，少一颗晶振，PCB面积小一点，BOM成本降一点，量产就是几十万的成本差异啊 💸。

不过要注意⚠️：每次唤醒后必须“喂狗”（重载计数值），否则WDT以为你程序卡死了，真给你来个复位……那就尴尬了。

// 使用WDT作为周期唤醒源（伪代码）
void enter_sleep_with_wdt(uint32_t period_ms) {
    configure_iwdg_interrupt_mode(period_ms);  // 设为中断模式
    enable_iwdg_wakeup();                      // 允许唤醒
    __disable_irq();
    HAL_PWR_EnterSTOPMode(PWR_LOWPOWERREGULATOR_ON, PWR_STOPENTRY_WFI);
}

ISR里记得及时reload，不然下次就不是唤醒，是重启啦！

深度睡眠模式怎么选？Stop还是Standby？

现代MCU通常提供多级低功耗模式，选择合适的“睡姿”至关重要。下面这张表你应该烂熟于心：

模式	功耗水平	是否保留SRAM	唤醒源	恢复时间
Run	高	是	-	-
Sleep	中	是	任意中断	<1μs
Stop	低	是	EXTI、RTC、WDT等	~10–100μs
Standby	极低	否	RTC Alarm、Reset引脚	~1–5ms

看到没？ Standby模式虽然最省电（可低至100nA） ，但它会清除所有寄存器和SRAM内容，相当于系统彻底关机再开机。如果你有重要状态要保存，就得用 Stop模式 ，牺牲一点点功耗换来上下文完整。

以STM32L4为例，进入Stop模式并由RTC唤醒的标准流程如下：

void enter_stop_with_rtc(uint32_t seconds) {
    schedule_next_wakeup(seconds);                    // 设置RTC闹钟
    __HAL_RCC_PWR_CLK_ENABLE();                       // 使能电源控制
    HAL_PWR_EnterSTOPMode(PWR_LOWPOWERREGULATOR_ON, PWR_STOPENTRY_WFI);
    // 唤醒后从此处继续执行
    SystemClock_Config();                             // 重新配置系统时钟
}

关键点提醒 🔔：
- 唤醒后需重新初始化系统时钟（HSE/HSI等）
- 外设可能也需要重新使能
- 若使用DMA或复杂通信协议，建议在任务结束后做一次轻量级状态检查

实战案例：一个LoRa温湿度节点的设计心法

假设我们要做一个基于STM32L073RZ的无线传感节点，用CR2032纽扣电池供电，目标是每10分钟上报一次温湿度，续航至少1年。

硬件架构大概是这样：

[STM32L0] 
   ├── [SHT30] 温湿度传感器
   ├── [LoRa模块] 如SX1276
   ├── [内置RTC] 32.768kHz晶振驱动
   └── [CR2032] 3V电池

工作节奏是怎么安排的？

上电 → 初始化RTC、传感器、LoRa
设置RTC闹钟：当前时间 + 600秒
关闭ADC、GPIO时钟，关闭SHT30电源（通过MOSFET控制）
进入Stop模式，仅RTC和备份域运行
10分钟后，RTC中断唤醒MCU
开启SHT30供电，读取数据，通过LoRa发送
发送完成 → 关闭LoRa射频 → 再次进入睡眠

整个活跃时间控制在 80ms以内 ，其余599.92秒都在睡觉 😴。

我们来算笔账：

睡眠电流：1.8 μA
工作电流：12 mA × 0.08 s = 0.96 mC/次
每天唤醒次数：144次
日均电荷消耗：1.8μA×86400s + 144×0.96mC ≈ 0.155 C/day
电池容量：225mAh ≈ 810 C
理论续航：810 / 0.155 ≈ 5.2年

哇哦！是不是有点惊喜？🎉
当然实际会有损耗，比如电池自放电、焊接漏电、LoRa传输失败重试等，但做到2~3年完全没有问题。

老工程师不会告诉你的那些坑 🕳️

再完美的设计也逃不过现实的毒打。我在调试这类系统时踩过的坑，现在都告诉你：

❌ 时间越走越慢？晶振漂移惹的祸！

即使标称±20ppm的晶振，长期运行也会累积误差。比如每月差5分钟，一年下来就快1小时了！解决办法：

✅ 定期校准RTC ：如果设备能联网（如LoRaWAN），可以从网络服务器获取UTC时间进行同步。
✅ 软件补偿机制 ：记录历史唤醒间隔，动态调整下一次延时值。

❌ 唤醒了却没干活？中断优先级搞错了！

有时候发现MCU确实被唤醒了，但任务没执行。查了半天才发现： SysTick中断优先级太高 ，或者 RTC中断被其他外设抢占了 。

🔧 解决方案：统一管理中断优先级，确保RTC唤醒后能顺利进入任务调度。

❌ 数据丢了怎么办？加一层“最后执行时间”保险

为了防止意外重启导致任务重复或跳过，可以在备份寄存器（Backup Register）里存一个 last_exec_time 。每次唤醒先读一下，判断是否真的到了该执行的时间。

uint32_t last_time = READ_REG(RTC->BKP0R);  // 从备份寄存器读
uint32_t now = get_current_epoch();

if (now - last_time >= 600) {
    execute_task();
    WRITE_REG(RTC->BKP0R, now);  // 更新最后执行时间
}

这招特别适合怕重复上报的场景，比如远程抄表系统。

设计 checklist：上线前必看 ✅

项目	是否完成
✅ RTC闹钟设置正确，支持周期唤醒	☐ / ✔️
✅ 使用Stop而非Standby以保留SRAM	☐ / ✔️
✅ 所有未使用外设时钟已关闭	☐ / ✔️
✅ 传感器和无线模块电源可控	☐ / ✔️
✅ 活跃时间 < 100ms	☐ / ✔️
✅ 添加软件看门狗防死锁	☐ / ✔️
✅ 支持远程时间同步机制	☐ / ✔️
✅ 开发阶段可通过串口输出调试信息	☐ / ✔️

📌 提示：开发时可以用宏开关控制是否启用深度睡眠：

#ifdef DEBUG_NO_DEEP_SLEEP
    while(1) {
        execute_task();
        HAL_Delay(600000);  // 直接延时模拟周期
    }
#else
    enter_stop_with_rtc(600);
#endif

方便调试又不影响最终版本。