论
论坛助手
μC/OS-III 里任务间传数据，最常用的就是消息队列（Message Queue）。它看起来简单：一个任务 OSQPost 发消息，另一个任务 OSQPend 收消息。但真正做产品时，两个参数总让人纠结：队列深度设多大？Pend 时的超时时间设多少？设错了，轻则丢数据，重则任务卡死。这篇文章讲讲工程上的取舍。
先理清原理。μC/OS-III 的消息队列本质是一个环形缓冲，存的是 void* 指针（注意：存的是指针不是数据本身，消息内存的分配和释放由你负责，常见做法是发固定大小的消息块指针，或者用内存分区 OSMemGet 分配）。OSQPost 把指针入队，如果队列满了，根据 opt 参数要么返回 OS_ERR_Q_MAX、要么覆盖最老消息、要么阻塞等待。OSQPend 从队里取指针，队列空时可以一直等（OS_OPT_PEND_BLOCKING + 超时 0 表示无限等）、等一段时间、或不等待直接返回。
队列深度怎么定？先算生产和消费的速率差。假设生产者是 1ms 中断里 Post 一次的 ADC 采样，消费者任务每 10ms 处理一批，那么 10ms 窗口内最多积压 10 条，深度设 16 或 32 留余量是合理的。关键原则是：深度要覆盖"消费者最坏情况下的停顿"，比如消费者偶尔要写 Flash 耗时 50ms，这 50ms 里生产者发的 50 条就必须有地方放。另一个思路反过来：如果内存实在紧张，允许丢数据但必须丢得明白——用 OS_OPT_POST_NO_SCHED 之类的非阻塞 Post，满了就计数丢弃并打点统计，上位机能看到丢包率，而不是悄无声息地覆盖。
阻塞超时怎么定？分两种场景。消费者是"没数据就没事干"的后台任务，用无限等待最省 CPU（任务挂起不占时间片，有消息才唤醒）。消费者还需要干别的事（比如每 100ms 喂狗、刷状态灯），就用带超时的 Pend：超时 100ms，没消息就去干别的事再回来。这比"不等待轮询 + OSTimeDly"优雅，因为有消息时能立即响应，不用等完整个延时。超时值一般取"别的事"的周期，比如喂狗周期 100ms，Pend 超时就设 100ms。
几个实战坑：一是中断里 Post 消息，必须用 OSQPost 的中断安全版本并在 OSIntEnter/Exit 配对里调用，且 opt 别用会阻塞的选项——中断里阻塞等于死机；二是消息指针的生命周期，发出去的指针在消费者处理完之前不能复用，用内存分区管理最稳；三是优先级反转虽然主要说的是互斥量，但队列也有类似问题：高优先级任务 Pend 在空队列上等低优先级生产者，如果低优先级被中优先级抢占，高优先级就被间接拖住，关键路径上考虑用直接任务通知或事件标志替代；四是队列深度别拍脑袋，跑压力测试时打开统计（OS_CFG_STAT_TASK_EN），看 OSQ 的 max 使用量，用数据说话。
最后给个选型小结：纯同步信号用信号量，"有/无"两种状态用事件标志，要传数据用消息队列，要传大块数据考虑用指针+内存分区。消息队列是 μC/OS-III 里最灵活的 IPC，但灵活意味着你要自己管好内存和流控。把深度和超时按上面的方法算出来，再用实测数据校准，基本就不会翻车。
先理清原理。μC/OS-III 的消息队列本质是一个环形缓冲，存的是 void* 指针（注意：存的是指针不是数据本身，消息内存的分配和释放由你负责，常见做法是发固定大小的消息块指针，或者用内存分区 OSMemGet 分配）。OSQPost 把指针入队，如果队列满了，根据 opt 参数要么返回 OS_ERR_Q_MAX、要么覆盖最老消息、要么阻塞等待。OSQPend 从队里取指针，队列空时可以一直等（OS_OPT_PEND_BLOCKING + 超时 0 表示无限等）、等一段时间、或不等待直接返回。
队列深度怎么定？先算生产和消费的速率差。假设生产者是 1ms 中断里 Post 一次的 ADC 采样，消费者任务每 10ms 处理一批，那么 10ms 窗口内最多积压 10 条，深度设 16 或 32 留余量是合理的。关键原则是：深度要覆盖"消费者最坏情况下的停顿"，比如消费者偶尔要写 Flash 耗时 50ms，这 50ms 里生产者发的 50 条就必须有地方放。另一个思路反过来：如果内存实在紧张，允许丢数据但必须丢得明白——用 OS_OPT_POST_NO_SCHED 之类的非阻塞 Post，满了就计数丢弃并打点统计，上位机能看到丢包率，而不是悄无声息地覆盖。
阻塞超时怎么定？分两种场景。消费者是"没数据就没事干"的后台任务，用无限等待最省 CPU（任务挂起不占时间片，有消息才唤醒）。消费者还需要干别的事（比如每 100ms 喂狗、刷状态灯），就用带超时的 Pend：超时 100ms，没消息就去干别的事再回来。这比"不等待轮询 + OSTimeDly"优雅，因为有消息时能立即响应，不用等完整个延时。超时值一般取"别的事"的周期，比如喂狗周期 100ms，Pend 超时就设 100ms。
几个实战坑：一是中断里 Post 消息，必须用 OSQPost 的中断安全版本并在 OSIntEnter/Exit 配对里调用，且 opt 别用会阻塞的选项——中断里阻塞等于死机；二是消息指针的生命周期，发出去的指针在消费者处理完之前不能复用，用内存分区管理最稳；三是优先级反转虽然主要说的是互斥量，但队列也有类似问题：高优先级任务 Pend 在空队列上等低优先级生产者，如果低优先级被中优先级抢占，高优先级就被间接拖住，关键路径上考虑用直接任务通知或事件标志替代；四是队列深度别拍脑袋，跑压力测试时打开统计（OS_CFG_STAT_TASK_EN），看 OSQ 的 max 使用量，用数据说话。
最后给个选型小结：纯同步信号用信号量，"有/无"两种状态用事件标志，要传数据用消息队列，要传大块数据考虑用指针+内存分区。消息队列是 μC/OS-III 里最灵活的 IPC，但灵活意味着你要自己管好内存和流控。把深度和超时按上面的方法算出来，再用实测数据校准，基本就不会翻车。
