前阵子帮人看一个STM32F103C8T6上的FreeRTOS工程，现象很典型：串口打印断断续续，屏幕刷新偶尔卡死，两个任务像在抢方向盘。翻代码一看，任务优先级全设成一样的2，系统心跳Tick频率还是默认的1000Hz，vTaskDelay里却按10ms的倍数写，任务堆栈也只给了128字。这个问题不是某个API用错，而是对FreeRTOS任务优先级和系统心跳Tick的关系没吃透。任务优先级决定谁先跑、谁能抢占谁，系统心跳Tick决定延时精度、超时判断和调度器的时间基准，两者一旦配合不好，轻则响应变慢，重则任务饿死、堆栈溢出、通信丢包。下面我按实际项目里的配置、计算和排查顺序，把这两个东西拆开讲清楚，适合刚移植完FreeRTOS、正在调任务分工，或者准备拿FreeRTOS做STM32项目实战的人参考。
1. 先弄清任务优先级和Tick的底层关系
1.1 任务优先级在调度器里到底怎么用
FreeRTOS里的任务优先级是一个整数，数值越大优先级越高。configMAX_PRIORITIES决定系统最多支持多少级优先级，比如设成7，那么合法优先级就是0到6。空闲任务优先级固定为0，定时器服务任务优先级由configTIMER_TASK_PRIORITY决定，通常不会设得太低。调度器内部维护一组就绪链表pxReadyTasksLists[configMAX_PRIORITIES]，每个优先级对应一个链表，任务就绪时挂到对应链表上。调度器每次找最高非空链表，从里面挑一个任务运行，所以高优先级任务只要就绪，就会立刻抢占低优先级任务，这就是抢占式调度的核心。
在Cortex-M3内核上，任务切换靠PendSV异常完成，SysTick负责产生系统心跳。任务优先级本身不直接写进NVIC，它只影响FreeRTOS调度器的选择结果。如果configUSE_PREEMPTION设为1，高优先级任务可以打断低优先级任务；如果设为0，任务要主动让出CPU才会切换。很多新手把任务优先级当成“线程权限”或者“执行顺序”，实际上它更接近“抢占权”，高优先级任务如果一直不阻塞，低优先级任务永远没机会跑。
1.2 Tick心跳不是单纯延时，而是调度时基
系统心跳Tick通常由SysTick定时器产生，频率由configTICK_RATE_HZ决定。常见配置是1000Hz，也就是每1ms来一次Tick中断。每次Tick中断发生，FreeRTOS会做几件事：全局Tick计数xTickCount加一，检查延时链表里有没有任务到期，如果有就把任务从延时链表移到就绪链表，然后判断是否需要触发任务切换。vTaskDelay、vTaskDelayUntil、xQueueReceive的超时、xSemaphoreTake的超时，底层都依赖这个Tick计数。
Tick频率不是越高越好。1000Hz时，vTaskDelay(1)就是1ms，延时分辨率是1ms；100Hz时，vTaskDelay(1)是10ms，很多需要几毫秒响应的任务就没法做。但频率越高，Tick中断越频繁，CPU花在中断上下文的时间也越多。假设一次Tick中断处理需要5us，1000Hz时CPU占用约0.5%，10000Hz时占用约5%，如果中断处理里还有别的逻辑，实际开销会更高。所以选Tick频率时，要在响应精度和CPU开销之间找平衡。
1.3 两者配合的典型误区
最常见的误区是任务优先级设成一样，然后指望vTaskDelay控制执行顺序。相同优先级的任务在没有阻塞时，会按时间片轮转，每个时间片通常是一个Tick。如果Tick频率是1000Hz，时间片就是1ms，任务切换看起来很频繁，但实际执行顺序并不完全可控。另一个误区是给高优先级任务写了一个死循环，里面没有vTaskDelay、没有等待信号量，结果低优先级任务全部饿死，连空闲任务都跑不了，系统看门狗也可能被触发。
还有一种情况是Tick频率和延时写法不匹配。比如configTICK_RATE_HZ是100Hz，代码里写vTaskDelay(10)，本意是10ms，实际却是100ms，因为vTaskDelay的参数单位是Tick，不是毫秒。正确做法是用pdMS_TO_TICKS(10)转换。如果Tick频率是1000Hz，pdMS_TO_TICKS(10)就是10；如果频率是100Hz，pdMS_TO_TICKS(10)就是1，但这样10ms会被截断成10ms，因为1个Tick就是10ms。截断误差要心里有数，高精度延时最好用硬件定时器或者提高Tick频率。
2. 任务优先级配置实战：从数值规则到任务拆分
2.1 优先级数值规则与抢占式、时间片调度
FreeRTOS任务优先级从0开始，0是最低，configMAX_PRIORITIES-1是最高。比如configMAX_PRIORITIES设为7，优先级范围是0到6。空闲任务固定0，软件定时器任务优先级由configTIMER_TASK_PRIORITY设置，通常设为比普通任务高一点，避免定时器回调被长时间拖延。抢占式调度由configUSE_PREEMPTION控制，时间片轮转由configUSE_TIME_SLICING控制。如果configUSE_TIME_SLICING为1，同优先级任务会轮流运行，每个任务运行一个Tick后切换到同优先级的下一个任务；如果为0，同优先级任务只有主动阻塞才会切换。
在实际项目里，我通常把configMAX_PRIORITIES设成8或10，留出足够层级，但不会把每个任务都设成不同优先级。优先级层级越多，调度逻辑越难维护，任务之间稍微改一下周期就可能互相影响。比较稳的做法是分层：硬实时任务一层，软实时任务一层，人机交互一层，后台日志一层，空闲一层。同级任务再用时间片轮转，这样结构清楚，排查也方便。
2.2 实际项目里的优先级分层方法
以STM32F103C8T6上的一个典型项目为例：电机控制或传感器采样周期10ms，截止时间很紧，优先级设5；通信协议解析周期20ms，偶尔有突发数据，优先级设4；LVGL界面刷新周期5ms或者按事件触发，优先级设2；日志存储和低功耗管理优先级设1；空闲任务0。中断服务程序不占任务优先级，但NVIC优先级要单独配置，后面会讲。
这样分层的理由很简单：控制任务错过一个周期可能导致控制不稳定，通信任务偶尔晚几毫秒只是响应变慢，界面刷新晚几毫秒人眼几乎看不出来。高优先级任务必须短小，执行时间不能超过它的周期，否则低优先级任务会被挤压。如果控制任务一个周期要跑8ms，周期是10ms，那CPU占用已经80%，再叠加通信和界面，系统就会很吃力。这时候要么降低控制任务频率，要么优化算法，要么换更高主频的芯片。
| 任务类型 | 建议优先级 | 典型周期 | 阻塞方式 |
|---|---|---|---|
| 硬实时控制 | 5 | 5ms到10ms | vTaskDelayUntil |
| 通信解析 | 4 | 10ms到20ms | 队列、信号量 |
| 界面刷新 | 2 | 5ms到30ms | 定时器、事件 |
| 日志后台 | 1 | 100ms以上 | vTaskDelay |
| 空闲任务 | 0 | 无 | 系统自动 |
2.3 优先级反转与互斥量优先级继承
优先级反转是FreeRTOS项目里很容易踩的坑。假设低优先级任务先拿到互斥量，正在写共享数据；高优先级任务也要这个互斥量，只能阻塞等待；这时一个中优先级任务就绪，抢占了低优先级任务，导致高优先级任务间接等待中优先级任务跑完。高优先级任务被中优先级任务拖住，这就是优先级反转。FreeRTOS的互斥量支持优先级继承，低优先级任务持有互斥量时，如果高优先级任务来拿，低优先级任务的优先级会临时提升到高优先级，避免被中优先级任务抢占。
注意，二值信号量没有优先级继承，它适合任务同步或者中断到任务的同步，不适合用来保护共享资源。保护共享资源要用xSemaphoreCreateMutex创建的互斥量。还有一个细节，互斥量不能在中断里使用，中断里只能用FromISR结尾的API，比如xSemaphoreGiveFromISR，而且对应的信号量最好是二值信号量，不要用互斥量。此外，持有互斥量的时间要尽量短，不要在里面调用vTaskDelay或者做耗时操作，否则优先级继承也救不了系统响应。
2.4 创建任务时的参数与优先级检查
创建任务用xTaskCreate或者xTaskCreateStatic。xTaskCreate的参数依次是任务函数、任务名、堆栈深度、参数、优先级、任务句柄。堆栈深度单位是字，不是字节。Cortex-M3上一个字是4字节，所以堆栈深度128代表512字节。很多人看到128以为很多，其实很容易溢出，尤其任务里有局部数组、浮点运算、printf调用时。优先级参数直接填数值，但最好用宏定义，比如PRIO_CTRL、PRIO_COMM，避免后面调优先级时到处改数字。
#define PRIO_CTRL 5 #define PRIO_COMM 4 #define PRIO_LVGL 2 #define PRIO_LOG 1 xTaskCreate(vTaskCtrl, "Ctrl", 256, NULL, PRIO_CTRL, &xHandleCtrl); xTaskCreate(vTaskComm, "Comm", 512, NULL, PRIO_COMM, &xHandleComm); xTaskCreate(vTaskLvgl, "Lvgl", 1024, NULL, PRIO_LVGL, &xHandleLvgl); xTaskCreate(vTaskLog, "Log", 256, NULL, PRIO_LOG, &xHandleLog);创建之后可以用uxTaskPriorityGet查询，用vTaskPrioritySet动态修改。动态修改优先级要小心，改完之后任务可能立刻被抢占。如果任务正在持有互斥量，优先级继承状态可能会受影响，所以最好在系统初始化阶段把优先级定好，运行中尽量少改。configASSERT在调试阶段一定要开，它能帮你抓出优先级越界、堆栈溢出、中断优先级配置错误等问题。
3. 系统心跳Tick配置：频率选择、SysTick计算与低功耗
3.1 configTICK_RATE_HZ该选多少
configTICK_RATE_HZ是FreeRTOSConfig.h里最关键的配置之一。常见值有100、200、1000、10000。100Hz对应10ms一个Tick，CPU开销极低，但延时精度差，适合低功耗、慢速采集设备。1000Hz对应1ms一个Tick，是STM32项目里最常用的档位，延时精度和开销平衡得不错。10000Hz对应100us一个Tick，适合高速控制、精确超时，但中断开销明显增加，而且很多任务根本不需要这么高的分辨率。
选频率时先看系统里最短的时间要求。如果最短周期任务是5ms，1000Hz完全够用；如果有1ms级超时检测，1000Hz只能给你1ms粒度，可能有1个Tick误差，想更细就得用硬件定时器或者提高Tick频率。还要看CPU主频，STM32F103C8T6主频72MHz，跑1000Hz很轻松，跑10000Hz也能跑，但中断负载要实测。我的习惯是默认1000Hz，除非低功耗要求特别严，或者有高速控制需求，才会调整。
3.2 SysTick重装载值与Tick中断计算
Cortex-M3内核的SysTick是一个24位递减计数器，重装载值不能超过0xFFFFFF。Tick中断周期计算公式是：SysTick重装载值 = SystemCoreClock / configTICK_RATE_HZ - 1。以STM32F103C8T6为例，SystemCoreClock通常是72MHz，configTICK_RATE_HZ为1000，重装载值就是72000000 / 1000 - 1 = 71999。这个值小于0xFFFFFF，配置合法。如果configTICK_RATE_HZ设成1Hz，重装载值会超过24位溢出，SysTick就不适合直接产生这么慢的Tick，需要用别的定时器。
FreeRTOS的Cortex-M3移植层里，SysTick中断服务程序通常叫xPortSysTickHandler，它会调用xTaskIncrementTick，然后根据返回值决定是否触发PendSV切换任务。SysTick中断优先级和PendSV优先级一般配置为最低，也就是数值最大。这样它们不会抢占高优先级中断，保证中断嵌套逻辑正确。在CubeMX里配置FreeRTOS时，这些底层代码会自动生成，但如果你手动移植，一定要检查port.c里的配置，尤其是configKERNEL_INTERRUPT_PRIORITY和configMAX_SYSCALL_INTERRUPT_PRIORITY。
3.3 vTaskDelay与vTaskDelayUntil的Tick换算
vTaskDelay的参数是Tick数，不是毫秒。想要延时100ms，稳妥写法是vTaskDelay(pdMS_TO_TICKS(100))。pdMS_TO_TICKS宏会根据configTICK_RATE_HZ自动换算，1000Hz时结果是100，100Hz时结果是10。如果忘了换算，直接写vTaskDelay(100)，1000Hz下是100ms，100Hz下就是1秒，误差非常大。另一个常用函数是vTaskDelayUntil，它用于固定周期任务，参数是上一次唤醒时间和周期增量。它会把任务唤醒时间累加，避免vTaskDelay带来的累积漂移。
void vTaskCtrl(void *pvParameters) { TickType_t xLastWakeTime = xTaskGetTickCount(); const TickType_t xPeriod = pdMS_TO_TICKS(10); for (;;) { // 控制逻辑，尽量短小 vTaskDelayUntil(&xLastWakeTime, xPeriod); } }vTaskDelayUntil的周期参数也是Tick。如果任务执行时间偶尔超过周期，下一次唤醒时间已经过去了，vTaskDelayUntil会立即返回，任务会连续运行补上，可能造成CPU占用飙升。所以周期任务的设计原则是：任务执行时间必须小于周期，最好只占周期的50%以内。TickType_t的宽度也要注意，16位Tick在1000Hz下大约65秒溢出，32位Tick大约49.7天溢出。代码里可以用xTaskGetTickCount和溢出安全的比较函数，避免长时间运行后延时错乱。
3.4 Tickless低功耗模式下的注意点
configUSE_TICKLESS_IDLE打开后，系统在空闲时可以停止Tick中断，进入低功耗模式，等到下一个任务到期或者外部中断唤醒时再补偿Tick计数。这个功能对电池设备很有用，但调试阶段建议先关掉。因为Tickless会影响vTaskDelay的精度，时间片轮转也可能变得不规律，一些依赖Tick计数做超时的通信协议可能出错。低功耗模式的选择也要看芯片，STM32F103C8T6支持Sleep、Stop、Standby，Tickless通常配合Sleep或Stop模式，唤醒后要重新校准时钟。
另外，Tickless模式下外部中断唤醒源要配置正确，否则系统可能睡过去醒不来。唤醒后FreeRTOS会调用vTaskStepTick补偿睡眠期间的Tick数，补偿值不能超过configEXPECTED_IDLE_TIME_BEFORE_SLEEP限制。如果补偿逻辑有误，Tick计数会跳变，超时判断就会乱。我的习惯是先在普通模式下把任务优先级和Tick频率调稳，再开Tickless做低功耗优化，并且用GPIO翻转配合示波器看实际唤醒周期。
4. 优先级和Tick在典型场景里的配合
4.1 周期任务：用vTaskDelayUntil锁定节拍
周期任务最怕两件事：周期漂移和CPU占用过高。vTaskDelayUntil能解决漂移，但前提是任务执行时间稳定且小于周期。假设控制任务周期10ms，Tick频率1000Hz，xPeriod就是10。如果任务执行时间平均3ms，CPU占用30%；如果某次执行8ms，留给其他任务的时间只剩2ms，通信和界面任务就可能被拖延。你可以用GPIO在任务开始时拉高、结束时拉低，示波器测出实际执行时间，再决定优先级和周期是否合理。
如果任务里有阻塞操作，比如等待ADC转换完成，最好用中断加信号量，而不是在周期任务里死等。死等会浪费CPU，还会让高优先级任务变成“高优先级忙等”，低优先级任务照样饿死。正确做法是控制任务等待一个二值信号量，ADC中断完成后释放信号量，控制任务再继续跑。这样控制任务在等待时阻塞，低优先级任务有机会运行，Tick中断也能正常处理超时。
4.2 高实时任务与后台任务的分工
高实时任务优先级高，但必须短小且会阻塞。通信任务优先级中等，负责解析协议、打包数据。LVGL界面任务优先级低，负责刷屏和触摸响应。后台日志任务优先级最低，负责写Flash或SD卡。中断服务程序优先级最高，但只做最少的事，比如读寄存器、清标志、释放信号量，把耗时处理留给任务。这样分工之后，高优先级任务不会被低优先级任务拖住，低优先级任务也不会完全饿死。
实际项目里经常遇到“高优先级任务等待低优先级任务释放信号量”的情况。如果低优先级任务因为优先级太低一直没跑，高优先级任务就会超时。解决办法是给低优先级任务一个合理的优先级，或者用互斥量优先级继承，或者把释放信号量的操作放到中断里。比如串口接收中断收到一帧数据后，直接释放二值信号量，通信任务优先级4，收到信号量后立刻处理，不依赖低优先级任务。
4.3 信号量、队列超时等待中的Tick
队列、信号量、事件组的超时等待都依赖Tick计数。xQueueReceive的第二个参数是等待Tick数，xSemaphoreTake同理。pdMS_TO_TICKS(20)表示最多等20ms，超时返回pdFALSE。超时时间不要随便写0或者portMAX_DELAY。写0表示不等待，立即返回，适合轮询场景；写portMAX_DELAY表示永久等待，适合确定会到来的事件。如果事件可能丢失，永久等待会让任务卡死，最好给一个合理超时，超时后做异常处理。
if (xSemaphoreTake(xBinarySem, pdMS_TO_TICKS(20)) == pdTRUE) { // 处理事件 } else { // 超时处理 }中断里不能用xSemaphoreTake，要用xSemaphoreGiveFromISR释放信号量。释放后如果需要任务切换，要把pxHigherPriorityTaskWoken设为pdTRUE，然后在中断退出前调用portYIELD_FROM_ISR。这个细节在Cortex-M3移植里很关键，忘了写会导致高优先级任务不能立刻切换，响应变慢。二值信号量适合中断到任务的同步，计数信号量适合管理多个资源，互斥量适合保护共享资源，别混用。
4.4 LVGL刷新、串口接收与优先级安排
FreeRTOS移植LVGL时，LVGL任务优先级不宜太高。LVGL刷屏可能涉及大量像素操作，优先级设太高会抢占通信和控制任务，导致串口丢包或者控制周期抖动。通常把LVGL任务优先级设在2左右，周期5ms到30ms，或者用定时器事件触发。LVGL内部如果使用互斥量保护显示，注意不要在持有互斥量时长时间阻塞。串口接收中断优先级要低于configMAX_SYSCALL_INTERRUPT_PRIORITY，否则不能在中断里调用FromISR API，系统会触发断言。
如果要在任务之间传字符串，别直接用全局变量加标志位，容易出竞态。可以用队列传指针，但指针指向的内存要保证生命周期；也可以传结构体或者用内存池分配。队列发送和接收都有超时参数，同样以Tick为单位。串口接收任务优先级可以设4，收到数据后解析，解析完通过队列发给控制任务。控制任务优先级5，但控制任务不应该被通信任务频繁打断，所以通信任务释放信号量的频率要控制，避免高优先级任务被大量事件淹没。
5. 常见问题排查：任务不跑、延时漂移、堆栈溢出
5.1 任务饿死与优先级设置错误
任务饿死的典型现象是：低优先级任务完全不执行，或者执行一次后再也不跑。先检查高优先级任务里有没有阻塞点。如果高优先级任务是一个for(;;)死循环，里面没有vTaskDelay、没有等待信号量、没有队列接收，那它就会一直占着CPU。解决方法是给高优先级任务加阻塞，比如等待事件、等待定时器、等待信号量。如果业务上确实需要一直运行，那就把它拆成状态机，每个Tick或者每个周期处理一部分，主动让出CPU。
另一个原因是优先级设得太接近。比如两个任务都设成5，其中一个任务一直就绪，另一个任务只能等时间片。时间片轮转虽然是1个Tick，但如果Tick频率是100Hz，时间片就是10ms，低优先级任务可能感觉很久没跑。这时候可以适当拉开优先级，或者给低优先级任务明确的触发事件，让它在事件到来时能抢占。用uxTaskGetSystemState可以查看每个任务的状态、优先级、运行计数，排查起来比盲猜有效。
5.2 Tick频率与延时误差排查
延时不准先看configTICK_RATE_HZ。如果设的是100Hz，vTaskDelay(1)就是10ms，vTaskDelay(pdMS_TO_TICKS(1))也会变成1个Tick即10ms。想要1ms精度，Tick频率至少要1000Hz。再看有没有用pdMS_TO_TICKS，直接写vTaskDelay(10)在1000Hz下是10ms，在100Hz下是100ms。排查时可以在任务里翻转GPIO，用示波器测实际周期，也可以打印xTaskGetTickCount，观察Tick增长是否正常。
如果Tick计数本身不准，检查SysTick重装载值是否按SystemCoreClock计算。SystemCoreClock可能因为时钟配置变化而改变，比如从72MHz降到36MHz，Tick周期就会翻倍。还要检查是否有其他中断长时间关闭全局中断，导致Tick中断丢失。FreeRTOS的临界区会短暂关闭中断，但如果临界区里执行了耗时操作，Tick计数就会丢。临界区里只做最必要的操作，不要放printf、Flash写、长循环。
5.3 堆栈溢出和优先级关系
堆栈溢出和优先级没有直接因果关系，但高优先级任务堆栈溢出往往更致命。高优先级任务运行时可能正在持有互斥量、正在写关键数据，一旦溢出破坏相邻内存，可能直接死机或者进入HardFault。configCHECK_FOR_STACK_OVERFLOW设为2可以在任务切换时检查堆栈末尾的标记，发现溢出后调用vApplicationStackOverflowHook。调试阶段一定要打开这个检查，同时打开configASSERT，能提前发现很多问题。
堆栈深度单位是字，不是字节。Cortex-M3上128字就是512字节，任务里有局部数组、浮点运算、printf、sprintf时，512字节很容易不够。我的习惯是：控制任务至少256字，通信任务512字，LVGL任务1024字以上，具体看实测。还可以用uxTaskGetStackHighWaterMark查看历史最小剩余堆栈，如果高水位低于20%，就该加大堆栈。中断嵌套使用主栈，主栈大小在启动文件里定义，也要留够。
5.4 问题速查表
| 现象 | 可能原因 | 排查方法 | 解决方向 |
|---|---|---|---|
| 低优先级任务不跑 | 高优先级任务忙等 | 看高优先级任务有无阻塞 | 加vTaskDelay或等待事件 |
| vTaskDelay(100)不是100ms | Tick频率不是1000Hz | 查configTICK_RATE_HZ | 用pdMS_TO_TICKS换算 |
| 延时周期性漂移 | vTaskDelay累积误差 | 测GPIO翻转周期 | 改用vTaskDelayUntil |
| 系统随机死机 | 堆栈溢出 | 开栈溢出检测和断言 | 增大堆栈或减少局部变量 |
| 中断里调用API后断言 | 用了非FromISR接口 | 查中断函数 | 改用FromISR结尾接口 |
| 高优先级任务等锁超时 | 优先级反转 | 看共享资源保护方式 | 用互斥量而非二值信号量 |
| 串口丢包 | 中断优先级配置错误 | 查NVIC优先级和configMAX_SYSCALL | 调整中断优先级 |
| 刷屏卡顿 | LVGL任务优先级太高 | 看CPU占用和任务周期 | 降低优先级或延长周期 |
6. 参数计算与调试经验：从理论值到实测
6.1 任务执行时间、CPU占用率和Tick周期估算
CPU占用率估算很简单：单个任务CPU占用 = 任务平均执行时间 / 任务周期。比如控制任务周期10ms，平均执行3ms，占用30%；通信任务周期20ms，平均执行2ms，占用10%；LVGL任务周期30ms，平均执行5ms，占用约16.7%；日志任务周期100ms，平均执行1ms，占用1%。加起来约57.7%，再加上Tick中断开销和中断服务程序，总占用可能到65%左右。一般建议总占用不超过70%，留出余量应对突发情况。
Tick中断本身也吃CPU。假设Tick中断服务程序执行2us，1000Hz下占用0.2%；执行10us，占用1%。如果Tick频率10000Hz，10us就是10%，这就很可观了。用GPIO在Tick中断里翻转引脚，示波器测高电平时间，可以估算中断开销。也可以用vTaskGetRunTimeStats统计各任务运行时间，但需要配置一个高频定时器作为运行时间统计时钟，会额外增加一点开销。
6.2 中断优先级与任务优先级别混为一谈
Cortex-M的NVIC中断优先级数值越小，优先级越高。FreeRTOS任务优先级数值越大，优先级越高。这两个规则完全相反，很多新手在这里栽跟头。configMAX_SYSCALL_INTERRUPT_PRIORITY定义了一个阈值，中断优先级数值大于等于这个阈值的中断，才能调用FreeRTOS的FromISR API。也就是说，逻辑上优先级较低的中断才能调用FreeRTOS接口。如果中断优先级数值小于这个阈值，说明它的优先级太高，FreeRTOS无法屏蔽它，在里面调用FromISR会破坏内核临界区，系统可能崩溃。
SysTick和PendSV通常设成最低优先级，也就是数值最大。这样它们不会抢占其他中断，任务切换只会在所有中断处理完之后发生。配置CubeMX时，NVIC里的优先级分组要选对，FreeRTOS要求所有可调用FromISR的中断使用相同的抢占优先级分组。串口、定时器、DMA中断如果要调用FromISR，优先级数值必须大于等于configMAX_SYSCALL_INTERRUPT_PRIORITY，具体值在FreeRTOSConfig.h里能看到。
6.3 我常用的调试手段和避坑清单
调试FreeRTOS项目，我一般按这个顺序来：先把configUSE_TICKLESS_IDLE关掉，把configTICK_RATE_HZ设成1000，configCHECK_FOR_STACK_OVERFLOW设成2，configASSERT打开。然后给每个任务分配明确的优先级和周期，用GPIO翻转测执行时间。任务里不要用printf打印大量数据，串口输出会阻塞，影响实时性，可以用SEGGER RTT或者内存日志。如果发现任务切换异常，先看PendSV和SysTick中断优先级，再看高优先级任务有没有阻塞点。
避坑清单里还有几条：第一，vTaskDelay的参数是Tick，不是毫秒，所有毫秒延时都用pdMS_TO_TICKS。第二，二值信号量用于同步，互斥量用于保护共享资源，别用错。第三，中断里只用FromISR接口，并且检查pxHigherPriorityTaskWoken。第四，任务堆栈按字算，不是按字节。第五，相同优先级任务如果都一直就绪，时间片轮转会让执行顺序变得不那么直观，关键任务最好用不同优先级加事件驱动。第六，Tick频率不是越高越好，够用就行，高频率会增加中断负载。第七，长时间运行要关注Tick计数溢出，32位Tick在1000Hz下约49.7天溢出一次，代码里用溢出安全的比较方式。
我自己的习惯是，在系统初始化完成后打印一张任务表，列出任务名、优先级、堆栈深度、周期和阻塞对象，贴在工程注释里。后面加任务或者改优先级时，先看这张表，避免优先级冲突。实际调过几轮之后，你会发现任务优先级和Tick频率不是孤立参数，它们一起决定了系统的响应、功耗和稳定性。把这两个东西调顺了，FreeRTOS项目后面加队列、信号量、事件组都会顺手很多。
