一段代码跑在单片机里和我们平时写PC程序最大的不同是什么不是语法不是编译器——是同时做多件事的方式。PC上开十个窗口操作系统帮你来回切换你感觉不到延迟。但在STM32上一个单核Cortex-M3要同时处理按键扫描、LCD刷新、传感器数据采集和通信协议解析谁来决定这些任务什么时候跑、跑多久、让谁先跑答案是调度器。我们来看FreeRTOS是怎么解决这个问题的。任务不是同时运行而是轮流露脸首先要理解的一个核心概念是在任何单核处理器上某一时刻只有一个任务在执行。所谓多任务不过是调度器在极短的时间内让不同的任务轮流使用CPU。FreeRTOS中的每个任务都有四种状态运行态Running、就绪态Ready、阻塞态Blocked和挂起态Suspended。我们就从这几个状态入手看看调度器到底在忙什么。当系统上电vTaskStartScheduler()被调用后调度器开始工作。它会从所有就绪态的任务中挑一个优先级最高的来执行——这就是运行态。如果这个任务调用了vTaskDelay()或者等待某个队列/信号量它就从运行态转入阻塞态。此时调度器回头扫一眼就绪列表再挑一个当前优先级最高的继续跑。如此循环往复。一个有意思的设计是如果两个任务优先级相同FreeRTOS会使用时间片轮转Round-Robin。每个任务跑一个tick通常1ms时间一到就被强制换下换另一个同优先级的上场。这和我们平时用Linux的CFS调度器的感受不太一样——在FreeRTOS里优先级决定了能不能抢跑而时间片决定了跑多久。谁在驱动这一切Tick中断调度器的每一次决策都需要一个触发器。这个触发器就是SysTick定时器产生的中断。每次tick中断到来FreeRTOS会做几件事- 减少当前任务的时间片计数如果有用时间片轮转- 检查是否有阻塞中的任务已经超时如果有将它们移回就绪列表- 调用vTaskSwitchContext()决定要不要切换任务如果当前运行的是最高优先级的就绪任务那无事发生继续跑。如果刚超时了一个优先级更高的任务那上下文切换就触发当前任务被打断存好寄存器现场让高优先级任务顶上。这里的存寄存器现场非常关键。每次任务切换时FreeRTOS会手动将R0-R12、LR、PC、xPSR等压入当前任务的栈中然后从目标任务的栈里弹出这些寄存器。切换完以后新任务继续执行完全不知道自己刚才被挂起过。一个很多人没注意到的细节Idle任务你一定注意到了一件事如果所有任务都阻塞了谁来跑或者说调度器从就绪列表里挑人如果就绪列表是空的呢FreeRTOS的设计很聪明——它在启动调度器时自动创建了一个优先级为0的Idle任务。这个任务永不阻塞永远处于就绪态唯一的用途是当没有其他任务可以运行的时候让CPU有事可做。Idle任务默认会执行一条wfiWait For Interrupt指令或者空循环具体取决于配置项configIDLE_SHOULD_YIELD_IS_1。一个常见的优化是在Idle任务里喂狗、进入低功耗模式或者做系统级的内务处理比如释放被删除任务的内存。但这里有个陷阱——千万不要把Idle任务的优先级改高。如果你在应用代码中把其他任务也设为优先级0那这些任务会和Idle任务同优先级。由于Idle任务默认配置了允许被同优先级任务抢占configIDLE_SHOULD_YIELD_IS_1它每次都会让出时间片给其他同优先级任务这也意味着它可能很少真正运行到你的内务代码就得不到执行。优先级反转问题讲调度器就绕不开优先级反转。考虑三个任务TaskA优先级3、TaskB优先级2、TaskC优先级1。它们共享一个互斥量保护的资源。场景是这样的TaskC先拿到了互斥量开始访问共享资源。这时TaskA就绪了它优先级更高立刻抢占了TaskC。TaskA也想要同一个互斥量但TaskC还拿着TaskA被阻塞。调度器回头一查TaskB刚好也就绪了。注意——TaskB优先级高于TaskC但低于TaskA它不需要互斥量它就直接跑起来了。结果呢TaskB跑得欢TaskC被TaskB抢占了没法释放互斥量TaskA还在那儿等着。明明是优先级最高的任务反而被最低优先级的任务卡住了。这就是优先级反转。FreeRTOS的互斥量通过优先级继承协议来处理这个问题当高优先级任务被低优先级任务持有的互斥量阻塞时系统会把持有者的优先级暂时提升到与等待任务的优先级相同即TaskC被临时提权到3让TaskC能尽快跑完、释放互斥量。之后TaskC的优先级恢复原值。配置项configUSE_MUTEXES和configUSE_PRIORITY_INHERITANCE需要同时启用才能生效。标准信号量xSemaphoreCreateBinary没有这个机制——只有互斥量才带了优先级继承。如何观察调度器的行为如果你想亲眼看看调度器在做决策最简单的方法是拉一个GPIO在vTaskSwitchContext()里翻转它。用逻辑分析仪或者示波器看这个引脚的波形每次跳变就是一次任务切换。也可以用FreeRTOS的trace功能。配置configUSE_TRACE_FACILITY和configUSE_STATS_FORMATTING_FUNCTIONS后vTaskList()和uxTaskGetSystemState()能打印出每个任务的运行时间统计——哪个任务吃了多少CPU一目了然。上次调一个传感器驱动时发现某个任务的CPU占用率莫名奇高用这个一查发现是它在轮询里没有加阻塞延时while(1)里面直接跑空了。加上vTaskDelay(pdMS_TO_TICKS(10))之后占用率从85%降到了3%。你遇过类似的情况吗
一段代码跑在单片机里和我们平时写PC程序最大的不同是什么不是语法不是编译器——是同时做多件事的方式。PC上开十个窗口操作系统帮你来回切换你感觉不到延迟。但在STM32上一个单核Cortex-M3要同时处理按键扫描、LCD刷新、传感器数据采集和通信协议解析谁来决定这些任务什么时候跑、跑多久、让谁先跑答案是调度器。我们来看FreeRTOS是怎么解决这个问题的。任务不是同时运行而是轮流露脸首先要理解的一个核心概念是在任何单核处理器上某一时刻只有一个任务在执行。所谓多任务不过是调度器在极短的时间内让不同的任务轮流使用CPU。FreeRTOS中的每个任务都有四种状态运行态Running、就绪态Ready、阻塞态Blocked和挂起态Suspended。我们就从这几个状态入手看看调度器到底在忙什么。当系统上电vTaskStartScheduler()被调用后调度器开始工作。它会从所有就绪态的任务中挑一个优先级最高的来执行——这就是运行态。如果这个任务调用了vTaskDelay()或者等待某个队列/信号量它就从运行态转入阻塞态。此时调度器回头扫一眼就绪列表再挑一个当前优先级最高的继续跑。如此循环往复。一个有意思的设计是如果两个任务优先级相同FreeRTOS会使用时间片轮转Round-Robin。每个任务跑一个tick通常1ms时间一到就被强制换下换另一个同优先级的上场。这和我们平时用Linux的CFS调度器的感受不太一样——在FreeRTOS里优先级决定了能不能抢跑而时间片决定了跑多久。谁在驱动这一切Tick中断调度器的每一次决策都需要一个触发器。这个触发器就是SysTick定时器产生的中断。每次tick中断到来FreeRTOS会做几件事- 减少当前任务的时间片计数如果有用时间片轮转- 检查是否有阻塞中的任务已经超时如果有将它们移回就绪列表- 调用vTaskSwitchContext()决定要不要切换任务如果当前运行的是最高优先级的就绪任务那无事发生继续跑。如果刚超时了一个优先级更高的任务那上下文切换就触发当前任务被打断存好寄存器现场让高优先级任务顶上。这里的存寄存器现场非常关键。每次任务切换时FreeRTOS会手动将R0-R12、LR、PC、xPSR等压入当前任务的栈中然后从目标任务的栈里弹出这些寄存器。切换完以后新任务继续执行完全不知道自己刚才被挂起过。一个很多人没注意到的细节Idle任务你一定注意到了一件事如果所有任务都阻塞了谁来跑或者说调度器从就绪列表里挑人如果就绪列表是空的呢FreeRTOS的设计很聪明——它在启动调度器时自动创建了一个优先级为0的Idle任务。这个任务永不阻塞永远处于就绪态唯一的用途是当没有其他任务可以运行的时候让CPU有事可做。Idle任务默认会执行一条wfiWait For Interrupt指令或者空循环具体取决于配置项configIDLE_SHOULD_YIELD_IS_1。一个常见的优化是在Idle任务里喂狗、进入低功耗模式或者做系统级的内务处理比如释放被删除任务的内存。但这里有个陷阱——千万不要把Idle任务的优先级改高。如果你在应用代码中把其他任务也设为优先级0那这些任务会和Idle任务同优先级。由于Idle任务默认配置了允许被同优先级任务抢占configIDLE_SHOULD_YIELD_IS_1它每次都会让出时间片给其他同优先级任务这也意味着它可能很少真正运行到你的内务代码就得不到执行。优先级反转问题讲调度器就绕不开优先级反转。考虑三个任务TaskA优先级3、TaskB优先级2、TaskC优先级1。它们共享一个互斥量保护的资源。场景是这样的TaskC先拿到了互斥量开始访问共享资源。这时TaskA就绪了它优先级更高立刻抢占了TaskC。TaskA也想要同一个互斥量但TaskC还拿着TaskA被阻塞。调度器回头一查TaskB刚好也就绪了。注意——TaskB优先级高于TaskC但低于TaskA它不需要互斥量它就直接跑起来了。结果呢TaskB跑得欢TaskC被TaskB抢占了没法释放互斥量TaskA还在那儿等着。明明是优先级最高的任务反而被最低优先级的任务卡住了。这就是优先级反转。FreeRTOS的互斥量通过优先级继承协议来处理这个问题当高优先级任务被低优先级任务持有的互斥量阻塞时系统会把持有者的优先级暂时提升到与等待任务的优先级相同即TaskC被临时提权到3让TaskC能尽快跑完、释放互斥量。之后TaskC的优先级恢复原值。配置项configUSE_MUTEXES和configUSE_PRIORITY_INHERITANCE需要同时启用才能生效。标准信号量xSemaphoreCreateBinary没有这个机制——只有互斥量才带了优先级继承。如何观察调度器的行为如果你想亲眼看看调度器在做决策最简单的方法是拉一个GPIO在vTaskSwitchContext()里翻转它。用逻辑分析仪或者示波器看这个引脚的波形每次跳变就是一次任务切换。也可以用FreeRTOS的trace功能。配置configUSE_TRACE_FACILITY和configUSE_STATS_FORMATTING_FUNCTIONS后vTaskList()和uxTaskGetSystemState()能打印出每个任务的运行时间统计——哪个任务吃了多少CPU一目了然。上次调一个传感器驱动时发现某个任务的CPU占用率莫名奇高用这个一查发现是它在轮询里没有加阻塞延时while(1)里面直接跑空了。加上vTaskDelay(pdMS_TO_TICKS(10))之后占用率从85%降到了3%。你遇过类似的情况吗
