企业官网建设流程全解析

1. 从“任务能跑”到“任务协作”：这一讲真正要解决的问题

上一部分我们把任务创建、删除、延时这些基础 API 过了一遍，不少朋友已经能把几个任务同时跑起来。但接下来几乎每个人都会撞到同一个问题：任务之间怎么交换数据？按键扫描任务读到的状态，如何交给显示任务去刷新；采集任务拿到的传感器原始值，怎么搬运给处理任务做滤波；线程 A 算出的结果，又如何提醒线程 B 赶紧消费。

如果任务之间不谈通信，那所谓“多任务”就只是“多个互不相关的动作并行执行”，离一个完整的系统还差关键的一步：数据通路。FreeRTOS 为开发者准备的通信机制非常明确，队列（Queue）、信号量（Semaphore）、互斥锁（Mutex）、任务通知（Task Notification）、软件定时器（Software Timer），每一类 API 面对的问题都不一样。我个人的学习顺序固定为：先队列，再信号量/互斥锁，之后是任务通知，最后看软件定时器。这个顺序背后有个很实际的原因：队列是多数通信机制的基础，很多信号量在内核里就是由队列实现的，先把队列的“数据如何被管理、如何被阻塞”想明白，后面的东西就顺了。

为什么我说第二批要重点啃队列，而不是急着研究各种花哨的调度器特性？因为真实工程很快就需要它。某个模块在中断里产生一批数据，要求尽快交到低优先级存储任务；一个任务负责采集，另一个任务负责显示，中间的数据缓冲不能互相覆盖。这些需求用单个任务 API 根本写不出来，哪怕硬写成全局变量加标志位，最后也会在时序上撞出各种烂问题。队列的存在，就是把“你等我、我等你、数据往哪放”这些细节封装好，让任务之间的衔接变得有序。

这一讲不会把所有 API 一次性列全，那样看十遍也记不住。我就挑最常用的四个方向，每个方向配一个典型用法：队列做数据搬运，信号量控制事件和资源，互斥锁保护共享资源，任务通知做轻量级提醒，软件定时器把周期动作从任务里拆出来。你跟着示例代码在自己的工程里跑一遍，用不了多长时间就能摸清每种 API 的脾气。

2. 队列 API 实操：从创建到收发，先看懂队列的“账”

2.1 创建队列前先算清内存账：容量与单元大小怎么定

队列在 FreeRTOS 里由队列控制块加一块存储区实现，最常用的动态创建版本是xQueueCreate，原型看着很简单：

QueueHandle_t xQueueCreate(UBaseType_t uxQueueLength, UBaseType_t uxItemSize);

uxQueueLength表示队列最多能装多少条数据，uxItemSize表示每条数据占多少字节。内核会在堆里一次性申请uxQueueLength * uxItemSize字节，再把队列控制块和这块存储区管理起来。所以这行代码绝不只是“登记”一个队列，它是实实在在的内存消耗。

我见过不少开发者在项目里对队列长度拍脑袋，结果调试时队列一直返回满，也不知道为什么。稳妥做法是先估算生产者的最大积压量。比如采集任务每 10 毫秒产生一条数据，显示任务每 50 毫秒消费一次，中间还可能被高优先级任务抢占，消费者偶尔会慢出一个周期，那队列长度至少要有 5 到 10 条数据的余量，再加一两个缓冲位应对瞬时抖动。每条数据多大则取决于你要传什么：只传一个 4 字节整数，uxItemSize就填sizeof(uint32_t)，不要偷懒写死 4，以后结构体改成uint16_t时容易忘。

创建返回值必须判空。我在实际调试里遇到过运行很久才偶现崩溃的案例，最后定位是某次xQueueCreate返回 NULL，后续所有发送都作用在一个空句柄上，把内存写坏了。建议创建后立刻检查：

QueueHandle_t g_queue = xQueueCreate(8, sizeof(uint32_t)); configASSERT(g_queue != NULL);

如果你的项目禁用动态内存分配，可以用xQueueCreateStatic配合静态缓冲区。静态版本没有太多神秘感，只是把存储区和控制块交由开发者提供。唯一的坑是静态控制块类型StaticQueue_t的大小在不同版本间可能有差异，建议用 FreeRTOS 提供的类型去声明，不要自己猜结构体内部字段。

2.2 发送侧：阻塞时间、FromISR 变体和“别复制大结构体”

队列发送有几个常用入口：xQueueSendToBack、xQueueSendToFront和xQueueSend。xQueueSend在多数内核版本里就是xQueueSendToBack的宏，语义是从队尾追加一条数据；xQueueSendToFront则像插队，把数据硬塞到队首。多数场合用队尾追加就够了，插队会扰乱原本的先后逻辑，要谨慎。

发送函数末尾都带一个阻塞时间参数，它的含义不是“绝对超时多少毫秒”，而是“最多等多少个时钟节拍”。如果队列此刻有空间，函数立即复制数据并返回pdTRUE；如果队列已满，任务进入阻塞状态，等这段时间里是否有空间腾出来。时间到了仍然满，就返回pdFALSE，数据被丢弃。传 0 表示不等待，队列满立即返回失败；传portMAX_DELAY表示无限期等待，前提是configINCLUDE_vTaskSuspend配置为 1。

普通任务里你要注意，xQueueSend的数据是“拷贝”进队列的。也就是说，你往队列里送一个局部变量后，这个局部变量马上可以拿去干别的，队列内部已经保存了一份副本。这其实是好事，规避了任务之间共享指针导致的竞争。但代价也随之而来：如果每条数据很大，比如一个 2KB 的结构体，每次发送都要搬一次内存，高频场景会拉高 CPU 占用。碰到大块数据，我更建议只把指针放进队列，队列的uxItemSize填sizeof(void *)，发送方分配好缓冲区后，把地址交给队列。

指针方案的代价是你要自己管理缓冲区生命周期。我的经验是“谁持有谁负责”：发送方把缓冲区地址交给接收方之后，就不该再碰它；接收方处理完再释放或归还缓冲池。否则双方同时读写同一块内存，调试起来非常头痛。

中断里发送要换一套 API，函数名末尾多一个FromISR，并且多一个BaseType_t *参数。示例如下：

void Some_IRQHandler(void) { BaseType_t xHigherPriorityTaskWoken = pdFALSE; uint32_t raw = read_sample(); xQueueSendToBackFromISR(g_dma_queue, &raw, &xHigherPriorityTaskWoken); portYIELD_FROM_ISR(xHigherPriorityTaskWoken); }

xHigherPriorityTaskWoken的用法很关键。中断发送时，如果该操作恰好唤醒了一个优先级高于当前被打断任务的阻塞任务，内核会把标志置为pdTRUE；中断退出前调用portYIELD_FROM_ISR，主动触发一次任务切换，让被唤醒的任务尽快运行。千万别图省事忽略这个标志，否则高优先级任务可能要一直等到下一个节拍中断才运行，实时性会被明显削弱。

2.3 接收侧：阻塞等待、有限超时、非阻塞轮询

接收端核心函数是xQueueReceive：

BaseType_t xQueueReceive(QueueHandle_t xQueue, void *pvBuffer, TickType_t xTicksToWait);

它把队首数据拷入pvBuffer，同时从队列中移除。pvBuffer指向的空间必须大于等于创建队列时的uxItemSize，否则很容易把栈上相邻内存写坏。我见过有人用uint16_t缓冲区去收一个uint32_t队列，结果高两位跑到栈变量之外，引发一系列神秘错误。

阻塞时间的常见玩法有三种：

• 接收任务只等这一件事：用portMAX_DELAY，让任务无限期挂起直到有数据。最适合单消费者模型，比如一个任务专门负责写文件系统，没有别的要干。
• 接收任务还要兼顾维护工作：比如 50 毫秒内没收到数据就做一次自检，那么阻塞时间写pdMS_TO_TICKS(50)，返回值是pdFALSE就说明超时，走超时分支。
• 低优先级任务顺带检查数据：传 0，有就收，没有就立即返回，不耽误后续逻辑。

还有个小众函数xQueuePeek，它只复制队首数据但不删除队项，适合“先看一眼队首是什么再决定怎么处理”的场景。它也有副作用：多个任务都做 Peek 而无消费时，队首一直占着，数据会积压。我自己用得不多，不太建议新手优先使用。

2.4 队列的常见坑：句柄作用域、内容类型与满队列

第一个坑是句柄作用域。队列句柄在哪个模块创建都行，但必须让发送方和接收方都拿到同一个值。有人把句柄放进各自函数的局部变量里，结果两边完全不是同一个队列；有人把句柄放进结构体，不小心又被拷贝了一份，同样造成两份“独立队列”。我通常把通信对象集中在顶层模块统一创建，存入全局结构体，再作为参数传给各任务入口，这样句柄生命周期清晰，排查时也能一眼看到所有对象的创建顺序。

第二个坑是内容类型理解不到位。队列内部只管字节拷贝，它不关心你传的是 int 还是指针。发送侧填的uxItemSize和接收侧pvBuffer大小必须严格匹配，收到数据的解释方式完全依赖代码约定。当队列单元是结构体时，拷贝结构体内部的指针意义不大，除非你确认指针指向的区域足够稳定且所有任务都遵守访问协议。

第三个坑与优先级有关。如果多个发送者往同一个队列写数据，阻塞时间会叠加。高优先级任务把队列写满后进入阻塞，低优先级任务迟迟不接收，高优先级任务就会一直被拖住。这种情况要么把队列加长，要么考虑满队列时把高优先级任务的数据插到队首，但后者会破坏公平性，我更推荐前者，不要在工程里制造过多特殊路径。

3. 信号量与互斥锁：看着相似，选错就会出现优先级反转

3.1 二值信号量和互斥锁到底差在哪

先给结论：保护共享资源优先使用互斥锁，通知“发生了一件事”使用二值信号量。两者在 FreeRTOS 里都叫SemaphoreHandle_t，创建函数长得也很像，但语义完全不同。

二值信号量本质上是一把“只允许一个用户使用”的钥匙，它不关心谁拿走了钥匙。任务 A 可以 Give，任务 B 可以 Take，中断里 Give、任务里 Take 也很正常。所以它更适合做事件通知：中断发生时 Give 一次，等待任务 Take 到之后立即处理事件。

互斥锁则带有明确的所有权概念。xSemaphoreTake成功后，锁被当前任务持有，直到同一个任务再次调用xSemaphoreGive，其他任务才可能拿到。如果任务 B 在没持有锁的情况下 Give，返回值通常是pdFALSE，逻辑上也不会把别人拥有的锁释放掉。这种所有权设计是为了实现优先级继承：当一个低优先级任务持有互斥锁、而高优先级任务正在等待该锁时，内核会把低优先级任务临时提升到与高优先级任务相同的优先级，让它尽快运行并释放锁，从而减少高优先级任务被无限期拖住的时间。

二值信号量没有这种继承机制。我在某次设备项目里曾用二值信号量保护串口打印，平时一切正常，但有一次低优先级任务先拿到锁开始打印时，一个高优先级任务也在等待打印，随后一个中等优先级任务不断抢占 CPU，把低优先级任务压得无法运行，锁迟迟不能释放，高优先级任务也就一直等下去。这就是典型的优先级反转。换成互斥锁之后，低优先级任务在等待期间被临时抬高，能够快速打印完并释放锁，问题随即消失。

所以我的建议很直白：共享资源保护一律优先互斥锁，事件提醒用二值信号量。不要因为二值信号量创建代码短，就拿它当万能锁。另外，互斥锁不能用于中断服务程序，因为中断里没有“任务持有锁”的上下文，中断侧要提醒任务，应选用计数信号量或任务通知。

3.2 计数信号量的两种典型用法：事件计数与资源池

计数信号量创建使用xSemaphoreCreateCounting(uxMaxCount, uxInitialCount)。第一个参数是计数上限，第二个参数是初始可用数量。它常用在两类场景。

一类是把信号量当作“可累计的事件计数器”。比如外部中断每分钟产生多次随机事件，ISR 每次xSemaphoreGiveFromISR一次，任务不定时去xSemaphoreTake。如果任务正在处理上次事件，中间又来了三次中断，计数值会加到 3，任务处理完一次后接着 Take 第二次，事件不会被丢失。这比二值信号量更适合“中断比任务快”的情况。

另一类是资源池保护。假设系统只有 3 个 DMA 通道可供任务申请，创建时uxMaxCount = 3、uxInitialCount = 3。任务申请通道时xSemaphoreTake，用完后xSemaphoreGive归还。Take 成功意味着拿到一个空闲通道，计数减一；Give 把计数加一。计数值的变化正好对应资源余量，语义很直观。

不过计数信号量不会记住“哪次 Give 对应哪次 Take”，它只表达数量契约。如果某个任务错误地连续 Give 两次，计数值就会虚高，别人会误以为有资源可用。因此调试阶段我习惯打印当前计数值，观察它是否与业务预期一致，比如每秒事件数是否匹配，是否有异常增长。

3.3 递归互斥锁：什么时候你会“自己锁自己”

普通互斥锁有一个容易踩的坑：同一个任务在持有锁的情况下，调用了一个也去 Take 同一把锁的函数，会立刻把自己锁死。这不是 FreeRTOS 的缺陷，而是互斥锁的非递归特性决定的。

举个例子。你写了reg_write()，为避免并发冲突，每次写寄存器前都xSemaphoreTake(g_hw_lock)。然后你又写了个update_chip()，它先 Take 同一个锁，再依次调用两次reg_write()。结果update_chip持有锁后，reg_write再次 Take 同一把锁，当前任务进入阻塞等待，永远等不到自己释放锁，死锁就发生了。

解决办法有两个。一是约定“锁内不再调用带锁的函数”，把公共函数拆成加锁版本和无锁版本，但容易漏改。二是直接用递归互斥锁，创建函数是xSemaphoreCreateRecursiveMutex，获取和释放也要用xSemaphoreTakeRecursive和xSemaphoreGiveRecursive。递归锁允许同一任务重复获取，但每次 Take 都要对应一次 Give，计数值归零才算真正释放。

递归锁也不是用来无脑替代普通锁的。它多占计数开销，语义上还容易掩盖模块边界分层不清的问题。如果项目里到处出现递归锁，我更建议先检查是不是嵌套层级太深，而不是急着换锁类型。

下面这张表是我日常选型时常用的对照：

4. 任务通知：更快更轻，但边界条件必须看清

4.1 xTaskNotifyGive 和 ulTaskNotifyTake 的配合

很多开发者一说到通信就只能想到队列和信号量，其实 FreeRTOS 还有一套更轻的内建机制：任务通知。它不像队列那样需要单独分配存储区，而是直接使用每个任务控制块里预留的通知值和通知状态。因此它的速度通常比信号量更快，在中断里使用尤其方便。

最基础的两个 API 是vTaskNotifyGiveFromISR（或xTaskNotifyGive）和ulTaskNotifyTake。中断侧示例：

static TaskHandle_t h_event_task; void EXTI_ISR(void) { BaseType_t xHigherPriorityTaskWoken = pdFALSE; vTaskNotifyGiveFromISR(h_event_task, &xHigherPriorityTaskWoken); portYIELD_FROM_ISR(xHigherPriorityTaskWoken); }

对应任务侧：

void event_task(void *param) { for (;;) { ulTaskNotifyTake(pdTRUE, portMAX_DELAY); handle_one_event(); } }

ulTaskNotifyTake第一个参数pdTRUE表示“退出后把通知计数清零”，pdFALSE表示保留计数。这个参数非常关键：如果连续来了两件事，任务处理第一次时计数被清零，第二次事件信息就丢了；如果你想记录“总共触发了多少次”，又用了pdTRUE，事件也会被覆盖。反过来，如果希望不丢事件就要用pdFALSE，但处理逻辑会复杂许多，因为你很难区分“刚刚发生”和“之前残留”。

大多数中断唤醒场景用pdTRUE就够了，因为任务每次被唤醒就处理一次最新事件。如果你真的要统计中断次数，不如在 ISR 里维护一个uint32_t计数器变量，把数值通过队列或共享变量交给任务，这样不容易产生歧义。

4.2 任务通知到底有哪些硬边界

任务通知的本质是“单车道”：一个任务只能被指定任务通知，不能被一组任务同时通知。它不具备广播能力。想让一个中断同时唤醒三个任务，只能遍历句柄逐个GiveFromISR，或者换用事件组 API。

另外，通知值只有 32 位。你可以存位掩码，也可以拿它当计数，但没法把任意结构体数据塞进去。所以它适合表达“有没有事情发生”这种信号，不适合搬运数据。要传一块采样数据、一批坐标点，还得用队列。

还有一个容易混淆的点：通知的等待是基于单个接收任务的。多个任务同时调用ulTaskNotifyTake等同一个通知时，谁等谁不等，内核不会帮你排队，因为通知本来就是发给指定任务句柄的。所以别把任务通知当成多消费者模型来设计。多生产者、多消费者或需要维护顺序的场景，队列才是正确选型。

4.3 什么时候优先选任务通知

我的经验是，在中断唤醒高频任务、按键去抖后的事件提醒、周期采集的“数据到了”信号等场景，任务通知非常好用，代码量比队列少，也没有额外内存分配。尤其是中断频率高、又希望任务快速响应的场合，通知比信号量更值得推荐。

但如果你有多个不同事件需要区分，或者要携带数据，通知就不方便。下面列一个简单对比：

5. 软件定时器：把周期动作从任务里拆出来，但回调不是任务

5.1 xTimerCreate 的关键参数与启动方式

软件定时器非常适合做周期性“小事”，比如每 500 毫秒翻转一次 LED、每 100 毫秒检查一次外部超时、定期喂一次看门狗。它不需要专门创建一个任务，也不需要写for(;;) + vTaskDelay。FreeRTOS 的软件定时器由内核里的一个“守护任务”统一管理，所有到期回调都在守护任务上下文执行。

创建函数是xTimerCreate：

TimerHandle_t xTimerCreate(const char *pcTimerName, TickType_t xTimerPeriodInTicks, UBaseType_t uxAutoReload, void *pvTimerID, TimerCallbackFunction_t pxCallbackFunction);

第二个参数是周期 tick 数，通常用pdMS_TO_TICKS转换。第三个参数uxAutoReload填pdTRUE表示周期重复，填pdFALSE表示只触发一次。pvTimerID可以挂一个应用自定义 ID，用于区分不同定时器。最后一个参数是回调函数地址。

创建后必须显式启动，定时器才会跑：

TimerHandle_t g_watchdog_timer; void vWatchdogCallback(TimerHandle_t xTimer) { feed_the_watchdog(); } void app_init(void) { g_watchdog_timer = xTimerCreate("wd", pdMS_TO_TICKS(1000), pdTRUE, NULL, vWatchdogCallback); if (g_watchdog_timer != NULL) { xTimerStart(g_watchdog_timer, 0); } }

xTimerStart第二个参数是发送启动命令时最多等多少个节拍。因为启动请求是通过命令队列交给守护任务的，如果命令队列暂时占满，这里的阻塞时间就起作用。初始化阶段一般传 0 就行。

5.2 回调为什么不能做“重”操作

这是软件定时器最容易踩坑的地方。回调并不运行在创建定时器的那条普通任务栈上，而是运行在守护任务上下文。如果你在回调里调用vTaskDelay、xSemaphoreTake(..., portMAX_DELAY)、xQueueReceive(..., portMAX_DELAY)，整个守护任务都会被阻塞，所有软件定时器的到期回调都会被卡住。等于一个定时器干了重活，把其他定时器也拖下水。

我之前在某仪表项目里就踩过一次：定时器回调里直接写 EEPROM，而 EEPROM 驱动内部用信号量等待硬件操作完成，结果回调被阻塞，看门狗定时器到期后回调迟迟不能执行，系统陷入连锁等待。后来改成回调只置一个“需要写盘”标志，由普通任务通过队列接收标志后执行写入，问题就消失了。

请务必记住：软件定时器回调里只适合极短操作，比如置标志位、计数、给信号量、往队列塞几个字节。需要长时间执行的工作，任何时候都该回到真正的任务里去做。

5.3 精度真相：它是“软”的，不是硬件定时器

软件定时器的精度上限取决于节拍频率configTICK_RATE_HZ。如果系统节拍是 100Hz，它能分辨的最小周期就是 10 毫秒，你不可能得到比一个节拍更细的粒度。节拍提到 1000Hz 后，1 毫秒才有可能，但更高的节拍也意味着每秒更多次中断和调度开销。

即使系统没有阻塞，回调的实际触发时刻也会受守护任务调度误差影响，比如某个高优先级任务正在长占 CPU，回调就可能延后。这不是 bug，是软件定时器的特性，要获得硬实时精度只能用硬件定时器。所以选型时别把软件定时器当成高精度定时源，它更适合做“周期事件”而非“精确时间基准”。

6. 把它们拼起来：一个采集、通知、排队与喂狗的综合示例

6.1 整体结构：传感器中断、采集任务、处理任务与看门狗

概念讲再多，不如一个组合示例。假设有一台小型采集设备，外部传感器通过一个边沿中断通知系统“有数据可读”，中断发生后由采集任务去读取，再放进队列，处理任务负责消费并写入缓存；另外还有一个软件定时器负责周期性喂狗。

这条链路的传递方式是：中断用任务通知唤醒采集任务，采集任务用队列把数据交给处理任务，软件定时器用回调周期喂狗。整体初始化大致如下：

static TaskHandle_t h_acquire_task; static TaskHandle_t h_process_task; static QueueHandle_t s_data_queue; static TimerHandle_t s_watchdog_timer; void Sensor_IRQHandler(void) { BaseType_t xHigherPriorityTaskWoken = pdFALSE; vTaskNotifyGiveFromISR(h_acquire_task, &xHigherPriorityTaskWoken); portYIELD_FROM_ISR(xHigherPriorityTaskWoken); } static void vAcquireTask(void *param) { uint32_t sample; for (;;) { ulTaskNotifyTake(pdTRUE, portMAX_DELAY); sample = read_sensor_reg(); if (xQueueSend(s_data_queue, &sample, 0) != pdTRUE) { log_queue_full(); } vTaskDelay(pdMS_TO_TICKS(2)); } } static void vProcessTask(void *param) { uint32_t sample; for (;;) { if (xQueueReceive(s_data_queue, &sample, pdMS_TO_TICKS(50)) == pdTRUE) { update_frame_buffer(sample); } else { do_periodic_check(); } } } static void vWatchdogCallback(TimerHandle_t xTimer) { feed_watchdog(); } void app_init(void) { s_data_queue = xQueueCreate(8, sizeof(uint32_t)); s_watchdog_timer = xTimerCreate("wd", pdMS_TO_TICKS(500), pdTRUE, NULL, vWatchdogCallback); xTimerStart(s_watchdog_timer, 0); xTaskCreate(vAcquireTask, "acq", 256, NULL, 3, &h_acquire_task); xTaskCreate(vProcessTask, "proc", 256, NULL, 2, &h_process_task); }

这段代码可以直接搬进自己的实验工程跑。注意采集任务优先级要高于处理任务，这样中断唤醒后能尽快读取并清掉硬件中断标志。如果反过来，中断把低优先级任务唤醒，而高优先级处理任务在等数据，调度顺序会变复杂，实时性反而不清晰。

6.2 运行时如何验证：vTaskList 和 StackHighWaterMark

系统跑起来以后，怎么确认任务协作正常？屏幕不亮、数据不对时，靠肉眼很难定位。一个简单又有效的办法是开启 FreeRTOS 的状态统计功能，周期性调用vTaskList，把输出打印到调试串口。

vTaskList需要同时开启configUSE_TRACE_FACILITY和configUSE_STATS_FORMATTING_FUNCTIONS，它会把每个任务的名字、状态、优先级、剩余栈空间等信息格式化到缓冲区。常见状态有 Running、Ready、Blocked、Suspended。如果某个任务长期处于 Ready 状态，且不是最低优先级，说明它没有在等待任何事件，可能在空转；如果任务长期 Blocked，而对应事件始终不发生，就要怀疑中断服务程序是否真的触发了，或者通知/队列句柄是否传错了。

栈空间也不能等崩了才看。我在调试时习惯在任务初始化一段时间后，打印一次uxTaskGetStackHighWaterMark(handle)，它返回“这个任务历史上剩余栈空间最少的那次还剩多少字”。如果返回值接近 0，说明任务曾一度逼近栈溢出。栈溢出后果可能是随机的，有时表现为变量被莫名改写，有时直接死机，所以提前打一条高水位数据能避免很多玄学问题。

除了这些，还可以给自己留一个调试计数器。比如采集任务里发现队列满时，用一个全局变量记录满的次数，显示任务或串口命令可以读取这个值。如果满的次数增长很快，说明队列长度不够或处理任务被其他高优先级任务抢占了太久。这个法子成本很低，但往往能最快暴露系统吞吐瓶颈。

6.3 我在若干次调试中总结的三个最值得注意的问题

第一，二值信号量不适用于共享资源保护。我多次遇到高优先级任务被低优先级无限拖住的现象，改用互斥锁后迅速好转。如果你现在系统里正是用二值信号量保护临界区，又出现高优先级被拖慢，优先怀疑这一条。

第二，定时器回调里别做阻塞操作。这个坑比较隐蔽，现场通常表现为“某个软件定时器没按预期执行”，很难想到问题出在另一个定时器回调里。排查思路是：先把所有回调里的阻塞调用注释掉，再看其它定时器是否恢复正常。如果是，就说明回调干重活了，赶紧把重活移回普通任务。

第三，任务通知的计数模式一定要按“是否真的需要统计次数”来选。把pdFALSE用在一次性提醒场景，会觉得任务被多余唤醒了几次；把pdTRUE用在需要计数的场景，又会觉得事件被吞掉了。这两种情况我都遇到过，每次都是回到 API 手册重新把参数含义过一遍才想明白。

这三个问题解决后，那个采集示例基本能稳定跑很久。我更建议你把队列、信号量、互斥锁这些通信对象统一创建、统一命名，并在调试串口里随时查询使用状态。这样后续哪怕功能越来越复杂，也不至于被通信逻辑绕得晕头转向。