3、RTOS核心概念：任务、调度器、优先级、中断、信号量、队列、互斥锁等基本机制

在TinyML场景中，推理任务往往需要与传感器数据采集、通信协议栈、电源管理等功能并发运行。实时操作系统（RTOS）的核心价值在于提供一套可预测、可控制的并发执行框架。本章将深入剖析RTOS的七大核心机制——任务、调度器、优先级、中断、信号量、队列、互斥锁，并重点阐述它们在TinyML推理任务中的具体定位与协作方式。理解这些机制，是设计一个稳定、低延迟、资源可控的嵌入式AI系统的前提。

上图展示了RTOS各核心机制之间的协作关系。任务是被调度的执行单元，调度器根据优先级决定哪个任务运行，中断用于响应外部事件，信号量、队列和互斥锁则负责任务间的同步与数据交换。在TinyML系统中，推理任务通常是一个独立的任务，它通过队列接收传感器数据，通过信号量被唤醒，并受互斥锁保护以避免与通信任务同时访问共享模型参数。

3.1 任务：RTOS中的执行单元

核心原理：任务是RTOS中最基本的执行实体，每个任务拥有独立的栈空间、程序计数器和寄存器上下文。任务在逻辑上并行执行，但在单核CPU上实际是并发执行。任务的状态机包括运行态、就绪态、阻塞态和挂起态。在TinyML场景中，典型的任务划分包括：传感器采集任务、推理任务、通信任务、电源管理任务。

任务设计要点：

• 栈大小估算：推理任务涉及模型加载和中间张量计算，栈需求通常较大。例如，一个基于MobileNet的推理任务，若使用静态张量分配，栈需求约2-4KB；若使用动态分配，则可能达到8KB以上。建议通过uxTaskGetStackHighWaterMark()在运行时监测栈余量。
• 任务状态转换：推理任务在等待数据时处于阻塞态，数据到达后通过信号量或队列通知转为就绪态，调度器根据优先级决定是否立即抢占运行。
• 任务优先级分配：推理任务通常设置为中高优先级（如3-5级，共10级），高于后台维护任务，但低于硬实时中断处理。

3.2 调度器与优先级：决定谁先运行

调度器机制：RTOS调度器维护一张就绪任务表，采用基于优先级的抢占式调度策略。当高优先级任务就绪时，立即抢占当前运行的低优先级任务。同优先级任务之间采用时间片轮转调度。在TinyML系统中，调度器的确定性至关重要——推理任务的完成时间必须可预测。

优先级反转问题：当低优先级任务持有互斥锁，而高优先级任务等待该锁时，中优先级任务可能抢占低优先级任务，导致高优先级任务被间接延迟。解决方案包括优先级继承协议或优先级天花板协议。FreeRTOS的互斥锁默认支持优先级继承。

调度延迟优化：在TinyML中，推理任务对调度延迟敏感。建议将推理任务设置为最高用户优先级（但低于中断），并确保中断服务程序（ISR）尽可能短，仅做标记和唤醒操作，实际数据处理放在任务中完成。

3.3 中断：外部事件的快速响应

中断与任务的关系：中断是硬件异步事件，具有最高执行优先级。在TinyML系统中，传感器数据就绪、DMA传输完成、定时器溢出等都会触发中断。中断服务程序（ISR）应遵循“快进快出”原则，仅完成必要操作（如读取寄存器、清中断标志），然后通过信号量或队列通知相关任务。

中断与推理任务的协作模式：

// ISR中最小化处理
void Sensor_ISR(void) {
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    int32_t sample = read_sensor_reg();
    xQueueSendFromISR(xSensorQueue, &sample, &xHigherPriorityTaskWoken);
    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

// 推理任务中阻塞等待数据
void InferenceTask(void *params) {
    int32_t sample;
    while(1) {
        xQueueReceive(xSensorQueue, &sample, portMAX_DELAY);
        // 执行推理
        float result = run_inference(sample);
        // 发送结果
    }
}

中断优先级配置：在Cortex-M系列MCU上，FreeRTOS要求中断优先级数值越小优先级越高，且不能使用高于configMAX_SYSCALL_INTERRUPT_PRIORITY的中断调用FreeRTOS API。TinyML系统中，传感器中断通常设置为中等优先级（如5-7），而系统节拍中断设置为最低优先级。

3.4 信号量、队列与互斥锁：任务间协作的三大工具

信号量（Semaphore）：用于任务同步，分为二值信号量和计数信号量。二值信号量适合事件通知（如“数据已就绪”），计数信号量适合资源计数（如“可用缓冲区数量”）。在TinyML中，推理任务可阻塞在二值信号量上，等待传感器采集任务完成一次数据采集后释放信号量。

队列（Queue）：用于任务间数据传递，采用FIFO（先进先出）方式。队列在TinyML中常用于传递传感器原始数据、推理结果或控制命令。队列长度和消息大小需根据数据频率和负载合理配置。例如，一个10Hz的传感器，队列长度设为5即可缓冲500ms的数据。

互斥锁（Mutex）：用于保护共享资源，具有优先级继承特性。在TinyML中，模型参数通常存储于只读区域，无需互斥保护；但若模型支持在线更新（如联邦学习场景），则需使用互斥锁保护模型参数区，防止推理任务读取时被更新任务修改。

3.5 实战案例：多传感器TinyML推理系统设计

场景背景：设计一个可穿戴设备的人体活动识别系统，包含加速度计（100Hz）、陀螺仪（100Hz）和心率传感器（50Hz）。系统需实时运行一个轻量级CNN模型（参数量约50K，推理时间约15ms），并通过BLE将结果发送至手机。

系统约束：

• MCU：Cortex-M4 @ 80MHz，256KB Flash，64KB RAM
• 推理任务必须在30ms内完成一次推理（含数据预处理）
• BLE通信任务优先级低于推理任务，但需保证每100ms发送一次结果
• 传感器数据通过SPI+DMA方式采集，每次DMA完成触发中断

任务划分与优先级分配：

关键实现细节：

// 队列定义
QueueHandle_t xSensorFrameQueue;  // 存放聚合后的传感器帧
QueueHandle_t xResultQueue;       // 存放推理结果

// SensorAggTask中发送数据
void SensorAggTask(void *params) {
    SensorFrame_t frame;
    while(1) {
        // 等待三路传感器数据齐备（通过信号量组）
        xSemaphoreTake(xSensorSyncSem, portMAX_DELAY);
        frame.accel = latest_accel;
        frame.gyro = latest_gyro;
        frame.hr = latest_hr;
        xQueueSend(xSensorFrameQueue, &frame, 0);
    }
}

// InferenceTask中接收并推理
void InferenceTask(void *params) {
    SensorFrame_t frame;
    Result_t result;
    while(1) {
        xQueueReceive(xSensorFrameQueue, &frame, portMAX_DELAY);
        // 预处理 + 推理
        preprocess(&frame);
        run_cnn_inference(&result);
        xQueueSend(xResultQueue, &result, 0);
    }
}

运行结果与调优：初始设计中，推理任务优先级设为3，导致在BLE发送高峰期推理延迟达到45ms，超过30ms预算。将推理任务优先级提升至5后，最坏情况推理延迟降至22ms。同时，通过监测栈高水位，发现推理任务实际栈使用仅2.1KB，将栈从4KB减至3KB，节省了1KB RAM。

复盘经验：优先级分配需结合最坏情况分析，不能仅看平均负载。中断服务程序中的DMA配置需确保缓冲区对齐，避免缓存一致性问题。队列长度设置为3即可满足100Hz数据率下的缓冲需求，过长会浪费RAM。