4、PX4固件编译与烧录：make编译系统、目标板配置、固件烧录方法（JTAG/SWD、USB）、固件版本管理。
编译和烧录，说白了就是把我们写的代码变成飞控能跑的东西。很多新手在这一步就卡住了——编译报错看不懂，烧录进去飞控没反应。我刚开始搞PX4的时候，也在这上面折腾了好几天。
这一章，我把这些年踩过的坑和总结的经验都抖出来。你跟着走一遍，基本就能搞定。
核心要点：PX4使用CMake + Make的编译系统，通过make命令加目标板参数来构建固件。烧录方式主要有三种：USB（最常见）、JTAG/SWD（调试用）、SD卡（批量部署）。
4.1 make编译系统：到底在干什么？
PX4的编译系统，说白了就是一套自动化工具链。你敲一个make px4_fmu-v5_default，它就会自动帮你完成：配置、编译、链接、生成固件。
我个人习惯把编译过程拆成三步理解：
- 配置阶段：读取目标板的配置文件，确定用哪些驱动、哪些模块。
- 编译阶段：把C++源码编译成机器码。
- 链接阶段：把所有目标文件打包成一个可执行的固件镜像。
为什么会这样设计？因为PX4要支持几十种飞控板，每块板的硬件资源都不一样。通过配置文件来管理，你换块板子只需要改个参数，不用重写代码。
小技巧：编译时加-j4参数可以加速，比如make px4_fmu-v5_default -j4。这个参数指定并行编译的线程数，一般设成你CPU核心数的1.5倍左右。
4.2 目标板配置：选对板子才能飞
PX4支持的目标板，都定义在boards/目录下。每个板子有一个独立的文件夹，里面放着配置文件。
常用的目标板命名规则是这样的：
| 目标板名称 | 对应硬件 | 适用场景 |
|---|---|---|
px4_fmu-v5_default |
Pixhawk 4 / FMUv5 | 通用四旋翼、固定翼 |
px4_fmu-v2_default |
Pixhawk 1 / FMUv2 | 老款飞控、教学用 |
px4_fmu-v3_default |
Pixhawk 2.1 / FMUv3 | 兼容性较好的中间代 |
sitl_default |
软件在环仿真 | 无硬件调试、算法开发 |
嗯，这里要注意：不要随便选一个板子就编译。我在项目中遇到过有人用FMUv2的固件刷到FMUv5的板子上，结果传感器全部不工作。因为不同版本的硬件映射地址不一样。
警告：编译前一定要确认你的飞控板型号。可以在板子上找丝印，或者用nsh> board_id命令查看。刷错固件可能导致飞控变砖。
4.3 固件烧录方法：把代码写进飞控
固件编译好了，怎么弄到飞控里？有三种主流方式。我按推荐程度排个序：
4.3.1 USB烧录（最常用）
这是最方便的方式。飞控通过USB连电脑，直接拖拽或命令行烧录。
具体步骤：
- 用USB线连接飞控和电脑
- 进入飞控的bootloader模式（一般是按住reset键再上电）
- 执行烧录命令：
make px4_fmu-v5_default upload
你想想看，整个过程就一条命令。PX4会自动检测USB设备，把固件传过去。
经验之谈：如果upload命令报错说找不到设备，八成是驱动问题。Linux下检查lsusb，Windows下检查设备管理器。我遇到过好几次，都是因为USB线质量太差导致通讯不稳定。
4.3.2 JTAG/SWD烧录（调试专用）
JTAG和SWD是专业的调试接口。它们不仅能烧录，还能单步调试、查看变量、设置断点。
什么时候用这个？
- 飞控变砖了，USB烧录不进去
- 你需要调试底层驱动，比如I2C时序问题
- 量产时批量烧录
常用的调试器有：ST-Link、J-Link、Black Magic Probe。接线方式一般是：
| 调试器引脚 | 飞控板引脚 | 说明 |
|---|---|---|
| SWDIO | SWDIO | 数据线 |
| SWCLK | SWCLK | 时钟线 |
| GND | GND | 地线 |
| 3.3V | VCC | 供电（可选） |
我曾经有一次，飞控刷了错误的bootloader，USB彻底不认了。最后靠J-Link硬生生把正确的固件灌进去才救回来。所以，搞飞控的，手边备一个调试器没坏处。
4.3.3 SD卡烧录（批量部署）
这个方法适合量产场景。把固件文件放到SD卡里，插到飞控上，上电自动刷写。
步骤很简单：
- 编译生成
.px4固件文件 - 改名为
firmware.px4 - 复制到SD卡根目录
- 插入飞控，重新上电
飞控检测到SD卡里有固件文件，就会自动进入烧录流程。烧录完成后，文件会被自动删除或重命名。
注意：SD卡烧录时不要断电。我曾经在测试时手贱拔了卡，结果固件写到一半，飞控直接变砖。后来用JTAG才救回来。
4.4 固件版本管理：别让版本乱飞
做项目最怕什么？版本混乱。今天改了这个，明天改了那个，最后都不知道飞控里跑的是哪个版本。
我个人的做法是这样的：
- 用Git标签管理发布版本：每次稳定版本打一个tag，比如
v1.12.3 - 在固件里嵌入版本号：PX4编译时会自动从Git获取commit信息，生成版本字符串
- 通过MAVLink读取版本：地面站可以读到飞控的固件版本，方便排查问题
你可以用ver all命令在NSH终端里查看当前固件版本：
nsh> ver all
PX4 git-hash: 7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6
PX4 version: 1.12.3
PX4 build: stable
嗯，这里有个坑：不要依赖文件名来管理版本。我见过有人把固件命名为final_final_v2.px4，结果过了一个月自己都分不清哪个是最新的。用Git tag + 自动版本号，才是正道。
总结一下：编译用make加目标板名，烧录用upload命令或JTAG/SWD，版本管理靠Git。这三板斧练好了，固件这块你就稳了。