第2章：飞控系统概述：飞控硬件架构、传感器数据流、控制环路
各位同学，欢迎来到第二讲。上一章我们聊了RTOS移植的全局观，今天咱们把目光聚焦到飞控系统本身。说白了，你要移植RTOS，总得知道它要跑在什么样的硬件上，要处理什么样的数据流，对吧？
我刚开始做飞控那会儿，也犯过迷糊——拿着STM32F4的参考手册就开始写代码，结果发现传感器数据老是丢，控制周期也抖得厉害。后来才明白，不把硬件架构和数据流吃透，写出来的代码就是空中楼阁。今天咱们就把这层窗户纸捅破。
2.1 飞控硬件架构：STM32F4 vs STM32H7
飞控的核心，说白了就是一块MCU。目前市面上主流的方案，基本就是ST的STM32F4和H7系列。我个人的习惯是：如果项目对成本敏感、功耗要求高，选F4；如果追求极致性能、要跑复杂算法，那就上H7。
咱们先看一张对比表，心里有个底：
| 特性 | STM32F4（如F405/F427） | STM32H7（如H743/H750） |
|---|---|---|
| 内核 | Cortex-M4F（单核） | Cortex-M7（单核，带双精度FPU） |
| 主频 | 168MHz ~ 180MHz | 400MHz ~ 480MHz |
| SRAM | 192KB ~ 256KB | 1MB+（含TCM、AXI SRAM等） |
| Flash | 512KB ~ 2MB | 1MB ~ 2MB |
| DMA | 2个DMA控制器（16流） | 4个MDMA + 2个DMA（更灵活） |
| 定时器 | 14个（含高级定时器） | 22个（含HRTIM高精度定时器） |
| ADC | 3个12位ADC（最快2.4MSPS） | 3个16位ADC（最快3.6MSPS） |
| 典型功耗 | 约50mA @ 168MHz | 约100mA @ 400MHz |
你看，H7的主频是F4的两倍多，SRAM更是大了好几倍。但代价也很明显——功耗翻倍，而且外设配置更复杂。我在一个四轴项目中用过H743，当时为了把DMA和MDMA的优先级调明白，折腾了整整两天。嗯，这里要注意：H7的Cache和TCM如果不配置好，性能反而可能不如F4。
核心要点：飞控硬件架构的关键，不是MCU本身有多强，而是它能不能在正确的时间拿到正确的数据。说白了，就是「实时性」和「确定性」。
2.2 传感器数据流：从物理量到数字信号
飞控系统里，传感器就是我们的眼睛和耳朵。常见的传感器包括：
- IMU（惯性测量单元）：包含加速度计和陀螺仪，比如MPU6000、ICM-20602
- 磁力计：比如HMC5883L、IST8310，用来测地磁场方向
- 气压计：比如MS5611、BMP280，用来测高度
- GPS/北斗：提供位置和速度信息
- 光流/超声波：用于室内定高和避障
这些传感器的数据是怎么流进MCU的？我画个简单的数据流图给你看：
传感器（物理量）
↓
模拟/数字转换（ADC/SPI/I2C）
↓
DMA传输（不占CPU）
↓
传感器驱动（中断/轮询）
↓
数据融合（卡尔曼滤波/互补滤波）
↓
控制环路（PID/ADRC）
↓
执行器（PWM输出到电调/舵机）你想想看，这里最容易被忽视的是哪一步？我个人经验是——DMA传输。很多新手喜欢在中断里直接读传感器，结果中断一多，CPU就被拖死了。我建议：所有SPI/I2C传感器都走DMA，让CPU专心做计算。
避坑指南：我曾经在一个项目中，用轮询方式读MPU6000的陀螺仪数据，结果发现控制周期从1kHz掉到了500Hz。后来改成DMA + 双缓冲，问题立刻解决。记住：传感器数据流里，DMA不是可选项，是必选项。
还有一个细节：传感器数据的「时间戳」。你从IMU读到的数据，到底是「什么时候」的？如果数据采集时间和处理时间对不上，控制精度就会大打折扣。我习惯在DMA完成中断里，用定时器捕获一个硬件时间戳，然后和数据一起打包传给上层。
2.3 控制环路：飞控的灵魂
飞控的核心，就是三个控制环路：
- 内环（角速率环）：频率最高，通常1kHz~4kHz。控制飞机的角速度，说白了就是让飞机「转得快还是慢」。
- 中环（姿态环）：频率中等，通常200Hz~500Hz。控制飞机的俯仰、横滚、偏航角度。
- 外环（位置环）：频率最低，通常50Hz~100Hz。控制飞机的位置和速度。
这三个环路是嵌套的。内环跑得最快，外环跑得最慢。为什么？因为角速度变化最快，位置变化最慢。你想想看，你推一下摇杆，飞机要立刻响应角速度变化，但位置变化需要时间积累。
我见过一个典型的飞控任务调度表，大概是这样的：
| 任务 | 优先级 | 周期 | 说明 |
|---|---|---|---|
| IMU数据采集 | 最高 | 250μs（4kHz） | DMA完成中断触发 |
| 角速率控制 | 高 | 250μs | 内环PID计算 |
| 姿态解算 | 中 | 2ms（500Hz） | 四元数更新 |
| 姿态控制 | 中 | 2ms | 中环PID计算 |
| 位置控制 | 低 | 10ms（100Hz） | 外环PID计算 |
| GPS数据解析 | 低 | 20ms（50Hz） | UART DMA接收 |
| 遥测数据发送 | 最低 | 50ms（20Hz） | 非实时任务 |
你看，这个调度表里，内环任务和IMU采集是绑在一起的，周期250μs。这意味着什么？意味着你的RTOS tick中断不能超过这个时间，否则就会丢数据。我建议：把tick设为100μs，或者干脆用定时器直接触发任务，绕过OS调度。
注意：千万不要在中断里做浮点运算！我曾经在IMU中断里直接跑卡尔曼滤波，结果中断延迟从5μs飙到了50μs，内环直接崩了。正确的做法是：中断里只做数据搬运和标记，计算放到任务里做。
最后，聊一下控制环路的「实时性」到底有多重要。我举个例子：假设内环周期是250μs，如果某次调度延迟了100μs，也就是350μs才执行，那么PID的输出就会滞后。对于四轴飞行器来说，100μs的延迟可能意味着10度以上的姿态偏差。你想想看，飞机能不晃吗？
所以，RTOS移植到飞控上，核心目标就一个：保证每个任务在它的deadline之前完成。这也是为什么我们后面要花大量精力去调优任务优先级、中断优先级和DMA配置。
好了，这一章的内容就到这里。下一章，我们正式进入RTOS移植的实战环节——从零搭建一个飞控用的FreeRTOS工程。到时候我会手把手带你配置时钟、中断和任务调度。咱们下章见。