最近好几拨人问我同样一个问题STM32开发到底要不要自己装ARM-GCC交叉编译链有的人是被命令行劝退有的人觉得Keil用得好好的没必要折腾还有人在GitHub上拉了个开源项目发现全是Makefile直接懵了。先给个直接回答不装也能做STM32开发但只要你碰过Linux环境、CI自动编译、开源代码移植或者Visual Studio Code配插件这套玩法ARM-GCC迟早要装。而且说实话一旦你理解了它的编译选项在干什么再回头看Keil的魔术棒界面反而会觉得那些选项其实都见过只是被图形界面包装起来了。这篇文章不打算写得像man手册那样逐条翻译而是把实际开发中最常用、最关键、最容易出问题的编译选项拿出来拆开讲。读完你至少能看懂一份Makefile里那几行CFLAGS是什么含义能自己调参数控制代码体积和调试体验遇到“编译过了但跑不起来”的情况也知道从哪个选项开始排查。1. ARM-GCC到底是什么STM32开发真的离不开它吗1.1 从“交叉编译”这个概念说起交叉编译的意思很直白你的电脑是x86架构但STM32芯片是Cortex-M架构两种CPU的机器码完全不一样。编译器做的就是“在一台机器上生成另一种机器能跑的代码”这件事这就是“交叉”二字的本意。ARM-GCC就是专门为ARM架构定制的一套GCC工具链和你在Linux上用的gcc同宗同源只是目标平台换成了ARM。它里面包含几个核心组件arm-none-eabi-gccC/C编译器负责把源码变成汇编再变成机器码arm-none-eabi-as汇编器负责把汇编代码变成目标文件arm-none-eabi-ld链接器负责把多个目标文件组合成最终的ELF文件arm-none-eabi-objcopy格式转换工具把ELF转成hex或bin烧录文件arm-none-eabi-size查看各段体积的工具arm-none-eabi-gdb调试器其中none表示没有操作系统bare metaleabi表示嵌入式应用二进制接口。这套工具链下载解压就能用不需要安装配好环境变量就行。我自己用的版本是gcc-arm-none-eabi-10.3-2021.10后面所有命令行示例都基于这个版本。1.2 有Keil和STM32CubeIDE为什么还要自己装ARM-GCCKeil和STM32CubeIDE本质上都内置了自己的编译器Keil用的是ARMCC新版本叫AC6CubeIDE用的是集成好的GCC。你确实可以不单独装ARM-GCC就完成开发。但有几个场景绕不开它。第一个是CI自动化编译。产品代码往Git仓库一推服务器上跑脚本自动编译检查服务器不可能装Keil要授权、要图形界面而ARM-GCC免费、开源、纯命令行正是CI环境的标准选择。第二个是跨平台。团队里有人用Windows有人用macOS有人用LinuxKeil只能在Windows上用而ARM-GCC三个平台都有大家用同一套Makefile就能保证编译结果一致。第三个场景我现在碰得特别多——从开源项目移植代码。GitHub上有大量STM32的开源工程是纯Makefile或者CMake组织的不用ARM-GCC你根本编译不了。反过来讲如果你会看编译选项把一个Keil工程翻译成Makefile工程也就是一两个小时的事。1.3 怎么判断你的环境到底缺不缺这东西我给你一个最简单的判断方法在命令行输入arm-none-eabi-gcc --version如果提示找不到命令而你正好符合下面任意一条那你就需要装了你准备在Linux或macOS上开发STM32你想用VS Code cortex-debug插件做开发调试你需要跑GitHub上那些用Makefile管理的开源例程你的项目需要接入自动化编译流程你想彻底搞明白程序从源码到烧录文件中间发生了什么装好之后不用急着写代码先拿一个现成的工程STM32CubeMX生成的Makefile工程就行编译一遍再回头来看这篇文章的选项解释每个参数你都会有实感。2. 架构与指令集选项决定你的代码跑在什么模式上2.1 -mcpu与-march告诉编译器你的芯片是谁这是整个编译命令里最关键的一行。-mcpu指定具体的CPU型号-march指定架构版本。看一个编译命令就知道开发者用的是哪颗芯片就是靠这个参数。比如STM32F103C8T6是Cortex-M3内核常见的写法是arm-none-eabi-gcc -mcpucortex-m3 -mthumb -c main.c -o main.o如果是STM32F407VECortex-M4内核且带FPU就要写arm-none-eabi-gcc -mcpucortex-m4 -mthumb -mfloat-abihard -mfpufpv4-sp-d16 -c main.c -o main.o这里有个初学者很容易踩的坑-mcpu和-march不需要同时写满了。GCC官方的建议是-mcpu已经包含了具体内核的完整信息含架构版本、FPU等所以只要指定了-mcpu-march可以省略。反过来如果你用-march指定架构版本还要再配合-mtune去优化特定内核的指令调度。实际工程里99%的Makefile都只写-mcpu。那什么情况会用到-march做汇编级优化、对不同内核统一架构版本做兼容编译时才会用到。比如你要打一个同时兼容Cortex-M3和Cortex-M4的库但只使用ARMv7-M通用的指令就会把-mcpu换成-marcharmv7-m。2.2 -mthumb与-marmARM模式与Thumb模式的取舍这两个选项决定编译器生成的指令集是16位的Thumb指令还是32位的ARM指令。Cortex-M系列内核只支持Thumb指令所以STM32工程里的-mthumb基本是必写的。你可能会问那-marm存在还有什么意义它主要用在Cortex-A系列处理器上比如跑Linux的芯片这些核同时支持ARM和Thumb两种模式。当你在Cortex-A上做裸机开发时可以选择-marm获得更高的性能和更丰富的指令代价是代码体积变大选择-mthumb则代码更紧凑但性能略有损失。在Cortex-M上有个更隐蔽的问题中断函数和某些特殊函数需要__attribute__((naked))修饰成完全不带栈帧的形式这种函数如果用Thumb模式写汇编注意要用.thumb伪指令声明。我自己第一次写向量表的时候就因为这个原因启动文件里的中断向量编译完地址对不上Debug调试进不去排查了半天。这里建议直接经验启动文件startup_xxx.s、链接脚本ld文件这类汇编和链接层面的东西优先用芯片厂商生成的原始文件别自己手写尤其是别顺手改指令集模式。Cortex-M0/0没有-marm可选Cortex-M3及以上默认也是Thumb这块选项基本固定。2.3 -mfloat-abi与-mfpu浮点运算最常见的坑这两个选项在Cortex-M4F和Cortex-M7等带FPU浮点运算单元的芯片上特别重要也是让很多新手程序“编译过了但运行结果全乱”的元凶。-mfloat-abi有三个值soft、softfp、hard。soft完全不使用FPU用软件模拟浮点运算。任何Cortex-M芯片都支持但浮点运算极慢。softfp使用FPU硬件指令但函数调用时浮点参数仍然通过通用寄存器传递。兼容性好但调用效率有损失。hard使用FPU硬件指令且函数调用时浮点参数用FPU寄存器传递。效率最高但要求整个工程包括库、启动文件都用同一套float-abi编译。实际项目中STM32F4系列绝大多数都选hard配合-mfpufpv4-sp-d16。代价就是你在移植一些第三方库时如果对方库编译时用的softfp而你工程整体用hard链接的时候就会报“incompatible float ABI”之类的错误。解决办法一般是统一重新编译库或者把自己的工程切回softfp。-mfpu指定FPU的硬件特性STM32F4是单精度FPU对应fpv4-sp-d16部分STM32F7和H7支持双精度对应fpv5-d16。如果选错了编译能过但浮点指令会产生硬件异常HardFault程序直接死机而且不好查。一个经验之谈遇到浮点相关HardFault先查这个选项和芯片型号是否符合。2.4 一个典型Cortex-M的编译参数案例拿STM32F103Cortex-M3和STM32F407Cortex-M4F做个对比你就能直观感受到不同的选项组合芯片内核常用编译选项STM32F103C8T6Cortex-M3-mcpucortex-m3 -mthumbSTM32F407VET6Cortex-M4F-mcpucortex-m4 -mthumb -mfloat-abihard -mfpufpv4-sp-d16STM32H743VIT6Cortex-M7F-mcpucortex-m7 -mthumb -mfloat-abihard -mfpufpv5-d16这里要注意Cortex-M7的-mcpu如果写成cortex-m7GCC在10以上版本会默认启用双精度FPU指令所以如果你的H7芯片实际只用了单精度浮点反而要显式加一句-mfpufpv5-sp-d16避免生成芯片不支持的双精度指令。这类“默认值不代表最优值”的例子在GCC里非常多。3. 优化选项同样功能体积和速度差出一大截3.1 -O0到-Os怎么选优化等级是编译选项里影响最直观的一组直接决定编译出来的代码长什么样。ARM-GCC从高到低主要支持-O0、-O1、-O2、-O3、-Os含义分别是-O0不做任何优化编译速度最快但代码体积最大、执行速度最慢。调试体验最好变量随时能看到单步执行不会乱跳。-O1做基本优化代码体积和速度都有改善调试还勉强能用。-O2更激进的优化执行速度快但调试时经常发现变量被优化掉断点位置和源码对应不上了。-O3极限性能优化会做函数内联、循环展开等操作代码体积急剧膨胀但实际MCU项目中很少用。-Os优先优化代码体积在尽量小的情况下兼顾速度。对Flash紧张的MCU来说是最常用的选项。我之前调试一个电机控制程序用-O2编译结果示波器看PWM输出频率和理论值差了几乎一倍。一开始以为是定时器配置错了排查半小时无果。后来把优化等级降到-O0频率恢复正常才反应过来是编译器把某个紧耦合的循环里变量计算提前或合并了导致时序不对。从那以后凡是对时序敏感的代码我都会在源文件里加一句#pragma GCC optimize(O0)只对这一函数关闭优化整个工程该用-Os的继续用-Os。3.2 -ffunction-sections和-fdata-sections链接器裁剪的前提这两个选项本身不做优化它们的作用是给链接器“剪枝”创造条件。默认情况下GCC编译生成目标文件时同一个源文件里的所有函数和全局变量都会放在同一个section里。假设你写了10个函数只用到其中1个链接器也没办法只保留这1个因为整个section要么全要、要么全不要。芯片Flash本来就不大这种浪费特别可惜。加了-ffunction-sections之后GCC会把每个函数都放进独立的section加了-fdata-sections则让每个全局变量也独立成段。这样链接器就有能力逐个筛选用到的部分。但光有这两个还不够你还需要让链接器在链接阶段真正做删除动作这就是下面要说的-Wl,--gc-sections。3.3 -Wl,--gc-sections到底删了什么-Wl,是GCC往链接器传参数的固定写法--gc-sections就是告诉链接器“帮我删除未被引用的section”。这几个选项配合起来是嵌入式开发里控制代码体积最经典的一套组合拳arm-none-eabi-gcc -mcpucortex-m3 -mthumb -Os \ -ffunction-sections -fdata-sections \ -Wl,--gc-sections \ -T stm32f103c8t6_flash.ld \ main.o startup.o \ -o firmware.elf我实测过一组数据一个包含HAL库全量编译的STM32F103工程不开gc-sections时固件体积约92KB开了之后降到约28KB。差别就是这么大。原因很简单HAL库每个外设都有独立源文件但一个工程真正用到的外设可能就三五个其余几万行代码全被裁掉了。这里有个要提醒的点--gc-sections必须和-ffunction-sections、-fdata-sections配套使用否则链接器没有独立section可以裁剪选项等于白写。还有一种情况是你用了弱符号__attribute__((weak))中断回调函数有些编译器优化会把未被引用的中断函数裁掉导致中断响应不了。解决方法是把中断函数标记为__attribute__((used))或者在链接脚本里用KEEP()指令强制保留。我遇到过两次这种“编译正常、中断不进”的情况一次是忘了KEEP中断向量表一次是GPIO回调函数被当成了无引用代码剪掉。4. 链接、启动文件与标准库选项能不能跑起来的最后一环4.1 -T链接脚本内存布局说明书编译选项不只有-mcpu和-O2这类看起来跟性能相关的-T指定链接脚本是整个工程能否运行的底座。链接脚本后缀通常为.ld或.lds定义了芯片的Flash从哪里开始、RAM从哪里开始、各段数据放在什么位置。用STM32F103C8T6举例内部Flash从0x08000000开始共64KBRAM从0x20000000开始共20KB。链接脚本的核心就是把这些信息告诉链接器顺带告诉它向量表放哪、堆栈大小设多少、.bss段从什么地址开始清零。一个常见的错误是把另一颗芯片的链接脚本直接拿过来用。比如把F103的脚本用在F407上程序也能编译释放烧进去就死。因为F103 Flash只有64KB脚本里的Flash长度定义可能锁死了生成代码的上限RAM大小不对也会导致链接器把栈顶地址设到不存在的内存区域。排查方法很简单打开map文件看尾部内存使用情况或者直接用arm-none-eabi-size看各段分布。我自己习惯在工程里额外跑一条命令验证内存是否超限arm-none-eabi-size firmware.elf输出里text、data、bss三列分别对应代码只读数据、已初始化数据、未初始化数据把它们和芯片实际Flash/RAM一对比就能看出是否放得下。4.2 -nostartfiles和启动文件的关系-nostartfiles的意思是“链接时不要自动链接标准的启动文件”。标准启动文件是GCC自带的crt0.o等主要做进入main之前的运行时初始化。在裸机嵌入式里这些标准启动文件和芯片的启动流程对不上通常不需要。实际工程里Cortex-M芯片的启动流程是芯片上电 - 从向量表取栈顶地址和复位处理函数地址 - 执行复位函数 - 调用SystemInit配置时钟 - 跳转main。这个流程里启动文件是芯片厂商提供的startup_xxx.s和你是否加-nostartfiles没有直接关系。那什么时候会用到-nostartfiles当你自己用汇编或C实现了完整的启动流程不希望链接器再额外加入GCC的运行时初始化代码时就加上它。大多数由STM32CubeMX生成的Makefile工程不会显式加这个参数因为它默认的启动流程已经被startup文件覆盖了。如果你在链接时遇到crt0.o相关的符号冲突或者发现编译出来的固件里莫名多了一段执行代码可以考虑试试-nostartfiles。顺带一提与它配套的还有-nodefaultlibs不链接默认库和-nostdlib完全不链接标准库和启动文件。这三个参数一个比一个激进新手不推荐轻易尝试。踩过一次坑之后我的态度是启动流程能不动就不动芯片厂商给的例程怎么说就怎么配。4.3 --specsnano.specs和printf浮点支持问题这个选项在我解答的“编译了但串口打印小数全是0”问题里出现了无数次。ARM-GCC默认链接的是newlib标准C库但它比较复杂代码体积大。用--specsnano.specs可以切换到为嵌入式优化的精简版newlib-nano库体积能减小不少。代价是数学函数精度下降、某些POSIX特性缺失。newlib-nano里面最坑的一点是printf族函数的浮点格式化支持默认是关闭的。哪怕你用了%f格式符输出的也全是0或者乱码。解决办法是在链接选项里加上-u _printf_floatarm-none-eabi-gcc ... --specsnano.specs -u _printf_float ...-u _printf_float的意思是告诉链接器“强制引用这个符号”链接器就会把printf的浮点支持模块拉进来。代价是代码体积会增加约几千字节。单片机串口打印调试是刚需所以我给你的实用建议是Release版本不加_printf_float把浮点转成整数再打印比如打印12345代表12.345这样代码体积小。Debug版本加上_printf_float调完好去掉别让固件包里白背这块重量。4.4 一个查选项用的实用技巧ARM-GCC自带的文档离线不加搜索可能看不下去但我每次不确定某个选项的含义时最常用的不是网上搜而是直接让GCC自己解释。想知道某选项支持哪些取值用arm-none-eabi-gcc --helptarget想确认某个选项是否真的生效用arm-none-eabi-gcc -mcpucortex-m4 -mthumb -mfloat-abihard -mfpufpv4-sp-d16 -Q --helptarget | grep float-Q选项会打印最终生效的选项值比如你只写了-mfpufpv4-sp-d16它能告诉你实际生效的float-abi是hard还是softfp。这对排查“为什么我写了hard但浮点性能没提升”之类的问题特别有用。还有一个我每次都会检查的把预处理后的宏定义打印出来确认编译器确实定义了对应型号的宏arm-none-eabi-gcc -mcpucortex-m4 -mthumb -dM -E - /dev/null | grep ARM输出里能看到__ARM_ARCH_7EM__、__ARM_FP这类宏对比一下就知道CPU配置是否按预期生效。5. 直接能抄的编译实操从命令行到Makefile5.1 一个完整的STM32编译命令把前面这些选项组合起来一个工程的最小完整编译流程分三步编译、链接、转格式。第一步把几个源码文件分别编译成目标文件arm-none-eabi-gcc -mcpucortex-m3 -mthumb \ -Os -ffunction-sections -fdata-sections \ -I./inc -I./Drivers/CMSIS/Include \ -c ./src/main.c -o ./build/main.o注意-c表示只编译不链接-I指定头文件搜索路径。每个.c文件都执行一遍这条命令生成对应的.o文件。源文件多的时候用Makefile的自动规则更省事。第二步链接所有目标文件arm-none-eabi-gcc -mcpucortex-m3 -mthumb \ -Wl,--gc-sections -T stm32f103c8t6_flash.ld \ ./build/main.o ./build/stm32f1xx_hal_msp.o ./build/startup_stm32f103xb.o \ --specsnano.specs -Wl,--start-group -lc -lm -Wl,--end-group \ -o ./build/firmware.elf这里有几个点说明一下。-Wl,--start-group和-Wl,--end-group把后面的大括号内库文件包在里面作用是让链接器循环扫描这些库解决库之间的循环依赖。裸机工程里libc和libm的依赖关系有时会出现“谁引用谁”的环不加这个就可能报undefined reference。-lc是C标准库-lm是数学库。第三步转成烧录文件arm-none-eabi-objcopy -O ihex ./build/firmware.elf ./build/firmware.hex # 或者生成bin文件 arm-none-eabi-objcopy -O binary ./build/firmware.elf ./build/firmware.binhex是Intel格式ST-Link、J-Link、串口ISP都能直接用bin是纯二进制需要知道烧录基地址烧录器通常默认写0x08000000对STM32来说没问题。5.2 Makefile里怎么写实际项目里没人会把这三条命令在终端里手敲几十遍都写在Makefile里自动执行。我比较习惯的写法是定义一个变量保存公共编译参数再按规则编译CROSS_COMPILE arm-none-eabi- CC $(CROSS_COMPILE)gcc OBJCOPY $(CROSS_COMPILE)objcopy SIZE $(CROSS_COMPILE)size CPU -mcpucortex-m3 -mthumb OPT -Os CFLAGS $(CPU) $(OPT) -ffunction-sections -fdata-sections CFLAGS -I./inc -I./Drivers/CMSIS/Include LDFLAGS $(CPU) -Wl,--gc-sections -T stm32f103c8t6_flash.ld LDFLAGS --specsnano.specs -Wl,--start-group -lc -lm -Wl,--end-group SRCS main.c stm32f1xx_hal_msp.c startup_stm32f103xb.s OBJS $(patsubst %.c,./build/%.o,$(filter %.c,$(SRCS))) OBJS $(patsubst %.s,./build/%.o,$(filter %.s,$(SRCS))) all: ./build/firmware.hex ./build/firmware.elf: $(OBJS) $(CC) $(LDFLAGS) $^ -o $ ./build/%.o: %.c | ./build $(CC) $(CFLAGS) -c $ -o $ ./build/%.o: %.s | ./build $(CC) $(CFLAGS) -c $ -o $ ./build/firmware.hex: ./build/firmware.elf $(OBJCOPY) -O ihex $ $ $(SIZE) $ ./build: mkdir -p $ clean: rm -rf ./build .PHONY: all clean这段Makefile把汇编文件和C文件分开编译patsubst负责把源文件列表转成目标文件列表| ./build表示“order-only prerequisite”也就是构建前先确保build目录存在但build目录时间戳变化不会触发重编。这样写的好处是新增一个.c文件只需要加到SRCS变量里。5.3 编译时怎么查看实际生效的参数有时候你写了一大堆CFLAGS但不确认它们是否都被正确解析尤其是从网上抄来的Makefile里面可能包含了平台相关的变量。这时候别猜直接让编译器把最终参数打出来make V1或者手动执行arm-none-eabi-gcc -mcpucortex-m3 -mthumb -Os -v -c main.c -o /dev/null-v会打印GCC执行的详细过程包括内置的搜索路径、实际传给子进程的参数。如果发现某些选项被忽略比如-mfloat-abi和-mcpu冲突GCC会以最后出现或更具体的选项为准调整起来心里就有底了。另外配合-fverbose-asm可以生成带注释的汇编文件适合检查编译器对你代码的处理逻辑arm-none-eabi-gcc $(CFLAGS) -S -fverbose-asm main.c -o main.s打开main.s你能看到每条汇编指令对应的C源码和变量名对理解编译器行为极有帮助。6. 新手最常见的问题排查实录6.1 编译过了下载进去没反应这是最高频的问题之一。代码编译零错误零警告烧录完板上灯不闪、程序不跑。按优先级从高到低排查先查启动文件有没有链接进去。很多人编译时只加了main.c忘了加startup_stm32f103xb.s程序没有异常向量表芯片上电直接跑飞。用arm-none-eabi-nm firmware.elf看导出符号里有没有Reset_Handler和SystemInit。再查链接脚本里的Flash起始地址和芯片是否匹配。比如你是F103C8T6Flash 64KB但链接脚本写的是F103ZEFlash 512KB如果代码恰好在64KB之外烧录后发现程序只会跑一部分或者直接不启动。最后查--gc-sections是否把中断向量表给删了。链接脚本里一定要有KEEP(*(.isr_vector))这类强制保留语句。我看到过不少人照抄网上的链接脚本里面的KEEP语句被误删一切看起来正常但芯片复位后进入中断向量表本来就是空自然跑不起来。6.2 浮点数运算结果全乱这种情况十有八九是-mfloat-abi和-mfpu不匹配硬件或者整个工程里混用了不同float-abi编译的目标文件。如果你的芯片是Cortex-M4F比如STM32F407但编译时只写了-mcpucortex-m4 -mthumb没写-mfloat-abihard -mfpufpv4-sp-d16那么GCC默认按soft处理所有浮点运算都走软件模拟功能正常但极慢。如果恰好你又在一个用了硬件FPU的汇编或者库文件里执行了浮点操作两种模式切换会导致浮点寄存器状态错乱运算结果就是乱码。排查方法很直接打开map文件看$d标识符号段或者在编译命令里加-Wfloat-equal编译告警选项看是否有混合浮点ABI的警告输出。还有一个更快的方法arm-none-eabi-objdump -d firmware.elf | grep vldr如果代码里出现了vldr、vstr这类FPU指令说明确实用了硬件浮点如果全是__aeabi_fmul之类的函数调用说明走的是软件浮点。6.3 用到了printf程序就卡死这类问题的根源通常是printf的底层输出通道没有实现。ARM-GCC的printf会调用_writenewlib或_sys_write某些重定向实现来处理最终的字符输出在裸机环境下这些函数默认是空的或者直接返回错误所以程序跑起来看着像卡死在printf里。解决方法是自己重定向_write函数把字符逐个通过UART发出去。常见写法在gcc下是int _write(int fd, char *ptr, int len) { for (int i 0; i len; i) { while (!(USART1-ISR USART_FLAG_TXE)); USART1-TDR *ptr; } return len; }注意这里的函数名是下划线开头的_write不同工具链可能略有区别Keil/ARMCC下是fputc或__stdout这也是为什么你搜索printf重定向时会看到好几种不同写法。配套的还别忘了--specsnano.specs时加-u _printf_float才能输出浮点。6.4 链接时undefined reference疯狂的报错新手看这种报错最容易慌因为报错列表能刷屏一整页。但其实核心就一句话某个符号链接器找不到定义。最常见的原因是忘了把对应源文件加进编译列表。比如你用了HAL库的HAL_UART_Transmit但Makefile里的SRCS没包含stm32f1xx_hal_uart.c链接器就会报undefined reference。处理办法是把arm-none-eabi-nm拿来做符号搜索arm-none-eabi-nm build/*.o | grep HAL_UART_Transmit能看到这个符号在哪个目标文件里然后再补到Makefile的SRCS列表。这种方法比对着链接器报错一条条猜要快得多。另一类undefined reference和库有关比如用到sin、sqrt这些数学函数就需要加-lm链接数学库用到memcpy、memset这种-lc一般会覆盖。我之前遇到过_sbrk未定义的情况这是newlib的内存管理接口裸机下需要自己实现通常放在syscalls.c里。STM32CubeMX生成的工程会自动带一个syscalls.c如果你是从零搭建的工程就得自己补上。结尾ARM-GCC编译选项这块内容我第一次系统梳理的时候也觉得枯燥全是一堆看似冷冰冰的参数。但实际用下来每一个选项背后都对应一类真实的问题-mcpu写错了芯片跑不起来-mfloat-abi不匹配浮点算错--gc-sections没配好代码体积爆炸。反而是把这些选项在命令行里一行行走一遍之后再去点Keil的图形界面瞬间就明白了那些勾选框背后到底做着什么。根据我个人经验新手最容易犯的毛病是到处复制Makefile模板却不理解每一行参数的含义。建议你拿到一个新板子至少从命令行手工编译一次最小工程把编译、链接、objcopy三步都走一遍。这个过程看起来麻烦但只要走通一次后面不管换什么芯片、什么工具链对你来说都是换几个参数的事。最后再分享一个小技巧把常用编译命令存成一个build.sh脚本调试时经常要换优化等级、开关_printf_float脚本里用变量控制会比反复编辑Makefile快得多。编译选项这东西只有自己动手改过几次才知道网上那些“最佳实践”为什么这么写也才能在出问题的时候不慌。
STM32开发必知：ARM-GCC交叉编译链与关键编译选项详解
最近好几拨人问我同样一个问题STM32开发到底要不要自己装ARM-GCC交叉编译链有的人是被命令行劝退有的人觉得Keil用得好好的没必要折腾还有人在GitHub上拉了个开源项目发现全是Makefile直接懵了。先给个直接回答不装也能做STM32开发但只要你碰过Linux环境、CI自动编译、开源代码移植或者Visual Studio Code配插件这套玩法ARM-GCC迟早要装。而且说实话一旦你理解了它的编译选项在干什么再回头看Keil的魔术棒界面反而会觉得那些选项其实都见过只是被图形界面包装起来了。这篇文章不打算写得像man手册那样逐条翻译而是把实际开发中最常用、最关键、最容易出问题的编译选项拿出来拆开讲。读完你至少能看懂一份Makefile里那几行CFLAGS是什么含义能自己调参数控制代码体积和调试体验遇到“编译过了但跑不起来”的情况也知道从哪个选项开始排查。1. ARM-GCC到底是什么STM32开发真的离不开它吗1.1 从“交叉编译”这个概念说起交叉编译的意思很直白你的电脑是x86架构但STM32芯片是Cortex-M架构两种CPU的机器码完全不一样。编译器做的就是“在一台机器上生成另一种机器能跑的代码”这件事这就是“交叉”二字的本意。ARM-GCC就是专门为ARM架构定制的一套GCC工具链和你在Linux上用的gcc同宗同源只是目标平台换成了ARM。它里面包含几个核心组件arm-none-eabi-gccC/C编译器负责把源码变成汇编再变成机器码arm-none-eabi-as汇编器负责把汇编代码变成目标文件arm-none-eabi-ld链接器负责把多个目标文件组合成最终的ELF文件arm-none-eabi-objcopy格式转换工具把ELF转成hex或bin烧录文件arm-none-eabi-size查看各段体积的工具arm-none-eabi-gdb调试器其中none表示没有操作系统bare metaleabi表示嵌入式应用二进制接口。这套工具链下载解压就能用不需要安装配好环境变量就行。我自己用的版本是gcc-arm-none-eabi-10.3-2021.10后面所有命令行示例都基于这个版本。1.2 有Keil和STM32CubeIDE为什么还要自己装ARM-GCCKeil和STM32CubeIDE本质上都内置了自己的编译器Keil用的是ARMCC新版本叫AC6CubeIDE用的是集成好的GCC。你确实可以不单独装ARM-GCC就完成开发。但有几个场景绕不开它。第一个是CI自动化编译。产品代码往Git仓库一推服务器上跑脚本自动编译检查服务器不可能装Keil要授权、要图形界面而ARM-GCC免费、开源、纯命令行正是CI环境的标准选择。第二个是跨平台。团队里有人用Windows有人用macOS有人用LinuxKeil只能在Windows上用而ARM-GCC三个平台都有大家用同一套Makefile就能保证编译结果一致。第三个场景我现在碰得特别多——从开源项目移植代码。GitHub上有大量STM32的开源工程是纯Makefile或者CMake组织的不用ARM-GCC你根本编译不了。反过来讲如果你会看编译选项把一个Keil工程翻译成Makefile工程也就是一两个小时的事。1.3 怎么判断你的环境到底缺不缺这东西我给你一个最简单的判断方法在命令行输入arm-none-eabi-gcc --version如果提示找不到命令而你正好符合下面任意一条那你就需要装了你准备在Linux或macOS上开发STM32你想用VS Code cortex-debug插件做开发调试你需要跑GitHub上那些用Makefile管理的开源例程你的项目需要接入自动化编译流程你想彻底搞明白程序从源码到烧录文件中间发生了什么装好之后不用急着写代码先拿一个现成的工程STM32CubeMX生成的Makefile工程就行编译一遍再回头来看这篇文章的选项解释每个参数你都会有实感。2. 架构与指令集选项决定你的代码跑在什么模式上2.1 -mcpu与-march告诉编译器你的芯片是谁这是整个编译命令里最关键的一行。-mcpu指定具体的CPU型号-march指定架构版本。看一个编译命令就知道开发者用的是哪颗芯片就是靠这个参数。比如STM32F103C8T6是Cortex-M3内核常见的写法是arm-none-eabi-gcc -mcpucortex-m3 -mthumb -c main.c -o main.o如果是STM32F407VECortex-M4内核且带FPU就要写arm-none-eabi-gcc -mcpucortex-m4 -mthumb -mfloat-abihard -mfpufpv4-sp-d16 -c main.c -o main.o这里有个初学者很容易踩的坑-mcpu和-march不需要同时写满了。GCC官方的建议是-mcpu已经包含了具体内核的完整信息含架构版本、FPU等所以只要指定了-mcpu-march可以省略。反过来如果你用-march指定架构版本还要再配合-mtune去优化特定内核的指令调度。实际工程里99%的Makefile都只写-mcpu。那什么情况会用到-march做汇编级优化、对不同内核统一架构版本做兼容编译时才会用到。比如你要打一个同时兼容Cortex-M3和Cortex-M4的库但只使用ARMv7-M通用的指令就会把-mcpu换成-marcharmv7-m。2.2 -mthumb与-marmARM模式与Thumb模式的取舍这两个选项决定编译器生成的指令集是16位的Thumb指令还是32位的ARM指令。Cortex-M系列内核只支持Thumb指令所以STM32工程里的-mthumb基本是必写的。你可能会问那-marm存在还有什么意义它主要用在Cortex-A系列处理器上比如跑Linux的芯片这些核同时支持ARM和Thumb两种模式。当你在Cortex-A上做裸机开发时可以选择-marm获得更高的性能和更丰富的指令代价是代码体积变大选择-mthumb则代码更紧凑但性能略有损失。在Cortex-M上有个更隐蔽的问题中断函数和某些特殊函数需要__attribute__((naked))修饰成完全不带栈帧的形式这种函数如果用Thumb模式写汇编注意要用.thumb伪指令声明。我自己第一次写向量表的时候就因为这个原因启动文件里的中断向量编译完地址对不上Debug调试进不去排查了半天。这里建议直接经验启动文件startup_xxx.s、链接脚本ld文件这类汇编和链接层面的东西优先用芯片厂商生成的原始文件别自己手写尤其是别顺手改指令集模式。Cortex-M0/0没有-marm可选Cortex-M3及以上默认也是Thumb这块选项基本固定。2.3 -mfloat-abi与-mfpu浮点运算最常见的坑这两个选项在Cortex-M4F和Cortex-M7等带FPU浮点运算单元的芯片上特别重要也是让很多新手程序“编译过了但运行结果全乱”的元凶。-mfloat-abi有三个值soft、softfp、hard。soft完全不使用FPU用软件模拟浮点运算。任何Cortex-M芯片都支持但浮点运算极慢。softfp使用FPU硬件指令但函数调用时浮点参数仍然通过通用寄存器传递。兼容性好但调用效率有损失。hard使用FPU硬件指令且函数调用时浮点参数用FPU寄存器传递。效率最高但要求整个工程包括库、启动文件都用同一套float-abi编译。实际项目中STM32F4系列绝大多数都选hard配合-mfpufpv4-sp-d16。代价就是你在移植一些第三方库时如果对方库编译时用的softfp而你工程整体用hard链接的时候就会报“incompatible float ABI”之类的错误。解决办法一般是统一重新编译库或者把自己的工程切回softfp。-mfpu指定FPU的硬件特性STM32F4是单精度FPU对应fpv4-sp-d16部分STM32F7和H7支持双精度对应fpv5-d16。如果选错了编译能过但浮点指令会产生硬件异常HardFault程序直接死机而且不好查。一个经验之谈遇到浮点相关HardFault先查这个选项和芯片型号是否符合。2.4 一个典型Cortex-M的编译参数案例拿STM32F103Cortex-M3和STM32F407Cortex-M4F做个对比你就能直观感受到不同的选项组合芯片内核常用编译选项STM32F103C8T6Cortex-M3-mcpucortex-m3 -mthumbSTM32F407VET6Cortex-M4F-mcpucortex-m4 -mthumb -mfloat-abihard -mfpufpv4-sp-d16STM32H743VIT6Cortex-M7F-mcpucortex-m7 -mthumb -mfloat-abihard -mfpufpv5-d16这里要注意Cortex-M7的-mcpu如果写成cortex-m7GCC在10以上版本会默认启用双精度FPU指令所以如果你的H7芯片实际只用了单精度浮点反而要显式加一句-mfpufpv5-sp-d16避免生成芯片不支持的双精度指令。这类“默认值不代表最优值”的例子在GCC里非常多。3. 优化选项同样功能体积和速度差出一大截3.1 -O0到-Os怎么选优化等级是编译选项里影响最直观的一组直接决定编译出来的代码长什么样。ARM-GCC从高到低主要支持-O0、-O1、-O2、-O3、-Os含义分别是-O0不做任何优化编译速度最快但代码体积最大、执行速度最慢。调试体验最好变量随时能看到单步执行不会乱跳。-O1做基本优化代码体积和速度都有改善调试还勉强能用。-O2更激进的优化执行速度快但调试时经常发现变量被优化掉断点位置和源码对应不上了。-O3极限性能优化会做函数内联、循环展开等操作代码体积急剧膨胀但实际MCU项目中很少用。-Os优先优化代码体积在尽量小的情况下兼顾速度。对Flash紧张的MCU来说是最常用的选项。我之前调试一个电机控制程序用-O2编译结果示波器看PWM输出频率和理论值差了几乎一倍。一开始以为是定时器配置错了排查半小时无果。后来把优化等级降到-O0频率恢复正常才反应过来是编译器把某个紧耦合的循环里变量计算提前或合并了导致时序不对。从那以后凡是对时序敏感的代码我都会在源文件里加一句#pragma GCC optimize(O0)只对这一函数关闭优化整个工程该用-Os的继续用-Os。3.2 -ffunction-sections和-fdata-sections链接器裁剪的前提这两个选项本身不做优化它们的作用是给链接器“剪枝”创造条件。默认情况下GCC编译生成目标文件时同一个源文件里的所有函数和全局变量都会放在同一个section里。假设你写了10个函数只用到其中1个链接器也没办法只保留这1个因为整个section要么全要、要么全不要。芯片Flash本来就不大这种浪费特别可惜。加了-ffunction-sections之后GCC会把每个函数都放进独立的section加了-fdata-sections则让每个全局变量也独立成段。这样链接器就有能力逐个筛选用到的部分。但光有这两个还不够你还需要让链接器在链接阶段真正做删除动作这就是下面要说的-Wl,--gc-sections。3.3 -Wl,--gc-sections到底删了什么-Wl,是GCC往链接器传参数的固定写法--gc-sections就是告诉链接器“帮我删除未被引用的section”。这几个选项配合起来是嵌入式开发里控制代码体积最经典的一套组合拳arm-none-eabi-gcc -mcpucortex-m3 -mthumb -Os \ -ffunction-sections -fdata-sections \ -Wl,--gc-sections \ -T stm32f103c8t6_flash.ld \ main.o startup.o \ -o firmware.elf我实测过一组数据一个包含HAL库全量编译的STM32F103工程不开gc-sections时固件体积约92KB开了之后降到约28KB。差别就是这么大。原因很简单HAL库每个外设都有独立源文件但一个工程真正用到的外设可能就三五个其余几万行代码全被裁掉了。这里有个要提醒的点--gc-sections必须和-ffunction-sections、-fdata-sections配套使用否则链接器没有独立section可以裁剪选项等于白写。还有一种情况是你用了弱符号__attribute__((weak))中断回调函数有些编译器优化会把未被引用的中断函数裁掉导致中断响应不了。解决方法是把中断函数标记为__attribute__((used))或者在链接脚本里用KEEP()指令强制保留。我遇到过两次这种“编译正常、中断不进”的情况一次是忘了KEEP中断向量表一次是GPIO回调函数被当成了无引用代码剪掉。4. 链接、启动文件与标准库选项能不能跑起来的最后一环4.1 -T链接脚本内存布局说明书编译选项不只有-mcpu和-O2这类看起来跟性能相关的-T指定链接脚本是整个工程能否运行的底座。链接脚本后缀通常为.ld或.lds定义了芯片的Flash从哪里开始、RAM从哪里开始、各段数据放在什么位置。用STM32F103C8T6举例内部Flash从0x08000000开始共64KBRAM从0x20000000开始共20KB。链接脚本的核心就是把这些信息告诉链接器顺带告诉它向量表放哪、堆栈大小设多少、.bss段从什么地址开始清零。一个常见的错误是把另一颗芯片的链接脚本直接拿过来用。比如把F103的脚本用在F407上程序也能编译释放烧进去就死。因为F103 Flash只有64KB脚本里的Flash长度定义可能锁死了生成代码的上限RAM大小不对也会导致链接器把栈顶地址设到不存在的内存区域。排查方法很简单打开map文件看尾部内存使用情况或者直接用arm-none-eabi-size看各段分布。我自己习惯在工程里额外跑一条命令验证内存是否超限arm-none-eabi-size firmware.elf输出里text、data、bss三列分别对应代码只读数据、已初始化数据、未初始化数据把它们和芯片实际Flash/RAM一对比就能看出是否放得下。4.2 -nostartfiles和启动文件的关系-nostartfiles的意思是“链接时不要自动链接标准的启动文件”。标准启动文件是GCC自带的crt0.o等主要做进入main之前的运行时初始化。在裸机嵌入式里这些标准启动文件和芯片的启动流程对不上通常不需要。实际工程里Cortex-M芯片的启动流程是芯片上电 - 从向量表取栈顶地址和复位处理函数地址 - 执行复位函数 - 调用SystemInit配置时钟 - 跳转main。这个流程里启动文件是芯片厂商提供的startup_xxx.s和你是否加-nostartfiles没有直接关系。那什么时候会用到-nostartfiles当你自己用汇编或C实现了完整的启动流程不希望链接器再额外加入GCC的运行时初始化代码时就加上它。大多数由STM32CubeMX生成的Makefile工程不会显式加这个参数因为它默认的启动流程已经被startup文件覆盖了。如果你在链接时遇到crt0.o相关的符号冲突或者发现编译出来的固件里莫名多了一段执行代码可以考虑试试-nostartfiles。顺带一提与它配套的还有-nodefaultlibs不链接默认库和-nostdlib完全不链接标准库和启动文件。这三个参数一个比一个激进新手不推荐轻易尝试。踩过一次坑之后我的态度是启动流程能不动就不动芯片厂商给的例程怎么说就怎么配。4.3 --specsnano.specs和printf浮点支持问题这个选项在我解答的“编译了但串口打印小数全是0”问题里出现了无数次。ARM-GCC默认链接的是newlib标准C库但它比较复杂代码体积大。用--specsnano.specs可以切换到为嵌入式优化的精简版newlib-nano库体积能减小不少。代价是数学函数精度下降、某些POSIX特性缺失。newlib-nano里面最坑的一点是printf族函数的浮点格式化支持默认是关闭的。哪怕你用了%f格式符输出的也全是0或者乱码。解决办法是在链接选项里加上-u _printf_floatarm-none-eabi-gcc ... --specsnano.specs -u _printf_float ...-u _printf_float的意思是告诉链接器“强制引用这个符号”链接器就会把printf的浮点支持模块拉进来。代价是代码体积会增加约几千字节。单片机串口打印调试是刚需所以我给你的实用建议是Release版本不加_printf_float把浮点转成整数再打印比如打印12345代表12.345这样代码体积小。Debug版本加上_printf_float调完好去掉别让固件包里白背这块重量。4.4 一个查选项用的实用技巧ARM-GCC自带的文档离线不加搜索可能看不下去但我每次不确定某个选项的含义时最常用的不是网上搜而是直接让GCC自己解释。想知道某选项支持哪些取值用arm-none-eabi-gcc --helptarget想确认某个选项是否真的生效用arm-none-eabi-gcc -mcpucortex-m4 -mthumb -mfloat-abihard -mfpufpv4-sp-d16 -Q --helptarget | grep float-Q选项会打印最终生效的选项值比如你只写了-mfpufpv4-sp-d16它能告诉你实际生效的float-abi是hard还是softfp。这对排查“为什么我写了hard但浮点性能没提升”之类的问题特别有用。还有一个我每次都会检查的把预处理后的宏定义打印出来确认编译器确实定义了对应型号的宏arm-none-eabi-gcc -mcpucortex-m4 -mthumb -dM -E - /dev/null | grep ARM输出里能看到__ARM_ARCH_7EM__、__ARM_FP这类宏对比一下就知道CPU配置是否按预期生效。5. 直接能抄的编译实操从命令行到Makefile5.1 一个完整的STM32编译命令把前面这些选项组合起来一个工程的最小完整编译流程分三步编译、链接、转格式。第一步把几个源码文件分别编译成目标文件arm-none-eabi-gcc -mcpucortex-m3 -mthumb \ -Os -ffunction-sections -fdata-sections \ -I./inc -I./Drivers/CMSIS/Include \ -c ./src/main.c -o ./build/main.o注意-c表示只编译不链接-I指定头文件搜索路径。每个.c文件都执行一遍这条命令生成对应的.o文件。源文件多的时候用Makefile的自动规则更省事。第二步链接所有目标文件arm-none-eabi-gcc -mcpucortex-m3 -mthumb \ -Wl,--gc-sections -T stm32f103c8t6_flash.ld \ ./build/main.o ./build/stm32f1xx_hal_msp.o ./build/startup_stm32f103xb.o \ --specsnano.specs -Wl,--start-group -lc -lm -Wl,--end-group \ -o ./build/firmware.elf这里有几个点说明一下。-Wl,--start-group和-Wl,--end-group把后面的大括号内库文件包在里面作用是让链接器循环扫描这些库解决库之间的循环依赖。裸机工程里libc和libm的依赖关系有时会出现“谁引用谁”的环不加这个就可能报undefined reference。-lc是C标准库-lm是数学库。第三步转成烧录文件arm-none-eabi-objcopy -O ihex ./build/firmware.elf ./build/firmware.hex # 或者生成bin文件 arm-none-eabi-objcopy -O binary ./build/firmware.elf ./build/firmware.binhex是Intel格式ST-Link、J-Link、串口ISP都能直接用bin是纯二进制需要知道烧录基地址烧录器通常默认写0x08000000对STM32来说没问题。5.2 Makefile里怎么写实际项目里没人会把这三条命令在终端里手敲几十遍都写在Makefile里自动执行。我比较习惯的写法是定义一个变量保存公共编译参数再按规则编译CROSS_COMPILE arm-none-eabi- CC $(CROSS_COMPILE)gcc OBJCOPY $(CROSS_COMPILE)objcopy SIZE $(CROSS_COMPILE)size CPU -mcpucortex-m3 -mthumb OPT -Os CFLAGS $(CPU) $(OPT) -ffunction-sections -fdata-sections CFLAGS -I./inc -I./Drivers/CMSIS/Include LDFLAGS $(CPU) -Wl,--gc-sections -T stm32f103c8t6_flash.ld LDFLAGS --specsnano.specs -Wl,--start-group -lc -lm -Wl,--end-group SRCS main.c stm32f1xx_hal_msp.c startup_stm32f103xb.s OBJS $(patsubst %.c,./build/%.o,$(filter %.c,$(SRCS))) OBJS $(patsubst %.s,./build/%.o,$(filter %.s,$(SRCS))) all: ./build/firmware.hex ./build/firmware.elf: $(OBJS) $(CC) $(LDFLAGS) $^ -o $ ./build/%.o: %.c | ./build $(CC) $(CFLAGS) -c $ -o $ ./build/%.o: %.s | ./build $(CC) $(CFLAGS) -c $ -o $ ./build/firmware.hex: ./build/firmware.elf $(OBJCOPY) -O ihex $ $ $(SIZE) $ ./build: mkdir -p $ clean: rm -rf ./build .PHONY: all clean这段Makefile把汇编文件和C文件分开编译patsubst负责把源文件列表转成目标文件列表| ./build表示“order-only prerequisite”也就是构建前先确保build目录存在但build目录时间戳变化不会触发重编。这样写的好处是新增一个.c文件只需要加到SRCS变量里。5.3 编译时怎么查看实际生效的参数有时候你写了一大堆CFLAGS但不确认它们是否都被正确解析尤其是从网上抄来的Makefile里面可能包含了平台相关的变量。这时候别猜直接让编译器把最终参数打出来make V1或者手动执行arm-none-eabi-gcc -mcpucortex-m3 -mthumb -Os -v -c main.c -o /dev/null-v会打印GCC执行的详细过程包括内置的搜索路径、实际传给子进程的参数。如果发现某些选项被忽略比如-mfloat-abi和-mcpu冲突GCC会以最后出现或更具体的选项为准调整起来心里就有底了。另外配合-fverbose-asm可以生成带注释的汇编文件适合检查编译器对你代码的处理逻辑arm-none-eabi-gcc $(CFLAGS) -S -fverbose-asm main.c -o main.s打开main.s你能看到每条汇编指令对应的C源码和变量名对理解编译器行为极有帮助。6. 新手最常见的问题排查实录6.1 编译过了下载进去没反应这是最高频的问题之一。代码编译零错误零警告烧录完板上灯不闪、程序不跑。按优先级从高到低排查先查启动文件有没有链接进去。很多人编译时只加了main.c忘了加startup_stm32f103xb.s程序没有异常向量表芯片上电直接跑飞。用arm-none-eabi-nm firmware.elf看导出符号里有没有Reset_Handler和SystemInit。再查链接脚本里的Flash起始地址和芯片是否匹配。比如你是F103C8T6Flash 64KB但链接脚本写的是F103ZEFlash 512KB如果代码恰好在64KB之外烧录后发现程序只会跑一部分或者直接不启动。最后查--gc-sections是否把中断向量表给删了。链接脚本里一定要有KEEP(*(.isr_vector))这类强制保留语句。我看到过不少人照抄网上的链接脚本里面的KEEP语句被误删一切看起来正常但芯片复位后进入中断向量表本来就是空自然跑不起来。6.2 浮点数运算结果全乱这种情况十有八九是-mfloat-abi和-mfpu不匹配硬件或者整个工程里混用了不同float-abi编译的目标文件。如果你的芯片是Cortex-M4F比如STM32F407但编译时只写了-mcpucortex-m4 -mthumb没写-mfloat-abihard -mfpufpv4-sp-d16那么GCC默认按soft处理所有浮点运算都走软件模拟功能正常但极慢。如果恰好你又在一个用了硬件FPU的汇编或者库文件里执行了浮点操作两种模式切换会导致浮点寄存器状态错乱运算结果就是乱码。排查方法很直接打开map文件看$d标识符号段或者在编译命令里加-Wfloat-equal编译告警选项看是否有混合浮点ABI的警告输出。还有一个更快的方法arm-none-eabi-objdump -d firmware.elf | grep vldr如果代码里出现了vldr、vstr这类FPU指令说明确实用了硬件浮点如果全是__aeabi_fmul之类的函数调用说明走的是软件浮点。6.3 用到了printf程序就卡死这类问题的根源通常是printf的底层输出通道没有实现。ARM-GCC的printf会调用_writenewlib或_sys_write某些重定向实现来处理最终的字符输出在裸机环境下这些函数默认是空的或者直接返回错误所以程序跑起来看着像卡死在printf里。解决方法是自己重定向_write函数把字符逐个通过UART发出去。常见写法在gcc下是int _write(int fd, char *ptr, int len) { for (int i 0; i len; i) { while (!(USART1-ISR USART_FLAG_TXE)); USART1-TDR *ptr; } return len; }注意这里的函数名是下划线开头的_write不同工具链可能略有区别Keil/ARMCC下是fputc或__stdout这也是为什么你搜索printf重定向时会看到好几种不同写法。配套的还别忘了--specsnano.specs时加-u _printf_float才能输出浮点。6.4 链接时undefined reference疯狂的报错新手看这种报错最容易慌因为报错列表能刷屏一整页。但其实核心就一句话某个符号链接器找不到定义。最常见的原因是忘了把对应源文件加进编译列表。比如你用了HAL库的HAL_UART_Transmit但Makefile里的SRCS没包含stm32f1xx_hal_uart.c链接器就会报undefined reference。处理办法是把arm-none-eabi-nm拿来做符号搜索arm-none-eabi-nm build/*.o | grep HAL_UART_Transmit能看到这个符号在哪个目标文件里然后再补到Makefile的SRCS列表。这种方法比对着链接器报错一条条猜要快得多。另一类undefined reference和库有关比如用到sin、sqrt这些数学函数就需要加-lm链接数学库用到memcpy、memset这种-lc一般会覆盖。我之前遇到过_sbrk未定义的情况这是newlib的内存管理接口裸机下需要自己实现通常放在syscalls.c里。STM32CubeMX生成的工程会自动带一个syscalls.c如果你是从零搭建的工程就得自己补上。结尾ARM-GCC编译选项这块内容我第一次系统梳理的时候也觉得枯燥全是一堆看似冷冰冰的参数。但实际用下来每一个选项背后都对应一类真实的问题-mcpu写错了芯片跑不起来-mfloat-abi不匹配浮点算错--gc-sections没配好代码体积爆炸。反而是把这些选项在命令行里一行行走一遍之后再去点Keil的图形界面瞬间就明白了那些勾选框背后到底做着什么。根据我个人经验新手最容易犯的毛病是到处复制Makefile模板却不理解每一行参数的含义。建议你拿到一个新板子至少从命令行手工编译一次最小工程把编译、链接、objcopy三步都走一遍。这个过程看起来麻烦但只要走通一次后面不管换什么芯片、什么工具链对你来说都是换几个参数的事。最后再分享一个小技巧把常用编译命令存成一个build.sh脚本调试时经常要换优化等级、开关_printf_float脚本里用变量控制会比反复编辑Makefile快得多。编译选项这东西只有自己动手改过几次才知道网上那些“最佳实践”为什么这么写也才能在出问题的时候不慌。
