FreeRTOS 学习笔记：任务、队列、信号量，我是这样分清的

我是电子信息在读研究生，课题做软体机器人，就业方向是嵌入式。软体机器人的控制天然是多件事并行：传感器要定时采集、驱动（气阀/电机）要按节拍输出、上位机通信不能被阻塞、异常状态要随时能打断。裸机大循环写这种系统很快就会乱，所以这学期我系统学了 FreeRTOS，把最容易混的三个概念整理一下。

1. 任务（Task）：先按“节拍”拆，不要按“功能大小”拆

拆任务的依据是周期和实时性，而不是代码量。我的习惯分法：采集类任务定周期唤醒；控制类任务被采集结果触发；通信类任务低优先级、慢慢跑；监控任务优先级最高，只负责看门狗式的异常处理。优先级给“最怕迟到的”，不是给“最重要的”。

2. 队列（Queue）：传数据本体的时候用它

采集任务和控制任务之间要传一组传感器数值，用队列最稳：发送方把结构体按值拷进去，接收方阻塞等待，天然解耦，还能靠队列长度吸收抖动。坑是队列满了怎么办要提前想好——控制场景我一般丢弃旧数据保最新，日志场景则宁可阻塞一小会儿。

3. 信号量（Semaphore）：只传“发生了”这件事的时候用它

中断里外设数据就绪、按键按下这类事件不需要带数据，二值信号量就够。中断服务函数里只能用带 FromISR 后缀的 API，这是我早期最常犯的错。另外计数信号量适合“资源池”计数，别拿它硬传数据。

4. 一个我踩过的典型坑：优先级反转

低优先级任务拿着互斥锁慢慢跑，高优先级任务等锁，中优先级任务又一直在抢 CPU，结果高优先级反而被饿死。解决办法就一句：共享资源用互斥量（带优先级继承），不要用二值信号量凑合。

小结：任务按节拍拆、数据走队列、事件走信号量、共享资源上互斥量——这四句是我目前写 RTOS 代码时的默认检查表。后面准备把软体机器人的采集+控制回路按这个结构在开发板上完整跑一遍，再来更新这篇。