2. ArduPilot 架构概览：主循环调度器、任务优先级、线程模型与HAL层抽象
说实话，很多刚接触ArduPilot的朋友，第一反应都是：“这代码也太庞大了吧？” 几万行代码，各种传感器、控制算法、通信协议搅在一起，看着就头大。
但你别慌。ArduPilot的架构设计其实非常清晰。它就像一栋设计精良的大楼，有承重墙、有水电管线、有电梯调度。你只要搞懂了它的骨架，剩下的就是往里面填砖的事。
我个人习惯，拿到一个嵌入式项目，第一件事就是看它的调度器（Scheduler）和线程模型。这决定了整个系统的实时性和稳定性。今天我们就来拆解ArduPilot的核心架构。
核心观点： ArduPilot 的架构核心是“分层 + 轮询 + 事件驱动”。主循环调度器是心脏，HAL层是骨架，线程模型是血管。理解这三者，你就掌握了整个系统的命脉。
2.1 主循环调度器（Scheduler）—— 系统的心脏
ArduPilot 不是像 Linux 那样靠中断和抢占式调度来运行的。它本质上是一个 超级循环（Super Loop）。嗯，你没听错，就是那种最朴素的嵌入式编程方式。
但它的高明之处在于，在这个循环里，它实现了一个非常高效的 协作式多任务调度器。所有任务都是“自愿”交出CPU的，没有任务能强行打断另一个任务（除非是硬件中断）。
这个调度器的核心逻辑，就在 AP_Scheduler 这个类里。它的工作流程大致是这样的：
- 计算可用时间： 看看这一轮循环还剩多少时间。
- 遍历任务列表： 按优先级顺序，检查每个任务是否该运行了。
- 执行任务： 如果任务到了执行时间，就调用它的回调函数。
- 时间监控： 如果某个任务跑超时了，记录日志，但不会杀死它。
- 循环结束，等待下一次心跳： 通常是 1kHz（1毫秒）的主循环频率。
我曾经在一个项目中，因为某个传感器驱动写得特别烂，每次读取都要阻塞 50 毫秒。结果整个飞控的循环周期从 1ms 直接掉到了 50ms，飞机在空中就跟喝醉了似的。从那以后，我写任何任务函数，都时刻提醒自己：“别阻塞！别阻塞！别阻塞！”
我的小技巧： 在写自定义任务时，尽量把任务拆分成多个小步骤。如果一次做不完，就设置一个状态机，每次循环只做一小步。这样就不会拖累整个调度器。
2.2 任务优先级与调度策略
调度器里维护着一张任务表。每个任务都有几个关键属性：
| 属性 | 说明 | 我的经验 |
|---|---|---|
| 函数指针 | 要执行的函数地址 | 确保函数执行时间可控 |
| 运行频率 (Hz) | 比如 400Hz、50Hz、10Hz | 不是越高越好，够用就行 |
| 优先级 (uint8_t) | 数值越小，优先级越高 | 0 是最高，一般留给紧急任务 |
| 最大执行时间 (us) | 建议的最大耗时 | 超过这个值会触发警告 |
你想想看，为什么 ArduPilot 不用抢占式调度？说白了，是为了 确定性。在抢占式系统里，你永远不知道一个低优先级任务会在哪条指令被高优先级任务打断。这在飞控这种对时序极其敏感的系统里，是灾难性的。
协作式调度保证了：只要一个任务不主动让出CPU，其他任务就绝对拿不到控制权。这听起来很危险，对吧？但正是这种“信任”，让整个系统的行为变得可预测。
避坑指南： 我曾经在调试一个光流传感器时，发现飞机总是莫名其妙地偏航。查了三天，最后发现是光流的数据处理任务里，有一个 while(1) 的等待循环，导致调度器卡死。记住：永远不要在任务函数里使用死循环或长时间的阻塞等待！
2.3 线程模型：从单核到多核的演进
传统的 ArduPilot（比如在 STM32F4 上）是纯单线程的。所有任务都在一个主循环里跑。但随着硬件的发展，我们开始用上了双核甚至多核的处理器（比如 STM32H7、Pixhawk 6X 上的 i.MX RT）。
这时候，ArduPilot 引入了 ChibiOS 作为实时操作系统（RTOS）。在 RTOS 模式下，主循环调度器依然存在，但它变成了一个高优先级的线程。其他辅助任务（比如 SD 卡写入、高频率传感器读取）可以放在其他线程里。
我画了一张图，帮你理解这个线程模型：
你看，主循环调度器在最顶层，它负责调度所有“飞控逻辑”相关的任务。而 HAL 层在最底层，屏蔽了不同硬件之间的差异。中间的任务列表，就是调度器要管理的“工作清单”。
2.4 HAL 层抽象 —— 跨平台的基石
ArduPilot 能跑在 STM32、i.MX RT、Linux（树莓派）、甚至 Windows 模拟器上，靠的就是 HAL 层（硬件抽象层）。
HAL 层的设计哲学很简单：定义接口，隐藏实现。比如，你要读取一个 GPIO 引脚，在代码里你调用的是 hal.gpio->read()。至于这个 read() 函数底层是操作 STM32 的寄存器，还是调用 Linux 的 /sys/class/gpio，上层代码完全不用关心。
我整理了一下 HAL 层的主要模块：
| HAL 模块 | 功能 | 典型实现差异 |
|---|---|---|
hal.gpio |
通用输入输出 | STM32: 直接寄存器操作；Linux: sysfs |
hal.spi |
SPI 总线通信 | STM32: HAL库；Linux: spidev |
hal.i2c |
I2C 总线通信 | STM32: HAL库；Linux: i2c-dev |
hal.uart |
串口通信 | STM32: USART；Linux: ttyS* |
hal.rcout |
PWM 输出（控制电机/舵机） | STM32: 定时器；Linux: PCA9685 |
hal.scheduler |
调度器接口（延时、获取时间） | ChibiOS: 系统时钟；Linux: clock_gettime |
我记得有一次，我们需要把 ArduPilot 移植到一个国产的 MCU 上。那个 MCU 的 SPI 控制器有个奇怪的 bug，在高速模式下会丢数据。如果是直接操作寄存器，我可能得改几百处代码。但因为 HAL 层的存在，我只需要在 AP_HAL_XXX 的 SPI 驱动里加一个软件重试机制，上层所有使用 SPI 的传感器（IMU、气压计、磁力计）就都自动修复了。这就是抽象层的威力。
一个实用的建议： 如果你想为 ArduPilot 贡献代码，或者移植到新硬件，重点关注 libraries/AP_HAL 目录。这里面定义了所有 HAL 接口。你只需要实现这些接口，剩下的飞控逻辑、EKF 算法、导航代码，一行都不用改。
2.5 三者如何协同工作？
我们来走一个完整的流程，看看这三者是怎么配合的：
- 硬件中断： 比如 IMU 的 SPI 数据准备好，触发一个中断。
- HAL 层处理： HAL 层的 SPI 驱动在中断服务函数里读取数据，放到一个环形缓冲区。
- 调度器轮询： 主循环调度器发现“IMU 读取任务”该运行了（比如 1kHz 的频率）。
- 任务执行： 任务函数从 HAL 的缓冲区里取出原始数据，进行校准、滤波，然后送给姿态估计模块。
- 输出控制： 姿态估计模块算出控制量，通过
hal.rcout输出 PWM 信号给电调。
整个过程，从传感器数据产生到电机响应，延迟通常在 1-2 毫秒以内。这就是 ArduPilot 能在竞速无人机上飞得那么激进的原因。
又一个坑： 我曾经在调试一个四轴飞行器时，发现电机响应有 10 毫秒的延迟。查到最后，发现是 HAL 层的 PWM 输出模块里，有一个 delay(5) 的语句。这个 delay 直接阻塞了主循环 5 毫秒！记住：HAL 层的实现里，绝对不能有阻塞调用，除非你明确知道自己在做什么。
好了，这一章的内容就到这里。ArduPilot 的架构其实不复杂，核心就是“调度器管逻辑，HAL 管硬件”。你只要记住这个原则，后面看代码就会轻松很多。