📚 课程目录第3章 RTOS任务调度与功耗

3. RTOS任务调度与功耗：空闲任务、Tickless模式原理

说到RTOS和低功耗，很多人第一反应是「选个低功耗MCU就完事了」。其实不然。我见过太多项目，芯片选的是顶尖的低功耗型号，结果跑起来电流还是居高不下。问题出在哪？多半是任务调度没处理好。

今天我们就来聊聊RTOS里两个跟功耗最相关的机制——空闲任务和Tickless模式。搞懂了它们，你的系统才能真正「该睡就睡，该醒就醒」。

3.1 空闲任务：系统的「喘息时间」

先问一个问题：当你的RTOS里所有任务都在等待事件、没有活干的时候，CPU在干嘛？

答案是——它在跑空闲任务（Idle Task）。

空闲任务是RTOS自动创建的、优先级最低的任务。只要没有其他任务就绪，调度器就会切到空闲任务。说白了，它就是系统的「兜底线程」。

关键认知：空闲任务不是「浪费CPU」，而是系统唯一可以安全进入低功耗模式的时机。

我早期做的一个物联网网关项目，刚开始没重视空闲任务，直接让它空转。结果整机功耗比预期高了3倍。后来我在空闲任务里插入了WFI指令，功耗直接降到了原来的1/5。你想想看，这差距有多大。

3.1.1 空闲任务的典型实现

以FreeRTOS为例，空闲任务的钩子函数（Idle Hook）是植入低功耗逻辑的标准位置：

void vApplicationIdleHook(void)
{
    /* 进入休眠前，确保没有中断挂起 */
    __disable_irq();
    
    /* 检查是否有任务需要唤醒 */
    if (eTaskConfirmSleepModeStatus() == eAbortSleep)
    {
        __enable_irq();
        return;
    }
    
    /* 进入WFI休眠 */
    __WFI();
    
    __enable_irq();
}

这段代码看起来简单，但有几个坑要注意：

关中断的时机：必须在检查任务状态之前关中断，防止检查完到WFI之间被中断打断
eTaskConfirmSleepModeStatus：这个API会告诉你「现在能不能睡」，如果刚好有任务被唤醒，它会返回abort
WFI vs WFE：WFI（Wait For Interrupt）更常用，但WFE在某些场景下唤醒延迟更低

我曾经踩过的坑：有一次在空闲任务里直接调了WFI，没做中断检查。结果系统进入休眠后，定时器中断来了，但CPU没及时响应，导致一个关键任务超时。从那以后，我每次写空闲任务都会加三层检查——中断状态、任务就绪队列、以及一个超时看门狗。

3.2 Tickless模式：打破固定心跳的束缚

传统的RTOS都有一个固定周期的系统滴答（SysTick），比如1ms一次。每次滴答都会触发一次上下文切换或者时间片轮转。这在实时性要求高的场景下没问题，但你想过没有——如果系统99%的时间都在空闲，这1ms一次的滴答就是巨大的浪费。

Tickless模式就是来解决这个问题的。它的核心思想是：没有任务需要调度的时候，停止周期性滴答，让CPU深度休眠，直到下一个任务需要被唤醒的时刻。

我的个人习惯：在电池供电的产品里，我几乎必开Tickless模式。但要注意，Tickless不是万能药——如果系统里有很多短周期任务（比如1ms的PWM控制），Tickless反而会因为频繁进出休眠而增加功耗。

3.2.1 Tickless的工作原理

咱们用一张图来理解：

从图上可以看得很清楚：传统模式下，CPU被频繁唤醒，即使没有实际工作要做；而Tickless模式下，CPU只在任务到期时醒来，其余时间都在深度休眠。

3.2.2 时间补偿机制

Tickless模式有个绕不开的问题——时间漂移。因为系统在休眠期间不响应滴答中断，所以RTOS的软件定时器、任务延时都会「走慢」。

解决办法是时间补偿。每次从休眠醒来时，计算实际休眠时间，然后一次性补偿给系统时钟：

void Tickless_ExitSleep(uint32_t sleep_ticks)
{
    /* 补偿系统滴答计数 */
    xTaskIncrementTick(sleep_ticks);
    
    /* 检查是否有定时器到期 */
    if (sleep_ticks > 0)
    {
        /* 处理所有到期的软件定时器 */
        vTimerUpdateExpired(sleep_ticks);
    }
    
    /* 重新计算下一次休眠时间 */
    uint32_t next_wake = GetNextTaskWakeupTime();
    SetWakeupTimer(next_wake);
}

注意：时间补偿不是简单的累加。如果休眠期间有多个定时器到期，你需要一次性处理完所有到期事件，否则会出现「定时器丢事件」的bug。我见过一个项目，就是因为补偿逻辑没处理好，导致一个周期性的传感器采集任务每隔几次就漏掉一次。

3.3 空闲任务与Tickless的协同工作

这两个机制不是孤立的。实际项目中，它们通常这样配合：

场景	空闲任务行为	Tickless行为	功耗效果
所有任务阻塞等待	进入WFI/WFE	停止SysTick，进入深度休眠	μA级
有短周期任务（<1ms）	几乎不进入空闲	建议关闭Tickless	mA级（无法深度休眠）
混合周期任务	空闲时进入浅休眠	根据最长空闲时间决定是否深度休眠	动态调节
中断频繁触发	空闲任务被频繁抢占	Tickless效果有限	取决于中断频率

从表格里能看出来，Tickless模式最适合「任务少、空闲时间长」的场景。如果你的系统里全是1ms周期的控制任务，那Tickless反而会成为负担——每次进出深度休眠的延迟可能比任务本身还长。

3.4 实际项目中的配置建议

说了这么多理论，咱们来点实际的。我总结了几条经验：

先测量，再优化：不要一上来就开Tickless。先用示波器或者电流分析仪测出系统的实际空闲时间分布，再决定是否启用。
空闲任务里不要做复杂操作：空闲任务应该只做两件事——检查能否休眠、执行休眠。不要在空闲任务里做日志、统计、数据清理等操作，这些会阻止系统进入深度休眠。
Tickless的唤醒源要可靠：常用的唤醒源有RTC、外部中断、定时器。我建议至少保留两个唤醒源——一个用于周期性任务，一个用于紧急事件。
注意调试时的功耗陷阱：调试器（如J-Link、ST-Link）会阻止MCU进入深度休眠。我遇到过好几次，调试时功耗正常，一脱机跑功耗就飙升——后来发现是调试接口没禁用。

一个小技巧：在空闲任务里加一个计数器，统计每次进入空闲的持续时间。把这个数据通过串口或者日志输出，你就能清楚地看到系统的「睡眠质量」。如果发现空闲时间总是很短，说明任务调度有问题，需要重新设计任务优先级或者周期。

好了，关于空闲任务和Tickless模式，核心内容就这些。记住一句话：低功耗不是靠芯片省出来的，是靠调度省出来的。把空闲时间利用好，你的系统功耗就能降一个数量级。