目录

概述

1 基本规则

2 优先级与任务调度

3 设置任务优先级（API）

4 设计任务优先级的实用建议

5 常见陷阱

6  FreeRTOS vs Zephyr RTOS任务优先级

---

概述

FreeRTOS的任务优先级是一个核心概念，理解它对于设计稳定、高效的实时系统至关重要。下面我将从基础到高级，本文系统介绍任务优先级的相关概念和使用方法。

1 基本规则

核心规则总结如下：

特性	说明
规则	数字越高，优先级越高（0最低）
范围	0 到 configMAX_PRIORITIES - 1
调度	抢占式 + 同优先级时间片轮转
关键API	xTaskCreate, vTaskPrioritySet, uxTaskPriorityGet
设计原则	按紧急度分配，避免饥饿，减少等级
重要机制	互斥量的优先级继承 用于解决优先级反转

1） 数值越高，优先级越高：

在FreeRTOS中，任务的优先级用数字表示。数字越大，任务的优先级越高。例如，优先级为3的任务比优先级为2的任务有更高的执行权。

2） 可配置范围

 优先级范围取决于FreeRTOS的配置 configMAX_PRIORITIES。这个值在 FreeRTOSConfig.h 文件中定义。

• 例如，如果 configMAX_PRIORITIES 设为 7，那么可用的优先级就是 0, 1, 2, 3, 4, 5, 6。其中0是最低优先级，6是最高优先级。

• 注意： 实际可用的优先级索引是 0 到 (configMAX_PRIORITIES - 1)。

3） 默认任务优先级：

• 空闲任务： 固定为优先级 0（最低），用于在系统空闲时运行。

• 守护任务（如果启用）： 通常设置为 configMAX_PRIORITIES - 1（最高）。

• 用户创建的任务： 通常建议从一个中间值开始，比如 (configMAX_PRIORITIES / 2)，但这完全取决于你的应用设计。

2 优先级与任务调度

FreeRTOS默认使用 基于优先级的抢占式调度器：

1） 抢占

 如果一个更高优先级的任务进入了就绪态（例如，被创建、从中断中恢复、等待事件到来），它会立即抢占当前正在运行的、较低优先级的任务。CPU的控制权会切换到更高优先级的任务。

2） 同优先级任务

 如果多个任务共享同一个优先级，它们会以 时间片轮转 的方式共享CPU时间。调度器会为每个任务分配一个固定的时间片（tick interrupt）。当前任务的时间片用完后，调度器会切换到同优先级的下一个就绪任务。

3） 状态决定一切

只有 就绪态 的最高优先级任务才会被运行。

3 设置任务优先级（API）

在创建任务或运行时，使用以下函数：

// 1. 在创建任务时指定
xTaskCreate( vTaskFunction,   // 任务函数
             “TaskName”,      // 任务名
             STACK_SIZE,      // 栈大小
             NULL,            // 参数
             tskIDLE_PRIORITY + 2, // 优先级，例如：空闲优先级+2
             &xTaskHandle );  // 任务句柄

// 2. 在运行时修改任务优先级
vTaskPrioritySet( TaskHandle_t xTask, // 任务句柄（NULL表示修改当前任务）
                  UBaseType_t uxNewPriority );

// 3. 在运行时获取任务优先级
UBaseType_t uxTaskPriorityGet( TaskHandle_t xTask ); // 任务句柄

4 设计任务优先级的实用建议

1） 按紧急性和关键程度分配

 对时间要求最严格、最关键的硬实时任务应分配最高优先级（例如，电机紧急停止、安全监控）。

2） 避免“饥饿”

不要将所有任务都设为高优先级。低优先级任务（如日志记录、非关键状态监测）也需要获得CPU时间。确保系统设计中有适当的阻塞点（如等待队列、信号量、延迟），让高优先级任务在等待资源时主动让出CPU。

3） 优先级分层

 将系统功能模块化，同一模块或处理链路上的任务可以使用相同或相近的优先级。

4） 慎用最高优先级

最高优先级（configMAX_PRIORITIES - 1）通常应保留给最关键、运行时间极短的任务（如守护任务或最高优先级的中断服务例程后续处理任务）。

5） 尽量减少优先级数量：

不需要为每个任务分配一个唯一的优先级。过多的优先级会增加调度器的开销，并使系统行为更复杂。通常，4-8个不同的优先级等级足以满足大多数复杂应用。

5 常见陷阱

1） 优先级反转

• 问题： 一个低优先级任务持有一个共享资源（如互斥锁），一个中优先级任务抢占执行，而一个高优先级任务又需要等待那个共享资源，导致高优先级任务被中优先级任务阻塞——优先级发生了“反转”。

• 解决方案： FreeRTOS中的 互斥量 具有优先级继承机制。当高优先级任务等待被低优先级任务持有的互斥量时，低优先级任务的优先级会被临时提升到与高优先级任务相同，使其能尽快执行完毕并释放资源，从而避免被中优先级任务抢占。

2） 配置 configMAX_PRIORITIES

• 这个值越大，内核为每个任务分配的 就绪列表 数组就越大，消耗的RAM越多。

• 值设置过小，可能无法满足应用需求。需要根据实际任务数量合理设置。

3） 中断与任务优先级

• 中断服务程序的优先级由硬件（如Cortex-M的NVIC）设置，与FreeRTOS任务优先级是两个独立的体系。

• 中断的硬件优先级永远高于任何任务。当中断发生时，它会立即抢占当前任务。

• 通常，在中断服务程序中，只做最精简的操作（如清除标志、发送通知），然后将耗时的处理交给一个高优先级任务（或通过二值信号量、任务通知等唤醒），这被称为“延迟处理”。

6  FreeRTOS vs Zephyr RTOS任务优先级

Zephyr RTOS的线程优先级设计在机制和理念上与FreeRTOS有显著不同。其核心特征是：数值越低，优先级越高；并且用正负号来区分两种调度行为完全不同的线程。下面这个表格对比了Zephyr与FreeRTOS在优先级上的关键区别：

特性	Zephyr RTOS	FreeRTOS
优先级数值意义	数值越低，优先级越高 (如 -2 > 0 > 5)	数值越高，优先级越高 (如 6 > 3 > 0)
调度类别	协作式线程 (负优先级) 和 可抢占式线程 (非负优先级)	所有任务均为可抢占式，通过API模拟协作行为
默认最低优先级	空闲线程，固定为最低优先级	空闲任务，固定为优先级 0
默认最高优先级	主线程，默认为最高可抢占优先级 0	由用户定义，通常为 configMAX_PRIORITIES - 1
优先级范围	由 CONFIG_NUM_COOP_PRIORITIES 和 CONFIG_NUM_PREEMPT_PRIORITIES 配置决定	由 configMAX_PRIORITIES 配置决定 (通常 0 到 N-1)

1） 两类线程与调度机制

这是Zephyr调度设计的核心，由优先级数值的正负决定：

• 协作式线程：优先级为负数。一旦运行，除非主动放弃CPU（如等待信号量、睡眠或调用k_yield()），否则会一直运行。

• 可抢占式线程：优先级为非负数（0和正数）。可以被更高优先级（数值更低）的协作式或可抢占式线程抢占。

2） 配置与使用优先级

优先级范围由两个配置项决定：

• CONFIG_NUM_COOP_PRIORITIES：协作式优先级数量，范围是 -N 到 -1。

• CONFIG_NUM_PREEMPT_PRIORITIES：可抢占式优先级数量，范围是 0 到 (N-1)。

系统线程的优先级是固定的：主线程默认为最高可抢占优先级 0，空闲线程固定为最低优先级。

3） 设计建议与注意事项

1. 合理划分类别：将要求严苛、不允许被中断的关键处理（如高速电机控制、安全监控）设为协作式线程（负优先级）。将一般的、可分割的处理任务设为可抢占式线程。

2. 避免协作式线程独占CPU：长时间运行的协作式线程必须在循环中适时调用 k_yield() 或使用信号量等机制主动让出CPU，以防系统卡死。

3. 优先级继承：与FreeRTOS类似，Zephyr的互斥量也支持优先级继承，可有效解决优先级反转问题。

4. 理解“数值低优先级高”：这是最需要适应的一点，务必牢记。

Zephyr通过正负优先级明确区分了协作式与可抢占式两种调度策略，这提供了更强的行为可控性，但也要求开发者更精细地规划线程类型。从FreeRTOS迁移时，除了要翻转优先级数值大小的观念，更重要的是根据任务特性重新归类。