3、任务优先级基本概念：优先级定义、抢占式与非抢占式调度、优先级反转及其影响
TinyML 设备通常搭载单核 MCU（如 Cortex-M0+/M4 系列），运行内存仅几十 KB，却需要同时完成传感器数据采集、推理计算和无线通信三类任务。任务优先级设计直接决定系统在资源受限条件下的实时性与可靠性。本章从优先级定义出发，系统讲解抢占式与非抢占式调度的差异、优先级反转的成因与危害，并结合 TinyML 典型场景给出可落地的优先级配置策略。
3.1 优先级定义：从任务属性到调度等级
在 TinyML 系统中，优先级是调度器决定"哪个任务先运行"的唯一依据。优先级通常用整数表示，数值越小优先级越高（或相反，取决于 RTOS 实现）。FreeRTOS 中数值越大优先级越高，Zephyr 则相反，设计时需先确认所用 RTOS 的约定。
优先级定义的核心原则：
- 实时性需求：对时间敏感的任务（如传感器数据采集、无线应答）应分配高优先级。
- 执行频率：高频任务（如 1kHz 采样）通常高于低频任务（如 1Hz 状态上报）。
- 资源占用：短小精悍的任务可适当提高优先级，长任务（如推理）应降低优先级以避免阻塞。
- 依赖关系：被依赖的任务（如数据预处理）优先级应不低于依赖它的任务。
| 任务类型 | 典型周期 | 建议优先级 | 说明 |
|---|---|---|---|
| 传感器中断处理 | 事件驱动 | 最高（0-1） | 必须立即响应，否则数据丢失 |
| 无线接收/发送 | 10-100ms | 高（2-3） | 通信超时会导致重传或断连 |
| 数据预处理 | 1-10ms | 中高（3-4） | 为推理准备数据，延迟影响整体 |
| 推理计算 | 50-500ms | 中（4-5） | 计算量大，可容忍一定延迟 |
| 日志/状态上报 | 1s以上 | 低（6-7） | 非关键，可被抢占 |
3.2 抢占式与非抢占式调度：机制与适用场景
非抢占式调度（协作式）：任务主动让出 CPU 后才运行其他任务。优点是实现简单、无需考虑共享资源竞争；缺点是高优先级任务必须等待当前任务完成，实时性无法保证。在 TinyML 中，非抢占式仅适用于极简循环（如超级循环架构），不适合多任务并发。
抢占式调度：高优先级任务就绪时，立即暂停当前任务并切换执行。这是现代 RTOS 的标准模式，也是 TinyML 多任务协调的基础。抢占式调度的关键指标是调度延迟——从中断触发到高优先级任务开始执行的时间，通常由以下部分组成：
调度延迟 = 中断响应时间 + 中断处理时间 + 上下文切换时间
典型值（Cortex-M4 @ 80MHz）：
- 中断响应：12-15 个时钟周期（约 150-190ns）
- 上下文切换：30-50 个时钟周期（约 375-625ns）
- 总延迟：通常 < 10μs（含中断处理）混合调度模式是 TinyML 最常用的方案：中断服务程序（ISR）处理紧急事件（如传感器数据就绪），通过信号量或消息队列通知任务；RTOS 内核负责任务级抢占调度。这种模式兼顾了中断的极低延迟和任务的复杂逻辑处理。
| 维度 | 非抢占式 | 抢占式 |
|---|---|---|
| 实时性 | 差，依赖任务主动让出 | 好，高优先级立即执行 |
| 共享资源保护 | 天然安全 | 需要互斥锁/信号量 |
| 上下文切换开销 | 低 | 较高（但可接受） |
| 代码复杂度 | 低 | 中高 |
| TinyML 适用性 | 仅极简场景 | 主流选择 |
3.3 优先级反转：成因、危害与应对
优先级反转是指高优先级任务因等待低优先级任务持有的资源而被阻塞，同时中优先级任务抢占低优先级任务，导致高优先级任务长时间无法运行的现象。这是抢占式调度中最经典的实时性问题。
典型场景拆解：
- 任务 A（高优先级）需要访问共享传感器数据缓冲区，但任务 C（低优先级）正持有该缓冲区的互斥锁。
- 任务 A 被阻塞，等待 C 释放锁。
- 任务 B（中优先级）就绪，抢占 C 的 CPU。
- C 无法继续执行，无法释放锁，A 被无限期阻塞。
危害表现：
- 推理任务超时，导致输出结果延迟或丢失。
- 无线通信任务错过发送窗口，触发重传，增加功耗。
- 传感器采样任务错过采样周期，数据出现混叠。
解决方案：
| 方案 | 原理 | TinyML 适用性 |
|---|---|---|
| 优先级继承 | 低优先级任务持有锁时，临时提升到等待者的优先级 | 推荐，FreeRTOS 原生支持 |
| 优先级天花板 | 锁的优先级设为所有可能使用者的最高优先级 | 适合静态配置场景 |
| 关中断保护 | 临界区关闭中断，防止抢占 | 仅用于极短临界区（< 10μs） |
| 无锁设计 | 使用消息队列或 DMA 避免共享内存 | 最佳实践，但实现复杂 |
3.4 实战案例：智能传感器节点优先级设计
场景描述：设计一个电池供电的振动监测节点，使用 ADXL345 加速度计（I2C 接口，400kHz）、nRF24L01 无线模块和 STM32L4 MCU（Cortex-M4 @ 80MHz）。系统需完成 1kHz 采样、FFT 特征提取、异常检测推理和无线上报。
初始问题：采用默认优先级配置（所有任务优先级相同），系统出现以下现象：
- 无线发送时，采样任务偶尔丢失数据（采样间隔超过 1ms）。
- 推理任务执行时间波动大（从 80ms 到 200ms）。
- 电池续航低于预期（无线重传次数多）。
分析过程：
- 使用逻辑分析仪抓取 I2C 时钟，发现采样间隔在无线发送期间从 1ms 拉长到 3ms。
- 检查 RTOS 任务状态，发现无线任务在发送时持有 SPI 总线锁，采样任务等待 I2C 总线锁（共享 DMA 通道）。
- 推理任务在等待采样数据时被无线任务抢占，导致执行时间不稳定。
优化方案：
// 优先级配置（数值越大优先级越高，FreeRTOS）
#define PRIO_SENSOR_ISR 5 // 传感器中断（最高）
#define PRIO_WIRELESS 4 // 无线通信
#define PRIO_PREPROCESS 3 // 数据预处理
#define PRIO_INFERENCE 2 // 推理计算
#define PRIO_LOG 1 // 日志上报（最低）
// 关键修改：
// 1. 传感器中断中仅读取数据到环形缓冲区，不做处理
// 2. 无线任务使用 DMA + 中断，避免长时间占用 SPI 总线
// 3. 推理任务使用消息队列接收预处理结果，不直接共享内存
// 4. 启用互斥锁优先级继承（configUSE_MUTEXES = 1）结果对比：
| 指标 | 优化前 | 优化后 |
|---|---|---|
| 采样间隔抖动 | ±2ms | ±0.1ms |
| 推理执行时间 | 80-200ms | 85-95ms |
| 无线重传率 | 15% | 2% |
| 平均功耗 | 12mA | 8.5mA |
复盘经验：优先级设计不是简单的数值分配，需要结合任务间的资源依赖关系。本案例中，将传感器中断优先级设为最高，但中断处理极短（仅拷贝数据），避免了长时间关中断；无线任务通过 DMA 减少总线占用；推理任务通过消息队列解耦，避免了直接共享内存带来的优先级反转风险。
3.5 常见误区与总结
误区一：优先级越高越好。过高的优先级会导致低优先级任务饿死，尤其是日志、状态上报等非关键任务。应确保每个任务在可接受的时间窗口内获得 CPU。
误区二：忽略中断优先级与任务优先级的关系。在 Cortex-M 中，中断优先级高于任何任务。若中断处理时间过长，会阻塞所有任务。建议中断中只做"标记事件 + 拷贝数据"，复杂处理放到任务中。
误区三：认为优先级继承可以解决所有问题。优先级继承只能缓解反转，不能完全消除。在极端情况下（多个资源嵌套），仍可能出现长时间阻塞。最佳实践是减少共享资源，使用消息队列或事件标志组替代互斥锁。
误区四：不测量就配置。优先级配置必须基于实际时序测量。建议使用 RTOS 自带的 trace 工具（如 FreeRTOS 的 SystemView）记录任务切换时间线，验证最坏情况下的调度延迟。
- 优先级定义应基于实时性、频率、资源依赖三个维度综合评估。
- 抢占式调度是 TinyML 多任务的标准选择，但需控制调度延迟。
- 优先级反转是抢占式调度的固有风险，必须通过优先级继承或设计优化来应对。
- 中断处理应保持极短，复杂逻辑下沉到任务中执行。
- 每次修改优先级后，必须重新测量系统时序，验证最坏情况。
在实际 TinyML 项目中，优先级设计往往需要多轮迭代。建议先搭建最小系统，测量各任务的实际执行时间和资源占用，再根据测量结果调整优先级。同时，利用 RTOS 提供的调试工具持续监控任务状态，确保系统在长期运行中保持稳定。