企业官网建设流程全解析

1. 四个软件到底在干嘛：先把工具链的账算清楚

很多人第一次接触STM32的C++开发，跟着教程一路Next装完软件，回头一看桌面多了四个图标，心里直发毛：我就点了个灯，至于吗？我当初也是这个状态，装完Keil、STM32CubeMX、VSCode、arm-none-eabi-gcc，盯着屏幕愣了半天，完全不知道谁负责干什么。后来踩了不少坑才明白，这四个东西根本不是重复建设，它们各自管一段流程，缺一个都跑不通。这一节我就把这笔账彻底算清楚，让你知道每个软件存在的理由。

1.1 先搞清楚一件事：写代码和跑代码是两码事

你写的C++代码，本质上就是一堆文本文件，CPU根本不认识。从文本到芯片里真正跑起来的二进制，中间要经过编译、汇编、链接三个大步骤，最后生成一个.elf或者.bin文件，再烧进STM32的Flash里。这个过程在PC上开发时，编译器（比如MSVC或者GCC）帮你全干了，你感知不到。但嵌入式开发不一样，你的电脑是x86架构，STM32是ARM Cortex-M架构，指令集完全不同，PC上的编译器生成的代码STM32根本执行不了。

所以你需要一个能生成ARM指令的编译器，这就是交叉编译的由来——在一种平台上编译出另一种平台能运行的代码。arm-none-eabi-gcc就是干这个的。名字拆开看：arm是目标架构，none表示没有操作系统（裸机），eabi是嵌入式应用二进制接口。这三个词把它的定位说得明明白白。

那Keil和STM32CubeMX又是干嘛的？Keil本质上是一个集成开发环境（IDE），它内部自带了一套ARM编译器（ARMCC或者ARMCLANG），同时还集成了编辑器、调试器、烧录工具。你可以把Keil理解成一个“全家桶”，从写代码到烧录一条龙。而STM32CubeMX是ST官方出的图形化配置工具，你点几下鼠标就能配好时钟树、引脚复用、外设参数，然后它自动生成初始化代码。VSCode则是代码编辑器，本身不具备编译能力，但通过插件可以调用arm-none-eabi-gcc来编译，配合OpenOCD或者ST-Link工具来烧录和调试。

1.2 四个软件的分工对照表

我把这四个软件的核心职责整理成一张表，你对照着看就清楚了：

看这张表你会发现，Keil和arm-none-eabi-gcc在功能上有重叠，它们都能编译ARM代码。这就是很多人困惑的根源：我到底该用哪个？答案取决于你选哪条路线。如果你用Keil做IDE，那它自带的编译器就够了，不需要额外装arm-none-eabi-gcc。如果你用VSCode做编辑器，那就需要arm-none-eabi-gcc来做实际编译，再配合Makefile或者CMake来组织构建流程。

注意：Keil自带的ARMCC编译器是收费的，社区版有代码大小限制。arm-none-eabi-gcc是GNU工具链，完全免费开源，没有代码大小限制。这也是很多人从Keil转向VSCode+GCC路线的原因之一。

1.3 为什么教程让你四个都装

你可能会问，既然有重叠，为什么很多教程让你四个全装？原因很简单：教程作者想让你先跑通，再理解。Keil+STM32CubeMX的组合是最省事的，CubeMX生成Keil工程，Keil直接打开编译烧录，不需要你手写Makefile，不需要配置编译器路径，对新手最友好。但这条路线的缺点是：你被Keil绑死了，换到Linux或者Mac上就没法用，而且Keil的编辑器体验确实一般。

VSCode+arm-none-eabi-gcc的路线更灵活，跨平台，编辑器体验好，但配置门槛高，你需要自己写Makefile、配置调试器、设置头文件路径。很多教程让你先装Keil跑通，再装VSCode+GCC体验另一条路线，目的是让你对比之后自己选。我个人的建议是：新手先用Keil+CubeMX跑通一个点灯程序，建立信心，然后再折腾VSCode+GCC路线。不要一上来就搞最复杂的配置，容易劝退。

2. 交叉编译工具链拆解：arm-none-eabi-gcc到底怎么工作

上一节把四个软件的定位说清楚了，这一节我重点拆解arm-none-eabi-gcc这个交叉编译工具链。很多人装了它之后，只知道在命令行敲arm-none-eabi-gcc能输出版本号，但完全不知道它内部包含哪些工具，每个工具干什么用。这一节我把工具链拆开，逐个讲清楚。

2.1 工具链里不只有gcc一个命令

你装完arm-none-eabi-gcc之后，去安装目录的bin文件夹下看一眼，会发现里面有一堆可执行文件，名字都带arm-none-eabi-前缀。这些不是重复的，每个都有明确分工：

• arm-none-eabi-gcc：C编译器，把.c文件编译成汇编或者目标文件
• arm-none-eabi-g++：C++编译器，把.cpp文件编译成汇编或者目标文件
• arm-none-eabi-as：汇编器，把汇编文件.s编译成目标文件.o
• arm-none-eabi-ld：链接器，把多个.o文件链接成最终的.elf文件
• arm-none-eabi-objcopy：格式转换工具，把.elf转成.bin或者.hex
• arm-none-eabi-objdump：反汇编工具，把二进制反汇编成汇编代码，调试时很有用
• arm-none-eabi-size：查看各段（text、data、bss）的大小，评估Flash和RAM占用
• arm-none-eabi-gdb：调试器，配合OpenOCD或者ST-Link GDB Server做在线调试

你平时敲的arm-none-eabi-gcc命令，其实是一个驱动程序，它会根据文件后缀自动调用对应的编译器、汇编器、链接器。比如你给它一个.cpp文件，它会自动调用arm-none-eabi-g++来编译。你给它.o文件，它会调用链接器。所以严格来说，gcc只是入口，背后是一整套工具在协作。

2.2 从源码到bin文件的完整流程

我拿一个最简单的C++文件举例，让你看清楚每一步发生了什么。假设你有一个main.cpp，内容就是点灯：

#include <cstdint> // STM32F103的GPIOB端口地址（简化写法，实际用寄存器定义头文件） volatile uint32_t* const RCC_APB2ENR = reinterpret_cast<uint32_t*>(0x40021018); volatile uint32_t* const GPIOB_CRL = reinterpret_cast<uint32_t*>(0x40010C00); volatile uint32_t* const GPIOB_ODR = reinterpret_cast<uint32_t*>(0x40010C0C); int main() { // 使能GPIOB时钟 *RCC_APB2ENR |= (1 << 3); // 配置PB0为推挽输出，50MHz *GPIOB_CRL &= ~(0xF << 0); *GPIOB_CRL |= (0x3 << 0); while (true) { *GPIOB_ODR ^= (1 << 0); // 翻转PB0 for (volatile int i = 0; i < 1000000; ++i); // 简单延时 } }

编译流程分四步：

第一步：预处理。arm-none-eabi-g++ -E main.cpp -o main.i，把#include展开，宏替换，去掉注释。这一步生成的文件还是文本，但已经没有任何预处理指令了。

第二步：编译。arm-none-eabi-g++ -S main.i -o main.s，把预处理后的C++代码翻译成ARM汇编。这一步是真正的“编译”，也是最复杂的一步，涉及语法分析、优化、寄存器分配。

第三步：汇编。arm-none-eabi-as main.s -o main.o，把汇编代码翻译成机器码，生成目标文件。目标文件里包含机器指令、符号表、重定位信息，但地址还没最终确定。

第四步：链接。arm-none-eabi-ld main.o -T stm32f103.ld -o main.elf，把所有目标文件、库文件链接在一起，按照链接脚本（.ld文件）指定的内存布局分配地址，生成最终的.elf文件。链接脚本里定义了Flash起始地址、RAM起始地址、各段（.text、.data、.bss）放在哪里。

最后用arm-none-eabi-objcopy -O binary main.elf main.bin生成纯二进制文件，烧进芯片。

提示：实际项目中不会手动敲这些命令，而是用Makefile或者CMake把这些步骤组织起来。但你必须知道每一步在干什么，否则出了问题根本不知道怎么排查。

2.3 交叉编译和本地编译的本质区别

你在PC上写C++程序，用g++ main.cpp -o main就能编译出可执行文件，直接运行。交叉编译多了一个-target的概念，编译器需要知道目标平台的架构、ABI、指令集。arm-none-eabi-gcc默认就是针对ARM Cortex-M系列的，但具体是Cortex-M3还是M4，需要你在编译选项里指定。

比如-mcpu=cortex-m3 -mthumb表示目标CPU是Cortex-M3，使用Thumb指令集。-mfloat-abi=soft表示浮点运算用软件模拟，-mfloat-abi=hard表示用硬件浮点单元（只有Cortex-M4F及以上才支持）。这些选项直接影响生成的代码能不能在目标芯片上跑。

还有一个关键区别：链接脚本。PC上的程序有操作系统帮你加载，你不需要关心代码放在哪个地址。但STM32是裸机，上电后从Flash的0x08000000地址开始执行，中断向量表必须放在最前面。链接脚本就是告诉链接器：把向量表放在0x08000000，把代码放在它后面，把变量放在RAM的0x20000000起始地址。这些地址因芯片型号而异，写错了程序直接跑飞。

3. 实操路线：从零搭一套能跑的C++工程

前面两节把原理讲透了，这一节我带你走一遍完整的实操流程。我会给出两条路线：一条是Keil+CubeMX的快速路线，一条是VSCode+GCC的灵活路线。你可以根据自己的需求选一条，或者两条都走一遍对比。

3.1 路线一：Keil + CubeMX，半小时点灯

这条路线适合新手，步骤少，坑也少。

第一步：装STM32CubeMX。去ST官网下载，装完之后打开，新建工程，选择你的芯片型号（比如STM32F103C8T6）。然后配置时钟：在RCC里把HSE设为Crystal/Ceramic Resonator，在Clock Configuration里把系统时钟拉到72MHz。接着配置GPIO：找到PC13（大多数最小系统板的LED接在PC13），设为GPIO_Output。最后在Project Manager里选Toolchain为MDK-ARM，生成代码。

第二步：装Keil MDK。去Keil官网下载MDK-ARM，装完之后需要安装对应的Device Family Pack（DFP），也就是STM32的芯片包。这个包里有启动文件、外设寄存器定义、Flash烧录算法。没有它Keil不认识你的芯片。

第三步：打开工程编译。CubeMX生成的工程直接用Keil打开，点Build，应该零错误零警告。然后点Download，程序就烧进去了。如果LED开始闪，恭喜你，环境搭好了。

第四步：改成C++。CubeMX默认生成的是C代码，main.c文件。你想用C++，需要做几件事：把main.c改名为main.cpp，在Keil的工程设置里把C++选项打开，确保启动文件里的SystemInit和中断向量表用extern "C"包裹。CubeMX生成的stm32f1xx_it.c等文件如果也要用C++编译，同样需要处理名称修饰问题。

注意：C++的名称修饰（name mangling）会导致链接错误。C语言编译出来的函数名就是函数名本身，C++会加上参数类型信息。所以C和C++混合编程时，C函数的声明必须放在extern "C" { }里面，否则链接器找不到符号。

3.2 路线二：VSCode + arm-none-eabi-gcc，灵活但门槛高

这条路线适合想跨平台、想深入理解构建流程的人。

第一步：装arm-none-eabi-gcc。去ARM官网或者xPack项目下载对应你操作系统的版本。Windows下建议下载.zip包，解压后把bin目录加到系统PATH环境变量里。验证方法：打开终端，敲arm-none-eabi-gcc --version，能输出版本号就说明装好了。

第二步：装VSCode和插件。VSCode本身只是个编辑器，需要装几个插件：C/C++（微软官方，提供代码补全和跳转）、Cortex-Debug（提供调试支持）、Makefile Tools（可选，方便管理构建）。装完插件后，在工程目录下创建.vscode文件夹，里面放c_cpp_properties.json配置头文件路径，放launch.json配置调试参数。

第三步：写Makefile。这是最关键的一步。你需要定义编译器路径、编译选项、源文件列表、头文件路径、链接脚本路径、输出文件名。我给出一个最小可用的Makefile模板：

# 工具链前缀 PREFIX = arm-none-eabi- CC = $(PREFIX)gcc CXX = $(PREFIX)g++ AS = $(PREFIX)as LD = $(PREFIX)ld OBJCOPY = $(PREFIX)objcopy SIZE = $(PREFIX)size # 目标芯片参数 CPU = -mcpu=cortex-m3 FPU = FLOAT-ABI = -mfloat-abi=soft MCU = $(CPU) -mthumb $(FPU) $(FLOAT-ABI) # 源文件 C_SOURCES = \ src/main.c \ src/stm32f1xx_it.c \ src/system_stm32f1xx.c CXX_SOURCES = \ src/main.cpp ASM_SOURCES = \ startup_stm32f103xb.s # 头文件路径 C_INCLUDES = \ -Iinc \ -IDrivers/STM32F1xx_HAL_Driver/Inc \ -IDrivers/CMSIS/Device/ST/STM32F1xx/Include \ -IDrivers/CMSIS/Include # 编译选项 CFLAGS = $(MCU) $(C_INCLUDES) -Og -Wall -fdata-sections -ffunction-sections CXXFLAGS = $(CFLAGS) -fno-exceptions -fno-rtti LDFLAGS = $(MCU) -TSTM32F103C8Tx_FLASH.ld -Wl,--gc-sections -specs=nano.specs -specs=nosys.specs # 目标文件 OBJECTS = $(C_SOURCES:.c=.o) $(CXX_SOURCES:.cpp=.o) $(ASM_SOURCES:.s=.o) # 最终目标 all: firmware.elf firmware.bin firmware.elf: $(OBJECTS) $(CXX) $(OBJECTS) $(LDFLAGS) -o $@ $(SIZE) $@ firmware.bin: firmware.elf $(OBJCOPY) -O binary $< $@ %.o: %.c $(CC) -c $(CFLAGS) $< -o $@ %.o: %.cpp $(CXX) -c $(CXXFLAGS) $< -o $@ %.o: %.s $(AS) -c $(MCU) $< -o $@ clean: rm -f $(OBJECTS) firmware.elf firmware.bin

这个Makefile里几个关键点解释一下：-Og是调试友好的优化级别，比-O0生成的代码小，又比-O2好调试。-fdata-sections -ffunction-sections配合-Wl,--gc-sections可以把没用的代码段裁掉，减小固件体积。-specs=nano.specs使用精简版C库，-specs=nosys.specs去掉系统调用相关的桩函数，裸机开发必须加。

第四步：配置调试。你需要一个ST-Link调试器，装好驱动后，在VSCode的launch.json里配置：

{ "version": "0.2.0", "configurations": [ { "name": "STM32 Debug", "type": "cortex-debug", "request": "launch", "servertype": "stlink", "device": "STM32F103C8", "interface": "swd", "executable": "./firmware.elf", "svdFile": "./STM32F103.svd", "runToMain": true } ] }

svdFile是芯片的外设寄存器描述文件，有了它你可以在调试时直接查看外设寄存器的值，不用手动算地址。这个文件在Keil的芯片包里或者ST官网都能找到。

3.3 两条路线的对比与选择建议

我的建议是：如果你只是做课程设计或者快速验证一个想法，用Keil+CubeMX就够了，别折腾。如果你打算长期做嵌入式开发，或者项目需要跨平台协作，那VSCode+GCC路线值得投入时间。两条路线不冲突，你可以先用Keil跑通，再慢慢迁移到VSCode。

4. 常见问题与排查技巧实录

环境搭建过程中遇到的问题，90%都是配置问题，不是代码问题。这一节我把自己踩过的坑和帮别人排查过的典型问题整理出来，你遇到类似情况可以直接对照。

4.1 编译报错：undefined reference toxxx

这是最常见的链接错误，意思是链接器找不到某个函数的定义。原因通常有三种：

第一种：C和C++混合编程时没加extern "C"。比如你在C++文件里调用了一个C文件里定义的函数，C++编译器会把函数名修饰成_Z3foov这种形式，而C文件里定义的是foo，链接器自然找不到。解决方法是在C++文件里声明这个函数时加上extern "C"：

extern "C" { void foo(void); }

或者在头文件里用宏判断：

#ifdef __cplusplus extern "C" { #endif void foo(void); #ifdef __cplusplus } #endif

第二种：源文件没加到编译列表里。Makefile里的C_SOURCES或者CXX_SOURCES漏了某个文件，或者Keil工程里没把文件添加到Group里。检查一下报错的函数在哪个文件里定义的，确认那个文件参与了编译。

第三种：库文件没链接。比如你用了sin()函数，需要链接数学库，在链接选项里加-lm。用了printf()，需要链接标准库，加-lc。裸机环境下还需要加-specs=nosys.specs来提供系统调用的桩函数。

4.2 程序烧进去不跑，或者跑飞

这个问题比编译错误更难排查，因为编译链接都通过了，但运行行为不对。常见原因：

启动文件选错了。不同型号的STM32启动文件不同，比如startup_stm32f103xb.s对应STM32F103中等容量产品，startup_stm32f103xe.s对应大容量产品。选错了会导致中断向量表偏移不对，程序跑飞。

链接脚本里的Flash和RAM地址写错了。STM32F103C8T6的Flash起始地址是0x08000000，大小64KB；RAM起始地址是0x20000000，大小20KB。如果你用的是其他型号，这些值不一样。链接脚本写错了，链接器会把代码分配到不存在的地址，烧录后直接HardFault。

时钟配置不对。CubeMX生成的SystemInit函数会根据你的时钟树配置设置PLL和分频器。如果你手动改了时钟配置但没更新SystemInit，系统时钟可能不是你以为的频率，导致延时函数不准、串口波特率错误。

中断优先级分组没设置。Cortex-M3/M4的中断优先级分组默认是0，所有中断都是抢占优先级，没有子优先级。如果你的程序依赖特定的优先级分组，需要在main函数开头调用NVIC_SetPriorityGrouping()设置。

实操心得：遇到程序跑飞，第一步先在main函数开头加一个死循环点灯，确认程序至少能跑到main。如果连这个都不行，问题一定在启动文件或者链接脚本。如果main能跑到，再逐步往后加代码，定位到出问题的那一行。

4.3 调试器连不上芯片

ST-Link连不上STM32，常见原因和解决方法：

还有一个容易被忽略的问题：STM32的JTAG引脚被禁用。如果你在代码里调用了GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGDisable, ENABLE)，SWD还能用，但JTAG被禁用了。如果你调用了GPIO_Remap_SWJ_Disable，SWD和JTAG都被禁用，调试器就彻底连不上了。这时候需要把BOOT0拉高，让芯片从系统存储器启动，再用调试器连接擦除Flash。

4.4 C++特性在嵌入式环境下的坑

用C++写STM32，有几个特性需要特别注意：

异常处理。C++的try-catch会生成大量额外代码，增加固件体积。裸机环境下通常用-fno-exceptions禁用异常。如果你确实需要错误处理，用返回值或者错误码代替。

RTTI。运行时类型识别（dynamic_cast、typeid）同样会增加代码体积，用-fno-rtti禁用。

动态内存分配。new和delete在嵌入式环境下要慎用，因为堆空间有限，频繁分配释放会产生碎片。建议用静态分配或者内存池。

虚函数。虚函数会生成虚函数表，增加RAM和Flash占用。如果只是用C++的封装特性，不涉及多态，可以不用虚函数。如果确实需要多态，考虑用模板或者编译期多态代替。

标准库。<iostream>、<string>、<vector>这些标准库组件在嵌入式环境下要么不可用，要么占用大量资源。建议用<cstdint>、<cstring>这些轻量级头文件，容器用ETL（Embedded Template Library）或者自己实现。

注意：C++的全局对象构造函数会在main函数之前执行，但此时系统时钟可能还没配置好，外设也没初始化。如果你的全局对象构造函数里调用了HAL库函数，可能会失败。解决方法是用__attribute__((init_priority))控制构造顺序，或者干脆不用全局对象，在main里手动初始化。

5. 工具链选型的深层逻辑与长期维护建议

聊完实操和排查，我想再往深一层聊聊工具链选型背后的逻辑。很多人选工具是“教程用什么我就用什么”，但如果你打算长期做嵌入式开发，或者项目要维护好几年，选型就不能只看眼前。

5.1 为什么GNU工具链是嵌入式领域的通用语言

arm-none-eabi-gcc属于GNU工具链家族，这个家族在嵌入式领域的地位几乎是统治级的。原因有几个：开源免费，没有License费用，也没有代码大小限制；跨平台，Windows、Linux、Mac都能跑，团队协作时不会因为操作系统不同而卡住；生态完善，CMake、Make、Ninja这些构建工具都原生支持GCC，CI/CD流水线里集成很方便；文档丰富，遇到问题网上能搜到大量资料。

相比之下，Keil的ARMCC编译器虽然优化做得好，但它是闭源的，只在Windows上跑，而且社区版有32KB代码限制。IAR的编译器优化也很强，但价格不菲。对于个人开发者和小团队来说，GNU工具链是性价比最高的选择。

5.2 构建系统怎么选：Makefile还是CMake

用GCC工具链，构建系统有两个主流选择：Makefile和CMake。Makefile直接、轻量，适合小型项目，但手写Makefile容易出错，尤其是源文件多了之后，依赖关系管理很麻烦。CMake是更高层的抽象，你描述“要编译哪些源文件、生成什么目标”，CMake自动生成Makefile或者Ninja文件。跨平台项目强烈建议用CMake。

STM32的CMake工程可以这样组织：

cmake_minimum_required(VERSION 3.20) project(stm32_cpp_demo CXX C ASM) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) # 工具链设置 set(CMAKE_C_COMPILER arm-none-eabi-gcc) set(CMAKE_CXX_COMPILER arm-none-eabi-g++) set(CMAKE_ASM_COMPILER arm-none-eabi-gcc) # 编译选项 add_compile_options( -mcpu=cortex-m3 -mthumb -Og -Wall -fdata-sections -ffunction-sections -fno-exceptions -fno-rtti ) # 链接选项 add_link_options( -mcpu=cortex-m3 -mthumb -T${CMAKE_SOURCE_DIR}/STM32F103C8Tx_FLASH.ld -Wl,--gc-sections -specs=nano.specs -specs=nosys.specs ) # 头文件路径 include_directories( inc Drivers/STM32F1xx_HAL_Driver/Inc Drivers/CMSIS/Device/ST/STM32F1xx/Include Drivers/CMSIS/Include ) # 源文件 file(GLOB_RECURSE SOURCES src/*.c src/*.cpp startup/*.s ) add_executable(firmware.elf ${SOURCES}) # 生成bin文件 add_custom_command(TARGET firmware.elf POST_BUILD COMMAND arm-none-eabi-objcopy -O binary firmware.elf firmware.bin COMMENT "Generating firmware.bin" )

CMake的好处是你不用手动维护目标文件列表，file(GLOB_RECURSE)会自动扫描源文件。但要注意，GLOB不会自动检测新增文件，每次加了新文件需要重新运行CMake配置。

5.3 版本管理与团队协作的注意事项

嵌入式项目的版本管理有几个特殊点：工具链版本要锁定。arm-none-eabi-gcc不同版本生成的代码可能不一样，团队里每个人用的版本不同，会导致构建结果不一致。建议在项目根目录放一个toolchain-version.txt，写明使用的GCC版本，或者用Docker容器统一环境。

链接脚本和启动文件要纳入版本管理。这两个文件直接决定程序的内存布局，改错了程序就跑不起来。每次修改都要写清楚原因，提交信息里说明改了什么、为什么改。

CubeMX生成的代码要标记。CubeMX会在生成的代码里加注释/* USER CODE BEGIN */和/* USER CODE END */，你写的代码要放在这两个标记之间，这样重新生成代码时不会被覆盖。如果你在标记外面改了代码，下次CubeMX重新生成就丢了。

固件版本号要写进二进制。在链接脚本里定义一个专门的段存放版本号，编译时通过-D宏传入，这样烧录后可以通过调试器或者串口读取固件版本，方便追踪问题。

5.4 从点灯到项目的扩展路径

环境搭好之后，下一步就是做实际项目。我建议的扩展路径是：点灯 → 串口打印 → 定时器中断 → PWM输出 → ADC采集 → SPI/I2C外设 → RTOS多任务 → USB设备。每一步都在前一步的基础上增加一个新概念，循序渐进。

串口打印是最重要的调试手段。有了串口输出，你可以在代码里打印变量值、函数执行路径、错误信息，比单步调试效率高得多。STM32的USART配置用CubeMX点几下就好，关键是重定向printf到串口。在GCC环境下，需要实现_write函数：

extern "C" int _write(int file, char* ptr, int len) { HAL_UART_Transmit(&huart1, (uint8_t*)ptr, len, HAL_MAX_DELAY); return len; }

这样printf的输出就会通过串口发出去。注意-specs=nosys.specs会提供_write的空实现，你自己定义的会覆盖它。

USB设备开发是另一个常见的需求。STM32F103自带USB外设，可以做成虚拟串口（CDC）、键盘（HID）、大容量存储（MSC）等设备。CubeMX里有USB中间件配置，选好设备类型后自动生成代码。但USB协议栈比较复杂，建议先用CubeMX生成一个CDC虚拟串口例程，跑通之后再改。

实操心得：从点灯到串口打印这一步，很多人会卡在printf重定向上。如果你用的是Keil的MicroLIB，_write的实现方式不一样，需要查一下具体用法。GCC环境下按上面的写法就行。另外，串口波特率要和终端软件一致，常见的是115200，数据位8，停止位1，无校验。

6. 我个人的工具链使用体会

写了这么多，最后分享几点我自己的真实体会，不是教程里会写的，但我觉得比教程更有用。

第一，不要追求“最优工具链”，先跑通再说。我见过太多人花一周时间纠结用Keil还是VSCode，结果一行代码没写。工具是拿来用的，不是拿来比的。你先用最顺手的方式跑通一个点灯，有了正反馈，后面才有动力深入。

第二，命令行能力是嵌入式的分水岭。如果你只会点IDE的按钮，遇到构建问题就只能干瞪眼。花点时间学一下Makefile的基本语法、GCC的常用选项、链接脚本的结构，这些知识在换平台、换芯片的时候都能复用。我当初从Keil转到GCC，前两周确实痛苦，但过了那个坎之后，效率反而更高了。

第三，调试器比printf更重要，但printf更常用。ST-Link配合Cortex-Debug可以单步、断点、看变量、看寄存器，功能很强大。但实际开发中，很多问题是时序相关的，单步调试会改变时序，反而复现不了。这时候串口打印就是最可靠的手段。两者都要会，看场景选。

第四，工具链版本升级要谨慎。GCC从10升到12，编译选项可能有变化，生成的代码大小也可能变。如果你的项目已经稳定运行，不要轻易升级工具链。如果非要升，先在分支上验证，确认没问题再合并。

第五，把环境搭建过程记录下来。你第一次装环境时踩的坑，过半年换电脑时还会再踩一遍。我当时用Notion建了一个页面，记录每个软件的版本号、下载链接、安装步骤、遇到的问题和解决方法。后来帮别人搭环境，直接把这个页面发过去，省了大量重复沟通。

这个系列后续我还会继续写，下一节打算聊STM32的启动流程和链接脚本的细节，把“程序从Flash到RAM再到main函数”这条路彻底走通。如果你在环境搭建过程中遇到了什么奇怪的问题，欢迎一起交流，很多坑我一个人踩不完，大家一起踩才踩得全。