📚 课程目录第3章开发环境搭建

3. 开发环境搭建

MCU 与 Linux UI 协同开发的最大特点，是同一套产品里同时存在两类完全不同的运行环境：一端是资源受限、运行裸机或 RTOS 的 MCU，另一端是运行 Linux、具备完整进程与图形栈的应用处理器。开发主机通常是 x86_64 的 PC，而目标板可能是 ARM Cortex-M、Cortex-A、RISC-V 等架构。因此，开发环境搭建的核心不是“装几个软件”，而是建立一条从主机到目标板、从源码到可执行文件、从运行现象到调试信息的完整链路。

本节目标：搭好三件套——交叉编译工具链（能编）、调试工具（能查）、版本控制（能管）。三者缺一不可，且必须与目标板的 CPU 架构、ABI、系统库版本严格匹配。

一、核心原理：为什么必须交叉编译

MCU 与 Linux 端的 CPU 架构通常与开发主机不同。主机上的 gcc 生成的是 x86_64 指令，无法在 ARM 目标板上运行。交叉编译工具链（cross toolchain）就是“在 A 架构主机上生成 B 架构可执行文件”的编译器集合，一般包含 gcc、g++、binutils（ld、as、objcopy、objdump）、glibc 或 musl、gdb 等。

工具链的命名前缀直接暴露了它的目标：arm-none-eabi- 表示面向 ARM 裸机（无操作系统、EABI），常用于 MCU；arm-linux-gnueabihf- 表示面向 ARM Linux、使用硬浮点 ABI，常用于 Cortex-A 应用处理器；aarch64-linux-gnu- 则面向 64 位 ARM Linux。选错前缀，轻则链接失败，重则程序在板上跑飞。

MCU 侧与 Linux 侧的工具链选择逻辑不同：MCU 侧关注 --specs=nano.specs、-mcpu、-mthumb 等裸机参数；Linux 侧关注 sysroot、动态链接器路径、glibc 版本兼容性。二者可以共用同一台主机，但必须放在不同目录、使用不同环境变量，避免 PATH 冲突。

二、方法流程：从零搭建可复现环境

确认目标信息：读取目标板手册，确认 CPU 架构、ABI、内核版本、根文件系统类型（glibc/musl）、是否带 FPU。
安装或构建工具链：优先使用厂商 SDK 自带工具链（如 STM32CubeIDE、Yocto SDK、Buildroot 输出），保证与板级支持包一致；也可用 crosstool-NG 或 buildroot 自行构建。
配置环境变量：将工具链 bin 目录加入 PATH，并设置 CROSS_COMPILE、SYSROOT。
验证工具链：编译最小程序并在目标板运行，确认架构与动态库匹配。
安装调试工具：MCU 侧用 OpenOCD + GDB，Linux 侧用 gdbserver + 交叉 gdb，UI 侧可辅以日志与性能工具。
建立版本控制：初始化 Git 仓库，配置 .gitignore，用分支管理 MCU 固件、Linux 应用与 UI 资源。

# 以 ARM Linux 工具链为例
export CROSS_COMPILE=arm-linux-gnueabihf-
export PATH=/opt/toolchain/bin:$PATH
export SYSROOT=/opt/toolchain/arm-linux-gnueabihf/sysroot

# 验证
${CROSS_COMPILE}gcc -v
${CROSS_COMPILE}gcc hello.c -o hello --sysroot=$SYSROOT
file hello
# 期望输出：ELF 32-bit LSB executable, ARM, EABI5 ...

三、调试工具：MCU 与 Linux 两条链路

MCU 侧调试依赖 SWD/JTAG 物理接口。典型链路是：IDE 或 GDB → OpenOCD → 调试探针（ST-Link、J-Link、CMSIS-DAP）→ MCU 的 SWD 引脚。OpenOCD 负责把 GDB 的远程协议翻译成芯片调试单元能理解的时序，因此配置文件必须选对芯片型号与接口。

Linux 侧调试常用 gdbserver：目标板上运行 gdbserver :1234 ./app，主机上用交叉 gdb 执行 target remote 192.168.1.10:1234，即可远程断点、查看调用栈。对于 UI 卡顿、渲染异常，还需结合 perf、strace、ltrace 与自研日志系统定位。

协同开发中一个常见场景是：MCU 采集传感器数据，通过串口/SPI 发给 Linux UI 显示。若 UI 数据不刷新，需要同时判断是 MCU 没发、链路丢包，还是 Linux 应用没读。此时调试工具的价值在于分段隔离：先用逻辑分析仪看物理信号，再用 gdbserver 看应用是否阻塞，最后用 MCU 断点确认发送逻辑。

四、版本控制：多仓协同与分支策略

MCU 固件、Linux 应用、UI 资源往往由不同成员维护，建议采用“单仓多目录”或“多仓 + 子模块”两种模式。单仓便于统一版本号与联调；多仓适合权限隔离与独立发布。无论哪种，都应遵循：源码入库、构建产物不入库、工具链版本可追溯。

类别	典型内容	是否入库	说明
源码	MCU C 代码、Linux 应用、QML/HTML 资源	是	按功能分支开发
构建脚本	Makefile、CMakeLists、Yocto recipe	是	保证可复现
工具链	交叉编译器、SDK	否	记录版本号与下载地址
产物	.elf、.bin、.so、镜像	否	由 CI 生成并归档
配置	设备树、环境变量、密钥	部分	密钥用模板或加密管理

# 推荐的 .gitignore 片段
build/
out/
*.o
*.elf
*.bin
*.so
.vscode/
__pycache__/

五、误区与复盘

误区一：主机 gcc 能编就行。主机编译通过不代表目标板能跑，必须用 file 和 readelf -A 检查架构与 ABI。
误区二：工具链越新越好。新工具链可能引入新 glibc 符号，导致目标板旧根文件系统无法加载。应以 SDK 配套版本为准。
误区三：调试只靠 printf。printf 在实时性要求高的 MCU 场景会阻塞，且无法查看寄存器与内存。应尽早接入 GDB/OpenOCD。
误区四：版本控制只提交代码。构建脚本、设备树、UI 资源同样需要版本化，否则联调时无法复现问题。

建议在项目根目录放置 env.sh，统一导出工具链路径与目标参数；新成员只需 source env.sh 即可获得一致环境，减少“我这里能编”的沟通成本。

完成以上三件套后，团队就具备了一条可复现、可调试、可追溯的协同开发链路。后续无论是 MCU 固件升级、Linux UI 迭代，还是二者联调排障，都能在同一套环境约定下高效推进。