FreeRTOS 任务优先级不是越高越重要

优先级描述的是调度紧迫性

FreeRTOS 的高优先级并不等于“业务上更重要”。调度器只关心当前有哪些任务处于就绪态，并优先运行数值更高的任务。真正应该获得高优先级的，是具有短响应期限、缓冲区可能溢出或会阻塞下游链路的工作。

例如，串口接收数据若不能及时从 DMA 缓冲区取走，后续字节可能覆盖旧数据；而 OLED 刷新即使晚几十毫秒，通常也不会破坏系统状态。前者比后者更需要及时调度。

先列出任务的时间属性

创建任务前，可以为每个功能记录：

触发方式：周期、事件、中断通知或队列消息。
最迟响应时间。
单次最坏执行时间。
是否允许被打断。
是否等待外设或共享资源。
输入积压后会发生什么。

没有这些信息时，给任务分配优先级只能依赖直觉。任务越多，直觉越容易产生“全部提高一级”的循环，最终失去层次。

一个实用的优先级分层

小型 STM32 系统可以先按性质分层，再根据测量结果调整：

高：短时限的数据搬运、控制闭环、必须及时处理的通知
中：协议解析、状态估计、业务状态机
低：显示刷新、日志整理、统计和后台维护
空闲：清理、低优先级诊断或由 Idle Hook 完成的工作

同一层不一定需要不同优先级。任务数量少、阻塞关系明确时，减少优先级等级反而更容易分析。

周期任务使用 vTaskDelayUntil

普通 vTaskDelay() 表示从当前时刻延迟一段时间，任务本身的执行时间会累计到周期中。稳定的周期任务更适合使用 vTaskDelayUntil()：

void ControlTask(void *argument)
{
    TickType_t last_wake = xTaskGetTickCount();

    for (;;) {
        ReadSensors();
        UpdateController();
        ApplyMotorOutput();
        vTaskDelayUntil(&last_wake, pdMS_TO_TICKS(10));
    }
}

如果任务执行时间超过 10 ms，延时函数不会自动修复超期。系统仍需要记录执行时间或超期计数，确认控制任务是否满足周期要求。

事件任务应该主动阻塞

任务等待队列、通知、信号量或事件组时，应进入阻塞态，而不是循环检查标志位：

void ProtocolTask(void *argument)
{
    ProtocolFrame frame;

    for (;;) {
        if (xQueueReceive(protocol_queue, &frame, portMAX_DELAY) == pdPASS) {
            ParseAndDispatch(&frame);
        }
    }
}

阻塞任务不占用 CPU 时间。持续轮询即使优先级较低，也会增加功耗、干扰空闲任务，并让调度波形充满无意义的切换。

ISR 只做必须立即完成的工作

中断中应读取状态、搬运少量数据并通知任务，复杂协议解析、日志格式化和控制计算应放到任务上下文。

void USART_IRQHandler(void)
{
    BaseType_t higher_priority_woken = pdFALSE;
    const uint8_t byte = USART_ReadByte();

    xStreamBufferSendFromISR(
        rx_stream,
        &byte,
        sizeof(byte),
        &higher_priority_woken);

    portYIELD_FROM_ISR(higher_priority_woken);
}

从 ISR 调用的 FreeRTOS API 必须使用 FromISR 版本。还要确认中断优先级满足 FreeRTOS 的配置限制，否则系统可能在高负载下出现难以复现的异常。

用所有权减少共享资源

相比让多个任务直接操作同一个 UART、I2C 或文件系统，更稳妥的方法是让单一任务拥有外设，其他任务通过队列提交请求。

这种结构的优点是：

外设访问天然串行化。
超时、重试和错误统计集中处理。
不需要在多个调用点重复加锁。
调试时能够看到完整请求顺序。

互斥量仍然有价值，但所有权设计通常比增加更多锁更容易维护。

二值信号量不能替代互斥量

互斥量带有优先级继承机制。当低优先级任务持有资源、高优先级任务等待该资源时，低优先级任务可以临时提升优先级，减少被中优先级任务长期抢占的风险。

二值信号量主要用于事件同步，不提供相同的资源所有权语义。用于保护共享资源时，应优先选择互斥量，并确保持锁时间足够短。

临界区只保护最小原子操作

关闭中断会影响整个系统的响应时间。临界区内不应执行：

字符串格式化和大块内存复制。
串口发送等待。
Flash 擦写。
传感器转换等待。
可能阻塞的 FreeRTOS API。

临界区只用于无法通过原子访问、队列或互斥量解决的极短共享操作。进入临界区前应能说明它保护了哪一个具体不变量。

队列长度不能凭感觉设置

队列容量取决于生产速率、消费任务最坏延迟和允许丢失策略。队列过短会在突发数据时溢出；队列过长会占用 RAM，并把处理延迟隐藏成大量积压。

系统应记录发送失败次数和历史峰值。若队列持续接近满载，应该分析消费者执行时间和优先级，而不是只把队列扩大。

对于连续字节流，Stream Buffer 或 DMA 环形缓冲通常比逐字节队列更合适；对于固定结构消息，队列更清晰。

栈和堆必须测量

每个任务栈都占用有限 RAM。栈太小会破坏内存，栈太大又会挤压其他任务。可以使用高水位接口记录任务历史最小剩余栈：

UBaseType_t words_left = uxTaskGetStackHighWaterMark(task_handle);

测量应覆盖最复杂路径，例如最长日志、错误处理和最大嵌套调用。仅在系统空闲时读取一次高水位，不能代表真实最坏情况。

同时应启用栈溢出钩子和 malloc 失败钩子，并让故障进入可观察状态，例如记录任务名、错误码或触发受控复位。

看门狗要监督系统进展

每个任务各自喂狗会掩盖局部死锁。更可靠的做法是由监督任务检查关键任务是否在限定时间内更新心跳，再统一喂硬件看门狗。

心跳不能只表示任务仍被调度，还应表示它完成了关键工作。例如通信任务应在成功处理帧或确认链路状态后更新，而不是每次进入循环都更新。

如何验证优先级设计

至少在以下场景下记录调度和统计数据：

正常周期运行。
串口或网络突发输入。
显示、日志和存储同时工作。
外设超时或返回错误。
队列接近满载。
CPU 负载升高和任务执行时间变长。

关注任务运行时间、最大响应延迟、队列峰值、丢包计数、最小剩余栈和看门狗状态。优先级应根据这些数据调整，而不是只看系统“暂时没有卡死”。

常见问题与定位顺序

高优先级任务占满 CPU：检查是否缺少阻塞等待。
低优先级任务长期不运行：检查高优先级任务执行时间和时间片配置。
偶发死锁：列出锁获取顺序，检查嵌套互斥量。
中断后任务不立即运行：检查 FromISR API、唤醒标志和中断优先级。
队列偶尔溢出：记录生产速率、消费延迟和峰值，而不是直接扩大容量。
运行一段时间后崩溃：优先检查栈高水位、数组边界和动态内存。

验收清单

每个任务的触发方式、周期、最坏执行时间和截止要求有记录。
周期任务使用稳定的周期基准，事件任务处于阻塞等待。
ISR 只完成最小工作，并使用正确的 FromISR 接口。
外设和共享数据具有明确所有者。
临界区和持锁时间足够短。
队列峰值、丢包、栈高水位和执行时间可观测。
看门狗能够发现任务失去进展，而不是被任意任务单独喂养。