4. 任务优先级机制：优先级数值含义、优先级与任务调度的关系、优先级配置宏(configMAX_PRIORITIES)

好，咱们今天来聊聊FreeRTOS里一个绕不开的话题——任务优先级。说实话，我刚接触RTOS那会儿，觉得优先级不就是个数字嘛，大的先跑，小的后跑，多简单。结果呢？第一次做项目就踩了坑，系统跑起来一会儿卡死，一会儿任务饿死，排查了半天才发现是优先级没玩明白。

优先级这东西，说白了就是给每个任务贴个“重要性标签”。但怎么贴、贴多大、贴错了会怎样，这里面的门道可不少。我带你一层层剥开来看。

4.1 优先级数值的含义：数字越大，地位越高？

在FreeRTOS里，优先级是用一个整数来表示的。数值范围从0开始，一直到你配置的最大值减1。这里有个关键点：数值越大，优先级越高。

举个例子，优先级5的任务，永远比优先级3的任务先获得CPU使用权。优先级0呢？那是系统里最低的优先级，通常留给空闲任务用。

我有个习惯，在设计任务时，会把关键性任务（比如电机控制、通信处理）放在高优先级，把非关键任务（比如LED闪烁、按键扫描）放在低优先级。这样即使系统忙不过来，丢掉的也只是些无关紧要的操作。

4.2 优先级与任务调度的关系：谁抢到算谁的

FreeRTOS是一个抢占式实时操作系统。什么叫抢占式？就是高优先级任务可以随时打断低优先级任务的执行。你想想看，这就像公司里的紧急事务——老板的电话来了，你手头的报表就得先放一放。

具体调度规则是这样的：

1. 就绪态任务中，优先级最高的先运行。系统会从所有“准备好”的任务里，挑出优先级最高的那个，把CPU给它。
2. 高优先级任务一旦就绪，立即抢占。如果正在运行的是优先级3的任务，突然优先级5的任务因为某个事件（比如中断、信号量）变得就绪了，那系统会立刻切换过去。
3. 相同优先级的任务，采用时间片轮转。如果两个任务优先级一样，那就轮流来，每人跑一个时间片（通常是1个tick）。

我在项目中遇到过一个问题：一个高优先级任务里做了个延时等待，结果低优先级任务一直没机会跑。后来发现，高优先级任务虽然延时了，但延时结束后又立刻抢占了CPU，低优先级任务根本没机会。解决办法？要么降低那个任务的优先级，要么在延时前主动让出CPU。

4.3 优先级配置宏：configMAX_PRIORITIES

这个宏定义在FreeRTOSConfig.h里，它决定了系统支持多少个优先级等级。比如你写成：

#define configMAX_PRIORITIES 5

那系统就支持优先级0到4，共5个等级。注意，这个值不是随便写的，它直接影响系统的内存占用和调度效率。

我个人的建议是：够用就好，别贪多。为什么？因为每个优先级都需要额外的内存来维护就绪列表。优先级越多，列表越长，调度时的查找开销也越大。对于大多数嵌入式项目，5到10个优先级完全够用了。

举个例子，一个典型的物联网终端设备，任务优先级可以这样分配：

优先级	任务名称	说明
4（最高）	紧急事件处理	比如硬件故障、看门狗喂狗
3	通信收发	WiFi/蓝牙数据收发，延迟敏感
2	数据处理	协议解析、业务逻辑
1	用户交互	按键、显示刷新
0（最低）	空闲任务	系统空闲时运行

你看，这样分配下来，紧急事件能第一时间响应，通信不会丢包，用户交互也不会卡顿。这就是优先级设计的艺术。

4.4 知识体系图：优先级机制的核心逻辑

下面这张图，是我自己梳理的优先级机制核心逻辑。你看一遍，基本就能把整个机制串起来了。

这张图其实就说了三件事：第一，优先级总数由configMAX_PRIORITIES决定；第二，数值越大优先级越高；第三，调度器根据优先级决定是抢占还是轮转。嗯，就这么简单，但实际用起来，你得结合具体场景去权衡。

4.5 实战建议：优先级设计的几个原则

最后，我把自己这些年总结的几个优先级设计原则分享给你：

• 关键任务放高位，非关键任务放低位。这是铁律，别反着来。
• 高优先级任务要短小精悍。别在高优先级里做复杂计算或长时间等待，否则低优先级任务会饿死。
• 优先级数量宁少勿多。5个够用就别设10个，省内存也省心。
• 用队列或信号量解耦。高优先级任务只负责“通知”，具体处理交给中等优先级的任务去干。

我记得有一次做工业控制器，一个同事把所有的任务都设成了同一个优先级。结果呢？系统跑起来跟单任务没啥区别，该卡的时候照样卡。后来我帮他重新划分了优先级，把报警处理提到最高，显示刷新降到最低，系统一下子就顺畅了。所以说，优先级设计不是锦上添花，而是雪中送炭。

---

公众号:蓝海资料掘金营，微信deep3321