3、FreeRTOS在飞控中的应用：任务创建与调度、消息队列、信号量、软件定时器、任务通知

各位同学，欢迎来到第三章。这一章我们聊聊FreeRTOS。说实话，飞控系统如果没有RTOS，就像人没有神经系统——所有事情都得靠主循环轮询，效率低不说，还容易出乱子。我个人习惯把FreeRTOS比作飞控的“调度中心”，它决定了哪个任务先跑、哪个任务等一等、哪个任务该睡觉了。

嗯，咱们直接切入正题。这一章我会结合我在实际飞控项目中的踩坑经历，把任务创建、调度、消息队列、信号量、软件定时器和任务通知这几个核心点讲透。你想想看，飞控里几十个传感器数据要采集、姿态要解算、控制律要输出、遥控器信号要解析……没有一套好的调度机制，根本玩不转。

3.1 任务创建与调度：飞控的“多线程”基础

FreeRTOS里，任务就是一段独立运行的函数。每个任务都有自己的栈空间和优先级。飞控中典型的任务划分是这样的：

任务名称 优先级 功能描述 典型周期
SensorTask 高 读取IMU、磁力计、气压计数据 1ms
AttitudeTask 高 姿态解算（互补滤波/卡尔曼） 2ms
ControlTask 中 PID控制律计算 4ms
TelemetryTask 低 地面站数据回传 50ms

任务创建很简单，用xTaskCreate()就行。但我提醒你一句：栈大小一定要算准。我曾经在一个项目中，SensorTask的栈给小了，结果飞了3分钟突然炸机——栈溢出把控制参数给覆盖了。从那以后，我每个任务都会用uxTaskGetStackHighWaterMark()检查一下剩余栈空间。

核心要点：飞控中高优先级任务不要做太多计算，只做“读数据”和“发指令”这种短平快的事。复杂的滤波和计算放到中优先级任务里。否则低优先级的遥测任务可能永远得不到CPU时间——这叫“优先级反转”的极端情况。

// 任务创建示例
void vSensorTask(void *pvParameters) {
    while(1) {
        // 读取IMU数据
        imu_read(&gyro, &accel);
        // 发送到姿态解算任务
        xQueueSend(xAttitudeQueue, &gyro, 0);
        // 精确延时1ms
        vTaskDelay(pdMS_TO_TICKS(1));
    }
}

void vAttitudeTask(void *pvParameters) {
    while(1) {
        // 接收传感器数据
        xQueueReceive(xAttitudeQueue, &gyro, portMAX_DELAY);
        // 姿态解算
        attitude_estimate(gyro, accel, &attitude);
        // 发送给控制任务
        xQueueSend(xControlQueue, &attitude, 0);
        vTaskDelay(pdMS_TO_TICKS(2));
    }
}

调度方式上，FreeRTOS默认是抢占式调度。说白了就是：高优先级任务一就绪，立刻打断低优先级任务。飞控里我一般把SensorTask设为最高优先级，因为它提供最原始的时间基准。

3.2 消息队列：任务间的“快递员”

消息队列是飞控里用得最多的IPC机制。为什么？因为传感器数据、控制指令、状态信息都需要在不同任务间传递。队列的本质是一个环形缓冲区，生产者往里放，消费者往外取。

我个人习惯把队列长度设成2的幂次，比如4、8、16。这样取模运算更快。嗯，其实在Cortex-M4上差别不大，但习惯成自然。

避坑指南：我曾经在ControlTask里用xQueueReceive设置了portMAX_DELAY，结果SensorTask偶尔卡死，ControlTask就一直等，飞控直接失控。后来我改成pdMS_TO_TICKS(10)的超时，配合一个看门狗复位机制，问题就解决了。记住：永远不要无限等待一个可能永远不会来的消息。

// 队列创建
QueueHandle_t xAttitudeQueue = xQueueCreate(4, sizeof(imu_data_t));

// 发送端（SensorTask中）
imu_data_t gyro_data;
xQueueSend(xAttitudeQueue, &gyro_data, 0);  // 0表示不等待

// 接收端（AttitudeTask中）
imu_data_t gyro_recv;
if(xQueueReceive(xAttitudeQueue, &gyro_recv, pdMS_TO_TICKS(5)) == pdTRUE) {
    // 处理数据
} else {
    // 超时处理：使用上一次的有效数据
}

3.3 信号量：资源管理的“红绿灯”

信号量分两种：二值信号量和计数信号量。飞控里二值信号量常用于“事件通知”，比如SPI传输完成中断里释放信号量，让等待的任务继续执行。计数信号量则用于管理有限资源，比如DMA缓冲区。

你想想看，飞控里I2C总线是共享的，多个传感器挂在同一条总线上。如果没有信号量保护，SensorTask和TelemetryTask同时操作I2C，数据就乱套了。

注意：中断服务函数中释放信号量要用xSemaphoreGiveFromISR()，而不是xSemaphoreGive()。这个坑我踩过——在中断里用了普通版本的Give，结果系统直接HardFault。因为FreeRTOS在中断上下文和任务上下文使用的API是不同的。

// 二值信号量示例
SemaphoreHandle_t xSPIComplete;

void SPI_IRQHandler(void) {
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    // 清除中断标志
    SPI_ClearITPendingBit();
    // 释放信号量
    xSemaphoreGiveFromISR(xSPIComplete, &xHigherPriorityTaskWoken);
    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

void vSPITask(void *pvParameters) {
    while(1) {
        // 等待SPI传输完成
        if(xSemaphoreTake(xSPIComplete, pdMS_TO_TICKS(100)) == pdTRUE) {
            // 处理SPI数据
        } else {
            // 超时处理：重新初始化SPI
            SPI_ReInit();
        }
    }
}

3.4 软件定时器：飞控的“闹钟”

软件定时器在飞控里非常实用。比如：每10ms检查一次遥控器信号是否丢失，每100ms更新一次LED状态，每1s记录一次飞行日志。这些周期性任务如果都用任务来做，太浪费栈空间了。用软件定时器回调函数，轻量又方便。

但要注意：定时器回调函数中不能阻塞。不能调用vTaskDelay()，不能等待信号量。回调函数应该短小精悍，只做标志位设置或消息发送。真正的处理逻辑放到任务里。

// 软件定时器创建
TimerHandle_t xLEDTimer = xTimerCreate(
    "LED Timer",           // 名字
    pdMS_TO_TICKS(100),    // 周期100ms
    pdTRUE,                // 自动重载
    NULL,                  // 定时器ID
    vLEDCallback           // 回调函数
);

void vLEDCallback(TimerHandle_t xTimer) {
    // 切换LED状态
    HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin);
    // 注意：这里不能调用阻塞API！
}

// 启动定时器
xTimerStart(xLEDTimer, 0);

3.5 任务通知：最高效的IPC方式

任务通知是FreeRTOS特有的机制，比信号量和队列都快。为什么？因为它直接操作任务控制块（TCB）里的一个32位值，不需要经过队列或信号量的链表操作。在飞控这种对实时性要求极高的场景，任务通知是首选。

我个人习惯用任务通知来替代二值信号量。比如：当DMA传输完成时，用xTaskNotifyGive()通知等待的任务。实测下来，任务通知比信号量快30%左右。

关键区别：每个任务只有一个任务通知值。如果你需要传递多个事件，或者需要传递数据，还是得用队列。任务通知适合“通知-等待”这种简单场景。

// 任务通知示例
TaskHandle_t xSensorTaskHandle;

// 在SensorTask中等待通知
void vSensorTask(void *pvParameters) {
    uint32_t ulNotificationValue;
    while(1) {
        // 等待通知，超时100ms
        ulNotificationValue = ulTaskNotifyTake(pdTRUE, pdMS_TO_TICKS(100));
        if(ulNotificationValue > 0) {
            // 收到通知，读取传感器
            imu_read(&gyro, &accel);
        } else {
            // 超时，执行备用逻辑
        }
    }
}

// 在中断中发送通知
void TIM_IRQHandler(void) {
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    // 清除中断标志
    TIM_ClearITPendingBit();
    // 发送任务通知
    vTaskNotifyGiveFromISR(xSensorTaskHandle, &xHigherPriorityTaskWoken);
    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

3.6 综合应用：飞控任务调度架构

好了，我们把上面这些知识点串起来，看看一个典型的飞控任务调度架构长什么样：

  1. SensorTask（最高优先级）：通过SPI/DMA读取IMU数据，用任务通知触发。读取完成后通过队列发送给AttitudeTask。
  2. AttitudeTask（高优先级）：从队列接收传感器数据，进行姿态解算。解算完成后通过队列发送给ControlTask。
  3. ControlTask（中优先级）：接收姿态数据，计算PID控制量，通过PWM输出给电机。
  4. TelemetryTask（低优先级）：每50ms通过UART发送状态数据到地面站。
  5. 软件定时器：每10ms检查遥控器信号，每100ms更新LED，每1s记录日志。

这个架构我用了好几年，在Pixhawk和自研飞控上都验证过。你想想看，每个任务各司其职，通过队列和信号量安全地交换数据，整个系统就像一台精密的瑞士钟表。

我的建议：刚开始做飞控时，不要追求花哨的调度策略。先把基础的任务创建、队列通信跑通。等系统稳定了，再逐步优化。我曾经见过一个新手，一上来就搞优先级反转避免、互斥量嵌套，结果代码写了一堆bug。记住：简单可靠，比复杂花哨更重要。

嗯，这一章的内容就到这里。下一章我们会深入飞控的传感器驱动开发，讲讲IMU、磁力计、气压计这些传感器怎么在FreeRTOS下高效工作。到时候我会分享一些我在I2C和SPI驱动上的踩坑经验，保证让你少走弯路。

← 上一章 📖 返回目录 下一章 →