1. 为什么飞控要从单核换到非对称双核1.1 飞控的“快”和“多”其实是两类矛盾问题做飞控的朋友应该都有体会飞控代码里最磨人的不是某个算法本身而是所有任务挤在同一个 CPU 上抢时间。姿态解算要跑得够快控制环要卡得够准数传、GPS、遥控、日志、任务规划这些又像一群不停要资源的小进程哪一个都不能长时间占着 CPU 不放。我把这两类需求拆开看一类是“快且硬”的控制链IMU 读取、姿态解算、控制律计算、电机输出这条链路最好能稳定跑到 1kHz 以上而且延迟抖动要尽量小另一类是“多且杂”的管理链MAVLink 协议解析、SD 卡日志写入、航点规划、传感器补温度补偿、参数存储、地面站心跳这些任务不要求微秒级响应但总量很大还经常有阻塞操作。单核 MCU 的经典做法是用实时操作系统跑优先级抢占把控制放在最高优先级任务里管理任务放到低优先级。这套方案在小四轴、入门固定翼上完全够用但一旦飞机变大、传感器变多、通信协议变复杂就会发现控制任务偶尔被高频率中断打断日志写卡或者 USB 枚举瞬间导致调度抖动飞起来手感忽硬忽软。1.2 国产飞控主控选型的现实困境过去国产飞控主控大多围绕国外厂商的通用 MCU 来做比如 STM32F4、STM32H7 这类。不是说这些芯片不行而是在供应链波动之后大家开始认真考虑“如果这颗料拿不到货方案能不能马上平移”。平移的过程里最容易卡住的地方就是算力和外设老一代 MCU 主频低、内存小CAN FD 和以太网这种接口要么没有要么数量不够再做高规格飞控就很难受。于是 HPM6750 这类国产高端 MCU 进入视野。它满足三点关键要求第一主频和算力足够适合跑复杂控制算法和多路协议第二双核架构能直接解决“快”和“多”的矛盾第三外设接口覆盖面广USB、以太网、CAN、PWM、ADC、SPI 一应俱全。对飞控硬件负责人来说这三点凑齐方案才敢往下推进。这里要强调一下国产不等于降级。HPM6750 的定位是高性能实时控制 MCU不是简单替代料。它和传统 MCU 之间不是“平替”关系而是把过去需要“MCU 协处理器”或者“高性能 MPU 跑 Linux”才能做的事压缩到一颗双核 MCU 里完成。对飞控这种既要强实时又要低功耗低成本的产品来说这个定位非常精准。1.3 AMP 和 SMP飞控更该选哪种双核模式双核处理器有两种主流工作模式。SMP 是对称多处理两个核心共享同一个操作系统由内核统一调度任务哪个核空闲就跑哪个任务好处是负载均衡坏处是任务执行位置不确定实时任务的延迟也就不可控。AMP 是非对称多处理两个核心各自运行独立的操作系统或裸机程序核心之间通过明确机制通信每个核只管自己那一摊事。飞控特别喜欢 AMP 的原因是它把“确定性”还给了开发者。控制核独占一个 CPU除了控制链相关中断外几乎不跑别的东西任务执行时间非常稳定管理核跑复杂协议和文件系统就算偶尔卡顿也不会污染控制链路。这种“物理隔离”比任何调度策略都彻底。HPM6750 适合 AMP 的硬件基础也在这里双 RISC-V 核心可独立启动、独立复位每个核有自己的中断控制器共享内存区域可配置。开发者可以把 CPU0 当成“飞控核心”把 CPU1 当成“通信管理核心”两个核各干各的只在必要的时候交换数据。2. HPM6750 的硬件能力哪些点直接命中飞控需求2.1 双核性能与实时性底子HPM6750 来自先楫半导体HPMicro采用双 RISC-V 核心设计最高主频能到 800MHz 以上。这个算力水平放在 MCU 圈子里属于第一梯队放在飞控场景里意味着姿态解算和控制律计算还远没到瓶颈。它的内核带有单精度和双精度浮点单元也支持 DSP 指令扩展。飞控里最常用到的矩阵运算、四元数更新、卡尔曼滤波、PID 增量计算基本都能用浮点指令直接高效完成。相比靠软件模拟浮点的老平台开发体验完全不一样不再需要为了性能去手动做定点化。我实测下来单核跑一套扩展卡尔曼滤波加 1kHz 控制律负载只占很小一部分剩下的算力可以被通信和日志任务吃掉或者干脆关掉另一个核来省电。实时性方面HPM6750 提供多级中断优先级且中断响应延迟很低。飞控最怕的有两件事中断被长时间屏蔽或者高优先级中断被无关中断卡住。在 HPM6750 上做裸机或者 RTOS 改造时只要控制核不开放不必要的阻塞操作控制中断的稳定性能做得很漂亮。2.2 存储与外设飞控最关心的几个区域飞控主控的选型说白了就是“内存要大、外设要全、接口要快”。HPM6750 带有 MB 级别的片上 SRAM具体容量根据型号配置内部足够放飞行日志环形缓冲、传感器数据缓存和核间通信共享内存池。不要小看片上内存飞控如果老要去访问外部 RAM不但增加布线难度还可能引入访问延迟和信号完整性问题。外设接口上它能提供多路 UART、SPI、I2C、CAN/CAN FD、USB、以太网、PWM 和 ADC。这意味着飞控板上不需要再挂一大堆转换芯片GNSS 接收机直接接 UARTIMU 传感器走 SPI 或者 I2C电调可以用 PWM 输出、DShot 或者 CAN FD地面站和数传可以走 UART 或 USB图传协同、机载电脑通信还能用以太网。一套外设接完发现芯片资源还有不少余量这种“宽裕感”在前期设计时很值钱。2.3 国产飞控硬件方案的供应链逻辑从系统工程角度国产化飞控不是只在 PCB 上换一颗芯片而是要全套方案都立得住。HPM6750 的国产属性让飞控硬件在供应链上多了一个低风险选项同时它的开发工具链、SDK 和文档都是中文友好型遇到问题可以直接和原厂 FAE 沟通这一点对量产项目是非常实在的保障。更核心的一点是HPM6750 的性能指标本身就留足了升级空间。现在做四轴用双核后面做复合翼、倾转旋翼、无人车或者机器人控制频率从 1kHz 升到 4kHz甚至加上在线参数辨识、自适应控制主控也不用推倒重来。选型时把这条路想清楚比只看眼前的参数表更关键。3. 非对称双核软件架构与核间通信设计3.1 双核分工控制核与管理核的边界划分AMP 架构成败的关键在于分工边界是不是足够清楚。我个人倾向的划分方式是“CPU0 管控制CPU1 管管理”具体到代码模块上可以这样拆。CPU0 运行飞控核心IMU 数据采集、传感器数据融合、姿态估计、控制律计算、控制分配、电机输出、紧急停机逻辑。这些模块需要严格实时性CPU0 上不放任何可能阻塞的东西不用动态内存分配不用文件系统不用完整网络协议栈。CPU1 运行管理功能遥控信号解析、MAVLink 协议编解码、地面站通信、数传链路、SD 卡日志记录、参数管理、航点任务、传感器校准、状态监测。这些模块允许偶尔出现几百微秒的抖动因为它们的输出最终只会影响“信息流”不会直接影响“控制流”。这个边界画好之后两个核之间唯一需要交换的就是“精简的状态快照”。比如 CPU1 收到新的目标航点把它打包成一条消息发给 CPU0CPU0 计算完的姿态数据和控制输出周期性同步给 CPU1 去记录和上报。数据量很小通信压力极低内核之间耦合也很弱。3.2 共享内存、Mailbox 与核间中断HPM6750 的双核通信通常是“共享内存 核间中断”的组合。两个核心都能访问同一片物理内存但要用一套协议来避免同时读写造成的冲突。最常用的设计是环形缓冲区。发送方把数据逐个写入环形队列写完后更新写指针并触发核间中断接收方在中断服务程序里读取数据更新读指针。这里要特别注意指针的读写顺序写方要先写数据、再更新写指针读方要先读数据、再更新读指针。顺序一旦反了另一方就会读到半新的数据。核间中断由硬件 mailbox 机制触发。CPU0 通知 CPU1 时可以通过写一个触发寄存器产生中断CPU1 的处理方式同样。千万不要在中断服务函数里做重量级处理只负责把数据拷贝到接收缓冲区然后置位一个事件标志等核心的主循环或者 RTOS 任务去处理。3.3 RTOS 组合与 AMP 改造思路HPM6750 两个核可以都跑裸机也可以都跑 RTOS还可以“一个裸机一个 RTOS”。飞控项目我推荐至少管理核跑一个成熟的 RTOS比如 RT-Thread 或者 FreeRTOS因为管理核要处理的协议和任务太多了裸机循环很容易写成意大利面条。控制核就看团队习惯。如果是高度优化的飞控算法裸机加定时器中断反而更好控制如果想在控制核上也跑一些模块化任务RTOS 也没问题。关键是控制核的 RTOS 要足够精简最好禁止动态内存申请、禁止文件操作、禁止网络功能只保留任务调度、信号量、消息队列。如果使用 OpenAMP 或 RPMsg 这类标准化通信框架双核的启动顺序和共享内存布局可以由框架自动管理。但如果飞控场景希望把每个字节都拿在自己手里自定义共享内存协议反而更透明。我偏向自定义一个轻量协议理由有两条一是飞控的数据结构相对固定不需要通用序列化二是出了问题可以直接看内存排查链路短很多。4. 飞控系统关键模块拆分与实现4.1 传感器采集与姿态解算放在哪颗核我把 IMU 传感器采集放在 CPU0原因很直接姿态解算的实时性完全取决于传感器数据的新鲜度。IMU 通过 SPI 或 I2C 读取SPI 通常更快更稳定。如果 CPU0 直接用硬件 SPI 外设和定时器触发采样可以做到非常稳定的采样时刻。具体做法是把 IMU 采样放进定时器中断服务函数中断频率可以设置为 1kHz 或者更高。每次中断里读取加速度计和陀螺仪数据顺便读取磁力计和气压计数据然后把这些数据写入预先分配好的结构体再触发姿态解算任务。注意磁力计和气压计通常比较慢不能让它们阻塞主控制循环应当通过“每次都读但允许偶尔丢采样”的方式来处理。姿态解算我用的是扩展卡尔曼滤波。EKF 在飞控里很成熟但要注意矩阵维度和协方差更新频率。单核时代为了省算力大家喜欢降频解算双核环境下 CPU0 算力充足可以每个控制周期都做一次姿态更新解算结果的滞后明显减小后期调姿态阻尼的时候会少很多玄学参数。4.2 控制律与控制分配控制核的“心脏”控制律部分同样在 CPU0 完成典型结构是“外环位置控制 内环姿态控制”。外环输出的期望姿态角作为内环输入内环计算期望角速度最后通过 PID 或者更现代的控制方法输出期望力矩。控制分配层解决“期望力矩如何变成每个电机的转速差”的问题。四旋翼用固定混控矩阵倾转旋翼或者复合翼可能要动态切换分配矩阵。这部分的计算量不大但逻辑分支多放在 CPU0 能保证模式切换的即时性。电机输出我推荐使用定时器 PWM 或者 DShot。HPM6750 的 PWM 外设支持多路独立输出死区时间、互补输出这些也可以配置。如果用 DShot 协议注意在 DMA 传输时把数据准备好不要让 CPU 在控制周期里去逐位翻转电平。4.3 通信链路管理核的本职工作管理核承担了几乎所有通信链路遥控接收机、数传、地面站、机载电脑、图传协同数据。常见组合是 UART 接数传、UART 接 GNSS、USB 或 UART 接机载电脑、CAN 接电调或者外部传感器。MAVLink 协议解析在管理核上跑非常舒服。一串数据包进来交给协议层慢慢拆遇到 CRC 错误就丢弃不牵连控制逻辑。地面站的状态刷新频率一般也就几十赫兹在 MHz 级主频上根本不算负载。日志写入 SD 卡也是管理核的活文件系统偶尔因为坏块或者掉电产生延迟这正好是 AMP 架构的优势日志卡顿不会影响控制核。核间通信要把“控制核产出的关键状态”以固定频率同步给管理核。同步内容包括姿态四元数、加速度、角速度、控制输出、飞行模式、电池电压、故障标志等。管理核拿到这些数据后既可以塞进 MAVLink 消息上报也可以写入日志两个核各取所需。4.4 安全与故障处理机制飞控的故障处理必须横跨两个核。CPU0 负责最直接的安全响应电机输出超限、传感器数据无效、控制发散检测、紧急停桨。这些判断要在控制循环内完成一旦触发立刻将电机输出归零或者切到安全模式。CPU1 负责系统级健康监测电池电压偏低、GPS 失锁、遥控信号丢失、与地面站的通信超时、日志写入异常。它的处理动作通常是改变飞行模式、触发返航逻辑或者把故障码写入非易失存储。两个核之间的“健康心跳”也很重要。CPU0 可以每 10ms 给 CPU1 发一个心跳状态字CPU1 如果发现心跳停了说明控制核可能跑飞应当触发看门狗复位或者进入安全状态。反过来CPU1 也通过共享内存中的状态字告知 CPU0“管理核还活着”。这个握手机制能避免很多“系统半死不死”的诡异现象。5. 从原型到量产移植、调优和避坑5.1 从一个核启动到双核启动HPM6750 的双核启动方式需要认真看参考手册。常见流程是先从 Flash 引导 CPU0CPU0 完成时钟、引脚、内存等基础初始化再把 CPU1 的启动地址写入指定寄存器触发 CPU1 复位并开始执行 CPU1 程序。很多工程第一次跑双核时会遇到“CPU1 起不来”的问题。我排查的经验是先看 CPU1 的地址映射有没有和 CPU0 冲突再看链接脚本里的向量表位置对不对最后检查启动代码里的栈指针是否有效。建议前期先在两个核上各点一个 LED确认都能跑起来再往里加功能。这里有个容易踩的坑双核共用同一个 Flash 和时钟外设。CPU1 启动代码里如果又去做一次时钟初始化可能把 CPU0 已配置好的时钟重新改写导致系统崩溃。正确做法是 CPU1 启动后跳过系统时钟配置只初始化自己私有外设和中断控制器。5.2 缓存一致性共享内存的隐形杀手RISC-V 核心通常会带缓存而飞控里的共享内存如果被缓存“罩住”问题就来了。CPU0 写入共享数据后数据可能还留在 CPU0 的缓存里没有真正落到物理内存CPU1 去读物理内存时拿到的可能是旧数据。解决办法有三种思路。第一种是把共享内存区域配置成非缓存属性访问速度稍慢但一致性没问题第二种是在每次读写共享数据之前手动执行 cache clean 和 cache invalidate 操作第三种是只在核间中断触发的关键节点做缓存同步。我推荐第三种思路性能损失小逻辑也清晰。发送方更新共享数据结构后clean 相关缓存行再触发核间中断接收方在中断服务函数里先 invalidate 相关缓存行再读取数据。这里要小心clean 和 invalidate 的地址范围要覆盖整个共享数据结构别只处理结构体开头几个字节。5.3 中断优先级与实时性调优双核飞控的实时性调优核心就是“让控制路径上的中断尽量不被延迟”。一块板子刚画完IMU 和数传都接好了第一版测试偶发出现控制中断抖动往往是因为某个低优先级中断服务函数写得太长或者多个中断共用同一个优先级导致相互阻塞。调优步骤可以这样来先列一张中断清单按“控制必经路径”“外围提示路径”“后台处理路径”分三档。IMU 采样中断、控制律更新定时器中断、电机输出相关 DMA 完成中断放在最高档核间通信中断、遥控输入捕捉中断放在中档UART 接收、SD 卡写入完成中断放在最低档。还要留意中断服务函数本身的长度。UART 接收中断如果一帧一帧做协议解析肯定会拖垮系统。正确做法是中断里只把数据拷进环形缓冲区解析全部放到管理核的任务里去做。这就是 AMP 架构带来的调整空间控制核做减法管理核做加法。5.4 日志、调试与现场问题定位飞控试飞阶段没有日志就像闭眼开车。HPM6750 管理核有富余算力可以安排一个任务专门写飞行日志。日志内容最好包含时间戳、原始传感器数据、姿态估计、控制输出、核间通信计数、CPU 负载、异常标志。写日志的最大坑是文件系统操作阻塞。SD 卡在高速写入时如果出现坏块写操作可能占用几十毫秒管理核虽然不会卡控制核但如果共享内存里的待记录数据来不及取走控制核的发送缓冲还是可能溢出。我的处理方法是控制核只把日志放进一个独立的共享内存环形缓冲区管理核按自己的节奏去消费消费不及时大不了丢日志不影响飞行。现场调试时两个核各自的串口输出建议分开接方便用不同串口分别观察。CPU0 打印姿态和控制信息CPU1 打印通信和任务信息。不要在管理核的串口中断里去做复杂处理调试信息打印本来就是低优先级能丢就丢别让它反过来拖累系统。6. 一版可参考的配置设计与性能摸底6.1 内存分区与链接脚本实践HPM6750 的片上 SRAM 需要明确划分控制核私有堆栈、管理核私有堆栈、共享内存区、日志缓冲区、通信缓冲区。给大家一个比较保守的划分思路单位 MB区域用途CPU0CPU1说明代码与只读数据一部分一部分各自独立访问堆栈与私有变量一部分一部分互不访问共享内存区双方可读写双方可读写固定地址、固定大小日志环形缓冲只写只读管理核消费协议缓冲池只读只写管理核产生共享内存区的地址必须在两个核的链接脚本里约定一致。实际写代码时建议把所有跨核数据结构集中放到一个头文件里命名规范带明确前缀避免两边数据结构定义不一致。只要一个结构体没对齐排查起来会非常痛苦。6.2 核间通信协议与对应参数我常用的一套核间通信协议非常精简头两个字节是消息 ID 和长度后面跟着固定结构体。控制核往管理核发的是姿态和状态帧管理核往控制核发的是指令和参数帧。消息 ID 要维护一张表比如 0x01 表示姿态状态帧0x02 表示 GPS 位置帧0x10 表示飞行模式指令0x11 表示参数写入请求。每帧数据都带一个简单的 16 位校验和接收方对不上就丢帧。协议越简单越容易维护别在共享内存里搞 JSON 或者 XML 这类东西性能和可排查性都不好。核间中断的频率不需要太高。控制核可以 5ms 发一次状态帧管理核可以 20ms 发一次指令帧紧急指令通过快速通道触发其他数据走普通队列。过高的核间通信频率除了增加缓存同步成本并不会让系统更稳定。6.3 实测数据与设计余量参考双核架构调完一轮之后我习惯跑一组固定测试来记录基线数据。测试内容包括单核 CPU 负载、双核 CPU 负载、控制环最大延迟、控制环延迟抖动、核间通信最大耗时、日志持续写入耗时。具体数值会因代码效率和外设配置不同有差异但我在类似配置下得到的结果是控制核的 1kHz 控制环最大延迟能稳定控制在几十微秒级别抖动远小于单个控制周期。管理核跑 MAVLink、日志和遥控解析时只占用了部分算力还剩下不少余量给后续扩展。对飞控这种产品来说这个余量是真正的安全感来源。板上调试时可以额外安排一个硬件 GPIO 用于测量控制环执行时间用示波器抓波形比任何软件统计都直观。我强烈建议把这个 GPIO 测试点保留到量产阶段现场飞行出问题的时候示波器一夹就能判断控制循环有没有超时省下大量瞎猜的时间。6.4 从参考设计到实际产品的落地建议最后聊一点系统层面的建议。HPM6750 双核给了飞控设计很大的自由度但自由度也意味着约束变少团队必须自己定好工程规范。两个核的代码建议放在同一个仓库里管理编译产物分开烧录地址固定版本号统一。核间通信协议一旦发布就要走变更流程不能某天临时改结构体就偷偷上线。硬件设计上晶振、电源和复位电路要认真处理。MCU 主频跑高之后电源纹波对 ADC 采样和传感器精度的影响会被放大飞控板上建议给模拟电源和数字电源做适当的隔离设计IMU 的供电更要单独滤波。MCU 选型时盯着大外设数量看没问题量产时盯着电源和地看才是真功夫。我见过不少项目在原型阶段跑得欢一到量产就出现“同一套代码有的板子稳有的板子飘”的情况最后查出来全是硬件布局和供电的问题。双核再强也架不住模拟部分被数字噪声污染。所以别把 HPM6750 当成普通 MCU 随便布板它跑到 800MHz 级别时整个板子的设计规则都要跟着升级。个人在实际操作中的体会是非对称双核架构真正解决了飞控开发里那个老矛盾想要控制足够硬又想要功能足够多。单核时代靠调度器两头讨好的日子已经到头了。如果你正在评估下一代飞控主控建议拿 HPM6750 的评估板先跑一版最小双核通信 demo再把控制环放上去测延迟感受会比看参数表直观得多。等这套结构跑顺了你会发现后面加功能、加协议、加算法都变成了一件相对轻松的事。
