用FreeRTOS做项目时，容易踩坑的地方

关注+星标公众号，不错过精彩内容

作者 | strongerHuang

微信公众号 | strongerHuang

虽然FreeRTOS经过这么多版本的迭代，已经非常完善了，但如果长时间用FreeRTOS做项目，其实也有很多“坑”。

当然，这里说的“坑”并不是FreeRTOS自身的缺陷，而是我们作为开发者，使用它的时候，容易犯一些低级的错误，或者你对FreeRTOS原理或机制不是很了解，导致容易踩坑。

今天简单分享一些FreeRTOS做项目时，常见的容易踩坑的地方。

一、中断易踩坑区

1.中断优先级配置错误：在 Cortex-M 等处理器上，数值越小的优先级，逻辑优先级越高。

如果调用了 FreeRTOS API 的中断优先级数值小于 configMAX_SYSCALL_INTERRUPT_PRIORITY，内核的临界区将失效，导致系统随机崩溃。务必确保此类中断的优先级数值大于等于该宏定义值。

2.在中断（ISR）中调用非 FromISR 版本的 API：你会发现FreeRTOS中有很多API带有后缀FromISR的接口，这种只能在中断里面调用。比如队列发送 xQueueSendFromISR。

比较典型的就是串口中断接收到一包数据，通过队列发送出去，此时就需要调用xQueueSendFromISR这个接口。而有些人调用xQueueSend这个API，这是最直接的错误。

在中断服务程序（ISR）中，只能调用以 FromISR 结尾的 API 函数。调用 xQueueSend、xSemaphoreGive 等非 ISR 版本可能导致断言失败或系统挂起。

3.忘记触发上下文切换：在 ISR 中调用 FromISR 函数后，如果唤醒了更高优先级的任务，必须调用 portYIELD_FROM_ISR()（或类似宏）来请求切换。否则，高优先级任务要等到下一个 Tick 才能运行，导致实时性丧失。

4.ISR 执行时间过长：在中断（ISR）函数里，执行时间应尽可能短，只做“标记事件”或“发送通知”。将耗时逻辑（如复杂计算、字符串处理）放在任务中执行，否则会阻塞其他中断和任务调度。

有些人在中断服务程序中运行一些加解密算法、甚至阻塞延时，这些都是错误的做法。

二、任务中易踩坑区

1.任务栈空间分配不足：任务栈用于存放局部变量、函数调用和上下文。最容易低估的是库函数（如 printf、sprintf、浮点运算）的栈消耗。

建议开启 configCHECK_FOR_STACK_OVERFLOW，并使用 uxTaskGetStackHighWaterMark() 监控栈的使用高峰，据此调整栈大小。

2.任务优先级设置不当：高优先级的任务，如果一个不主动阻塞（如不使用 vTaskDelay、xQueueReceive），则该任务的会一直占用（独占） CPU，导致低优先级任务“饿死”，系统表现为“死机”。

所以，高优先级的任务，处理完当下事务之后，需要系统延时（如vTaskDelay）或等待（如xQueueReceive），使其让出CPU，确保低先级任务得到执行。

3.任务函数意外返回：FreeRTOS 任务函数绝不能像普通函数那样 return。

如果某一个任务需要结束，应调用 vTaskDelete 删除该任务。

4.在 main() 函数中定义大量局部变量：调度器启动后，main() 的栈可能被复用或覆盖，其中定义的变量会变得不可靠。如果确实需要这些变量，建议使用全局变量或动态分配。

三、同步与互斥中易踩坑区

1.互斥量（Mutex）绝不能用于 ISR。它的优先级继承机制在中断上下文中无法工作，且其“获取/释放”必须成对出现在任务中。

在 ISR 中应使用二值信号量（Semaphore）来同步。如果中断发生速度快于任务处理速度，二值信号量（其状态只有“有”和“无”）会丢失中间事件。例如，中断连续触发 5 次，但任务只来得及处理 1 次。对于此类场景，应使用计数信号量或任务通知。

2.优先级反转（Priority Inversion）：当高优先级任务等待低优先级任务持有的互斥量时，如果中间优先级的任务就绪，会抢占低优先级任务，导致高优先级任务被“无限期”延迟。

FreeRTOS 的互斥量提供优先级继承来缓解此问题，但该机制是“简化的”，在嵌套使用多个互斥量时可能失效。最佳实践是从设计上避免优先级反转，例如使用“看门人任务”（Gatekeeper Task）统一管理资源访问。

四、软件定时器中易踩坑区

1.在回调函数中执行耗时操作或调用阻塞 API：软件定时器的回调函数运行在定时器服务任务的上下文中。绝对不能在其中调用 vTaskDelay、xQueueReceive 等阻塞函数，也不能执行耗时过长的逻辑，否则会阻塞整个定时器服务任务，导致其他定时器全部延迟或系统崩溃。

2.回调函数执行时间超过定时周期：如果一个自动重载定时器的回调执行时间大于其周期，会产生“追赶效应”，导致定时器命令队列堆积，最终可能耗尽内存或导致系统异常。

3.定时器周期计算溢出：使用 pdMS_TO_TICKS() 将毫秒转换为 Tick 时，如果定时时间很长（如 10 分钟），在 16 位 Tick 计数器上可能发生溢出，导致定时器立即触发。需确保系统使用 32 位 Tick 计数。

五、临界区易踩坑区

1.在 ISR 中使用 taskENTER_CRITICAL()：该宏仅能在任务中使用。在 ISR 中应使用 portSET_INTERRUPT_MASK_FROM_ISR() 和 portCLEAR_INTERRUPT_MASK_FROM_ISR() 来管理中断屏蔽。

2.在调度器启动前调用需要临界区的 API：在 vTaskStartScheduler() 之前，内核尚未完全初始化，此时调用某些需要进入临界区的 API（如创建某些内核对象）可能会破坏中断使能状态，导致调度器启动后系统异常。

------------ END ------------