1. 为什么放弃Keil，折腾VSCode+JLink+GCC这套组合
先说说我自己为什么折腾这套环境。这几年做GD32相关项目，最开始也是老老实实用Keil，毕竟官方资料多、教程铺天盖地。但用久了有几个痛点越来越难忍：一是Keil的编辑体验摆在那，代码跳转、智能提示和VSCode差了不止一个量级；二是工程越做越大，Keil那套工程文件在多人协作、版本管理的时候非常痛苦，合并冲突能把人逼疯；三是Keil的编译速度在项目大了以后明显乏力，还得时不时处理License的问题。后来接触了不少做开源项目的朋友，发现大家都在用VSCode+GCC这套开源工具链，我花了一个周末把环境搭起来，跑通了一个带FreeRTOS的通讯项目，之后就把主力开发彻底从Keil迁了过来。
这套组合解决的核心问题，说穿了就三个：工程文件可文本化、编译工具链可脚本化、调试体验可定制化。工程文件是普通的CMakeLists或Makefile，往Git一扔，不管谁拉下来都是同一套构建逻辑；编译用的是ARM官方GCC工具链，跨平台一致，Linux上同样能编；调试直接走JLink的GDB Server，VSCode的Cortex-Debug插件做前端，断点、变量监视、寄存器查看一个不少。
这项技能对谁有用呢？如果你手里有不止一个厂家的ARM Cortex-M项目，比如同时维护GD32、STM32、AT32这些片子，那这套环境的迁移成本几乎为零，换芯片只是换启动文件和链接脚本的事。如果你是做Linux下嵌入式开发、或者习惯用Git做版本管理的工程师，那这套环境可以说是标配。哪怕你是刚入门、之前只在Keil里点过灯的初学者，跟着这篇文章一步步走，也能把环境完整跑起来。
需要提前说明的是，我这里以GD32F103系列为例，型号不同（GD32F303、GD32F407、GD32E230等）在启动文件、链接脚本上会有差异，但整个环境的搭建思路完全一致。本文基于Windows系统演示，Linux下的差异只在个别命令上，我会顺带标注。
2. 环境准备：四个核心工具的下载、安装与验证
搭建这套环境，本质上就是凑齐四样东西：VSCode编辑器、ARM GCC交叉编译链、JLink驱动、GD32固件库。每一步都有一些容易踩的细节，我按实际操作的顺序拆开讲。
2.1 VSCode：编辑器本体
VSCode去官网下载User Installer版本就可以，安装时建议勾选“添加到PATH”和“在Code中打开”这两个选项，后面在命令行里敲code就能直接启动编辑器。装完之后先装四个插件，我按优先级排一下：
- C/C++（Microsoft官方）：提供代码跳转、智能提示、语法高亮，这是基础中的基础。
- Cortex-Debug（基于实体调试器的ARM调试插件）：JLink调试全靠它，后面配置launch.json会细说。
- Arm Assembly：汇编语法高亮，看启动文件、反汇编的时候用得着。
- LinkerScript：链接脚本的语法高亮，改
.ld文件时不至于全靠肉眼硬看。
2.2 ARM GCC工具链：编译器的选择和升级坑
这步是初学者最容易卡住的地方。很多人直接在Windows上敲apt install gcc，那是给本机用的；我们交叉编译ARM芯片，需要的是arm-none-eabi-前缀的工具链，千万别搞混。下载地址选ARM官方的GNU Arm Embedded Toolchain，下载Windows版本的-win32.exe安装包，或者选择xpack版本的免安装压缩包，我建议用xpack的版本，因为它是绿色解压、不污染系统注册表，换版本也方便。
装完以后有个高频问题，就是命令行里执行arm-none-eabi-gcc -v提示不是内部命令。原因几乎都是PATH没配好。装的是安装程序版本，装的时候要勾选“Add path to environment variable”；装的是解压版，需要手动把解压目录下的bin文件夹路径加到系统环境变量PATH里。验证方法就一条命令：
arm-none-eabi-gcc -v输出里能看到gcc version 10.3.1这类信息，说明工具链生效。这里多说一句，网上有人问“gcc升级后为啥还是旧版本”，十有八九是PATH里同时存在多个GCC，系统按顺序先找到了旧的那个。检查方法是在命令行里执行where arm-none-eabi-gcc，看看实际调用的是哪个路径下的可执行文件。
2.3 JLink驱动：版本比想象中更重要
JLink驱动从SEGGER官网下载，下载页面会要求填一个简单信息，随便填就能下。安装时注意两点：一是安装过程中提示安装USB驱动时一定要允许，否则后面连不上仿真器；二是装完以后建议把安装目录下的JLinkGDBServerCL.exe和JLink.exe确认能找到，调试时要用。
有个非常实用的经验：SEGGER驱动并不是越新越好。有些GD32芯片的调试接口对新版本驱动的时序适配有细微差异，我遇到过JLink驱动从某个版本升级后，连GD32F103直接报Could not connect to target的情况，退回上一版就正常。所以建议安装时保留你验证过能正常连接的版本，别盲目追新。后面调试部分我会细讲怎么用命令行验证仿真器是否工作。
2.4 GD32固件库：从哪里获取标准外设库
GD32的固件库在GD官网可以下载，也可以从GigaDevice的GitHub仓库拉取。这里有个关键知识点：GD32F10x的标准外设库，和STM32的StdPeriph库在结构上高度相似但不能直接替换使用。原因很简单，GD32和STM32虽然引脚兼容，但内部寄存器、时钟树、Flash控制器设计不同，尤其是GD32的主频可以跑到108MHz（STM32F103是72MHz），Flash等待周期和时钟配置代码完全不一样。
拿到固件库后，我建议不要动库文件，把它当成只读依赖放在工程里。后面讲工程结构时，你会看到我对外设库的处理方式。
3. 工程骨架：读懂启动文件、链接脚本和Makefile的关系
环境装好只是第一步，真正决定项目能不能编译过的是工程结构设计。VSCode+GCC的开发模式下，工程的“骨骼”由三部分构成：启动文件（startup）、链接脚本（.ld）、构建脚本（Makefile或CMake）。搞清楚这三者的协作关系，后面换芯片、加组件都会游刃有余。
3.1 工程目录设计
我习惯的工程目录结构是这样的：
gd32-project/ ├── core/ │ ├── startup_gd32f10x_hd.s │ ├── system_gd32f10x.c/.h │ └── gd32f10x.h ├── libraries/ │ ├── CMSIS/ │ └── peripherals/ # 标准外设库源码 ├── user/ │ ├── main.c │ ├── gd32f10x_it.c/.h # 中断处理 │ └── board_init.c/.h # 板级初始化 ├── ld/ │ └── gd32f10x_flash.ld ├── Makefile └── .vscode/ ├── c_cpp_properties.json ├── tasks.json └── launch.jsoncore放芯片启动相关的核心文件，libraries放固件库，user放自己的业务代码，ld放链接脚本。把“厂商代码”和“业务代码”分开放，最大的好处是固件库升级时能直接整个目录替换。
3.2 启动文件：为什么必须用GD官方的
启动文件的作用是：定义中断向量表、设置初始栈指针、调用SystemInit、然后跳转到main。如果用STM32的启动文件去跑GD32，短小工程能跑，但坑埋得很深——GD32的中断向量和部分外设和STM32有差异，哪怕能启动，后续一旦用到向量表里序号不一致的中断，就会出现“中断触发但进错函数”这种极其难查的问题。
GD32F10x固件库的Firmware/CMSIS/GD32F10x/Source/ARM目录下能找到startup_gd32f10x_hd.s（大容量，256KB以上Flash）、md.s（中等容量）、ld.s（低容量）。选哪个取决于你用的芯片型号，查数据手册里Flash大小，别猜，猜错编译能过但芯片跑不起来。
3.3 链接脚本：GD32和STM32的隐蔽差异
链接脚本定义了代码段、数据段、堆栈在Flash和SRAM里的布局。很多从STM32转GD32的人，图省事直接拿STM32的.ld改个芯片名就用，这里就有个隐蔽的雷：GD32F103和STM32F103的SRAM容量在部分型号上不一样，比如GD32F103系列的SRAM是从6KB到96KB不等，GD32F103VBT6是128KB Flash + 32KB SRAM，而部分新批次型号的SRAM实际更大。链接脚本里MEMORY区域的LENGTH如果写小了，白白浪费内存；写大了（超过实际SRAM），链接时还不会报错，运行时Array越界会随机死机。
我用的GD32F103VBT6链接脚本，核心的MEMORY段长这样：
MEMORY { FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 128K SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 32K }对于带64KB以上SRAM的型号如GD32F103VE，SRAM可以配到64KB。还有一点，GD32系列的0x20000000起始地址和ARM Cortex-M3标准一致，但部分型号支持ITCM接口，如果用到ITCM，链接脚本要额外增加一个内存区域，这个在追求极致性能时再研究，日常工程用不上。
3.4 Makefile：三分钟写一个可以用的构建脚本
Makefile的思路就是告诉编译器：固件库源码、启动文件、自己的源代码分别在哪，编译参数是什么，最后怎么链接。我提供一个精简可用的版本：
# 工具链前缀 PREFIX = arm-none-eabi- CC = $(PREFIX)gcc OBJCOPY = $(PREFIX)objcopy SIZE = $(PREFIX)size GDB = $(PREFIX)gdb # 芯片型号 MCU = cortex-m3 # 宏定义 DEFS = -DGD32F10X_HD -DUSE_STDPERIPH_DRIVER # 编译参数 CFLAGS = -mcpu=$(MCU) -mthumb -Wall -O2 \ -ffunction-sections -fdata-sections \ -I./core -I./libraries/CMSIS \ -I./libraries/peripherals/inc -I./user $(DEFS) LDFLAGS = -mcpu=$(MCU) -mthumb -T./ld/gd32f10x_flash.ld \ -Wl,--gc-sections -Wl,-Map=output.map # 源文件列表 C_SRCS = $(wildcard ./user/*.c) \ $(wildcard ./core/*.c) \ $(wildcard ./libraries/peripherals/src/*.c) ASM_SRCS = ./core/startup_gd32f10x_hd.s OBJS = $(C_SRCS:.c=.o) $(ASM_SRCS:.s=.o) all: firmware.elf firmware.bin %.o: %.c $(CC) $(CFLAGS) -c $< -o $@ %.o: %.s $(CC) $(CFLAGS) -c $< -o $@ firmware.elf: $(OBJS) $(CC) $(LDFLAGS) -o $@ $(OBJS) $(SIZE) $@ firmware.bin: firmware.elf $(OBJCOPY) -O binary $< $@ clean: rm -rf $(OBJS) firmware.elf firmware.bin output.map flash: JLink.exe -device GD32F103VB -if SWD -speed 4000 -autoconnect 1 -CommanderScript flash.jlink debug: @echo "请在VSCode中按F5启动调试" .PHONY: all clean flash debug几个关键参数解释一下原因。-mcpu=cortex-m3告诉编译器生成的指令集是M3的，别用cortex-m4，GD32F103是M3核，指令集不一样，常见的现象是编译能过，下载后HardFault。-ffunction-sections -fdata-sections配合--gc-sections，把没用到的函数和变量从最终镜像里剔除，GD32的Flash容量本来就不大，这组参数能省下不少空间。-O2是常规的优化级别，调试阶段我建议改成-O0 -g3，否则后面调试试变量会看到一堆被优化掉的值，这个问题在第5节细说。
4. VSCode侧配置：三个JSON文件搞定编辑、编译、调试
工程结构搭好，Makefile能编译了，接下来的重头戏是把VSCode配置成“一键编译、F5调试”的开发环境。需要动手改三个JSON文件，每个文件承担不同职责，我按顺序说清楚。
4.1 c_cpp_properties.json：让代码跳转和智能提示认识你的芯片
这个文件解决的是IntelliSense的问题。很多人的代码能编译过，但VSCode里全是红色波浪线，就是没配这个文件。它告诉C/C++插件：编译器是哪个、头文件在哪些目录、宏定义是什么。
{ "configurations": [ { "name": "GD32", "includePath": [ "${workspaceFolder}/**", "${workspaceFolder}/core", "${workspaceFolder}/libraries/CMSIS", "${workspaceFolder}/libraries/peripherals/inc", "${workspaceFolder}/user" ], "defines": [ "GD32F10X_HD", "USE_STDPERIPH_DRIVER" ], "compilerPath": "C:/xpack-arm-none-eabi-gcc-10.3.1-2.1/bin/arm-none-eabi-gcc.exe", "cStandard": "c11", "intelliSenseMode": "gcc-arm" } ], "version": 4 }这里最关键的是defines和compilerPath。defines里的GD32F10X_HD必须是你在Makefile中定义的宏，这决定固件库头文件里到底启用哪个型号的配置，两边不一致的后果是：代码能编译，但VSCode提示的头文件内容和你实际编译用的不是同一份，跳转全乱。compilerPath要填真实的GCC路径，C/C++插件会调用它来分析系统头文件，路径填错的话标准库相关的内容全部标红。
4.2 tasks.json：把编译动作绑到Ctrl+Shift+B
tasks.json的作用是把“编译”这个动作从命令行搬进VSCode。按下Ctrl+Shift+B就能触发Makefile里的all目标，不用再切到终端敲命令。配置如下：
{ "version": "2.0.0", "tasks": [ { "label": "build", "type": "shell", "command": "mingw32-make", "args": ["all"], "group": { "kind": "build", "isDefault": true }, "problemMatcher": [ "$gcc" ], "presentation": { "echo": true, "reveal": "always", "focus": false, "panel": "shared" } }, { "label": "clean", "type": "shell", "command": "mingw32-make", "args": ["clean"] } ] }一个容易忽略的细节：Windows上直接敲make可能提示找不到命令，因为你装GCC工具链时它不一定自带make.exe。两个解决办法：一是装一个MinGW-w64，把它的mingw32-make.exe改名或直接使用；二是用gmake。我习惯用MinGW-w64附带的mingw32-make，性能和兼容性都够。problemMatcher配$gcc是为了让编译报错能跳转到对应代码行，配上以后双击终端里的错误信息，VSCode会自动带你到出错那一行。
4.3 launch.json：Cortex-Debug接上JLink的关键配置
这是整套配置里最核心、也最容易出错的一个文件。它做的事情是：让VSCode启动Cortex-Debug插件，插件启动JLinkGDBServer，GDB Server再通过SWD接口连上芯片。配置如下：
{ "version": "0.2.0", "configurations": [ { "name": "GD32 Debug", "cwd": "${workspaceFolder}", "executable": "${workspaceFolder}/firmware.elf", "request": "launch", "type": "cortex-debug", "servertype": "jlink", "device": "GD32F103VB", "interface": "swd", "serverpath": "C:/Program Files/SEGGER/JLink/JLinkGDBServerCL.exe", "svdFile": "${workspaceFolder}/svd/GD32F10x.svd", "runToEntryPoint": "main", "armToolchainPath": "C:/xpack-arm-none-eabi-gcc-10.3.1-2.1/bin", "preLaunchTask": "build" } ] }几个参数的用意：device必须和JLink Commander里填的型号一致，填错最常见的报错是Selected device has no SWD port；interface用swd，现在几乎没有人用JTAG调试Cortex-M芯片；svdFile是芯片厂商提供的外设寄存器描述文件，配上以后调试器窗口能直接看到每个外设寄存器的位定义，GD32的SVD文件可以在网上搜到对应型号的资源；runToEntryPoint设为main，启动调试后自动跑到main函数，不用每次手动打断点。
如果点F5提示找不到GDB Server，优先检查serverpath是不是指向了JLinkGDBServerCL.exe。要注意的是，SEGGER新版驱动把这个文件名改过，旧版本叫JLinkGDBServer.exe，新版本在安装目录下可能只看到JLinkGDBServerCL.exe，这是正常的，CL后缀代表纯命令行版本，专供第三方工具调用。
5. JLink调试实战：从连接验证到断点、变量、寄存器的完整链路
配置全部就位，最激动人心的环节来了：按下F5，进入调试。但在这之前，我强烈建议先做一步“裸验证”——先用命令行确认JLink能连上芯片，再进图形界面调试。这样能第一时间把问题定位在硬件还是软件上。
5.1 用命令行验证连接
在终端里执行：
JLink.exe -device GD32F103VB -if SWD -speed 4000 -autoconnect 1然后输入connect回车，再接mem32 0x08000000 16，这条命令是把Flash起始地址的16个字读出来，如果芯片是全新的，读出来全是FFFFFFFF，说明JLink和芯片的通信链路是通的。
如果在这个阶段就报错，先查三件事：接线是不是SWDIO、SWCLK、GND、3V3四根线都对了（注意GD32的SWDIO和SWCLK对应的是PA13和PA14）；芯片有没有上电，独立供电的话JLink和目标板必须共地；JLink是不是D版或者固件被SEGGER新驱动拒了。关于最后一个问题，老版JLink驱动拒绝非正版仿真器的情况很常见，表现为Cannot connect to J-Link via USB，这种情况除了换正版没别的根治办法，有的老版本驱动能兼容，但我不建议在这种非法路子上花太多精力。
5.2 调试会话的完整工作流
连接验证通过后，F5进入调试，你会看到熟悉的VSCode调试界面。左侧调试面板有“运行和调试”窗口，从上到下能看到：
- 变量（VARIABLES）：局部变量、全局变量的实时值。这里有个大坑，我反复提醒也不为过——用
-O2编译出来的程序，变量被优化是常态，你会在变量窗口看到variable optimized out。调试阶段必须把Makefile里的CFLAGS改成-O0 -g3，改完记得重新编译再调试。 - 监视（WATCH）：手动添加表达式。看数组元素、结构体成员很方便，比如输入
(uint8_t *)buffer这种强制类型转换表达式，能按字节查看内存区域。 - 调用堆栈（CALL STACK）：函数调用关系。程序跑飞了以后第一件事就是看调用堆栈停在哪、是什么函数调进来的。
断点的类型也值得展开说说。普通行断点用得最多，点代码行号左侧即可；但嵌入式中更常用的是硬件断点和条件断点。Cortex-M3内核内置了硬件断点比较器，数量有限（通常是6个），你在调试Flash中的程序时用的其实是Flash断点——JLink会把断点地址处的指令暂时替换成BKPT指令，执行到的时候触发异常。在RAM中调试、或者频繁修改断点时，JLink自动切换机制可能出现“断点打不上”的情况，这时候把目标端的SRAM留出一小块给调试器保存原始指令，很多诡异断点问题就消失了。
条件断点是当某个变量满足条件才停下来。比如想在i == 0x1A时停在循环里，右键选择“添加条件断点”，输入i == 0x1A。注意条件表达式是在目标板的CPU上求值的，所以条件别写太复杂，否则会影响实时性。
5.3 在线内存和寄存器查看：调试硬件问题的利器
调试外设相关的问题时，寄存器窗口比变量窗口更直接。Cortex-Debug插件配合SVD文件，在调试时会自动加载外设寄存器视图。举个实际例子：你发现UART发不出数据，与其在代码里猜来猜去，不如Debug暂停后，在寄存器窗口找到USART1，直接看STAT寄存器的TC位和TXE位。如果TXE一直是0说明数据寄存器里还有没发完的数据，此时程序卡在某个等待循环里；如果TXE一直是1但发出的数据总是不对，那就去检查波特率寄存器BAUD的实际值，是不是和理论计算值偏差很大。这种排查方式比printf管用得多，printf本身还会干扰时序。
内存窗口输入0x20000000能看到SRAM的原始数据。我在排查DMA传输问题时，就喜欢在DMA搬运前后对比这块内存区域的数据，确认是源数据问题还是传输配置问题。
5.4 JLink的烧录命令：不打开调试也能下载
有时候只想烧个程序、不调式，可以用flash.jlink脚本文件。在工程根目录下建一个批处理内容：
device GD32F103VB si SWD speed 4000 connect loadbin firmware.bin 0x08000000 r g exit终端里执行JLink.exe -CommanderScript flash.jlink，JLink会按照脚本顺序执行连接、下载、复位运行。这条路径在做产测脚本、批量下载时非常有用，比打开IDE点下载按钮高效得多。
6. 我踩过的坑：编译、烧录、调试三个环节的高频故障
最后把这套环境跑了一个多月后积累的故障案例整理出来，基本都是“编译能过、下载能成、跑起来不对”甚至“芯片锁死”级别的坑，每一条都有实际教训在里面。
6.1 编译链接阶段：undefined reference和重复定义
undefined reference to 'SystemInit'是最经典的报错，原因是链接时找不到SystemInit函数。这个函数在system_gd32f10x.c里，启动文件会调用它来初始化时钟。解决办法是确认system_gd32f10x.c有没有被包含进编译列表，或者它是否被正确编译了。检查方法很直接：在Makefile变量C_SRCS里临时加一个$(info $(C_SRCS))输出实际源文件列表，看看system_gd32f10x.c在不在。
另一个高发问题是多个源文件重复定义同一个中断处理函数。比如你既写了gd32f10x_it.c里的USART1_IRQHandler，固件库的某个示例文件里也定义了一个，链接时就报multiple definition。解决方法是工程中同一份中断处理函数只能出现一次，查找所有IRQHandler后缀的函数，确认没有重复定义。
6.2 烧录阶段：芯片锁死与解锁方法
GD32有一个让新手非常崩溃的问题：GD32的读保护设置后芯片会被锁，表现出来就是JLink连接报Could not connect to target，或者连接成功后无法擦除Flash。常见触发场景是设置了读保护（RDP），或者程序里使用了不规范的Flash写操作。
解锁方法有两个层次。第一层，用JLink命令行的unlock命令试试：
unlock GD32F103VB如果这个命令能执行成功，紧接着重新连接擦除即可。第二层，如果unlock也连不上，需要把BOOT0引脚拉高（进入系统存储器模式），然后按住复位键，先点连接再松开复位，利用“连接窗口期”擦除整个Flash：
erase擦除完成后BOOT0拉低，恢复正常启动。这里有个经验之谈：别没事在程序里开读保护，尤其调试阶段，它除了给你添堵没有任何实际意义。如果确实要在量产阶段开读保护，务必先验证解锁流程是通的再执行。
6.3 调试阶段：HardFault的快速定位套路
程序跑飞进HardFault_Handler死循环是最常见又最让新手头疼的问题。我分享一个百试百灵的定位套路。第一步，在HardFault_Handler里加上断点（或者在启动文件里找到它的无限循环位置打断点），让程序停进异常处理。第二步，打开VSCode的调用堆栈窗口，查看发生异常前的函数调用链。第三步，如果调用堆栈看不到有效信息，查看CPU寄存器窗口，找到PC的值，然后到反汇编窗口输入这个地址，看当前执行到哪条指令——这条指令附近通常就是元凶。
异常码（CFSR寄存器）能帮你判断异常类型：ICSR的VECTACTIVE字段值为3表示HardFault，值为4表示MemManage Fault，值为6表示Bus Fault。Bus Fault最常见的原因是访问了不存在的外设地址或未对齐访问；MemManage Fault通常是栈溢出、堆越界、或者在中断里访问了受MPU保护的区域。拿STM32经验直接套GD32时，特别容易在Flash操作上踩Bus Fault，因为GD32的Flash控制器寄存器和STM32不同，状态位的判断逻辑也有差异，拿旧代码改型号时务必对照GD32的参考手册逐一核对。
6.4 优化等级导致的诡异现象
我强烈建议调试阶段用-O0，但你可能会遇到“-O0一切正常、-O2跑飞”的情况。这类问题的排查思路是：-O2下编译器的假设前提被破坏。最常见的是未初始化局部变量。-O0下栈上的随机值可能碰巧能用，-O2下寄存器分配策略一变，随机值变成错误值，程序就崩了。另一个常见问题是volatile遗漏，尤其涉及寄存器映射的变量，比如while (flag == 0);，如果flag不在循环体内修改且没有声明为volatile，-O2编译器可能把整个循环优化掉，表现为程序“卡死”但其实在飞跑。排查这类问题我习惯用二分法：先-O1试试，再逐个模块加-O2，用GCC的__attribute__((optimize("O0")))给可疑函数单独关优化。
7. 调试效率和工程管理的几个进阶建议
环境跑通只是起点，真正提升研发效率的是把这些流程进一步固化。我根据自己的使用习惯，分享几个进阶技巧。
第一，把烧录动作绑定到VSCode任务。在tasks.json里再加一个任务，调用make flash，配合VSCode的快捷键，实现“改代码-保存-一键烧录-看现象”的无缝循环。产测和硬件调试的时候，不用在多个窗口之间来回切换，效率提升很明显。
第二，利用Git管理工程文件版本。工程进入Git后，建议把output.map、firmware.elf、firmware.bin这些构建产物加进.gitignore，只提交源码和构建脚本。这样团队成员拉取代码后各自编译，不会产生二进制文件冲突。工程文件文本化是这套环境相对Keil最大的优势，一定要把这个优势用好。
第三，使用JLink的RTT组件做日志输出。传统的串口printf要占用串口资源、还要接电平转换芯片，而JLink的RTT（Real Time Transfer）通过SWD接口传输数据，不占用额外外设，速度还快。调试网络协议栈这类对时间敏感的程序时，RTT比串口实在太多。在GD32的SDK里，有专门的SEGGER_RTT源码可以移植，配合JLink RTT Viewer工具查看输出，体验和IDE里的调试终端差不多。
第四，定期用arm-none-eabi-size和map文件检查资源占用。编译结束后执行arm-none-eabi-size firmware.elf会输出text、data、bss三段的大小，加起来就是Flash占用（text+data）和SRAM占用（data+bss）。我见过不少项目在后期才突然发现Flash不够用，实际上从第一天就统计资源占用、每个迭代都看一眼增长趋势，能在早期就发现膨胀。
8. 我对这套环境最终的评价
从Keil迁到VSCode+JLink+GCC这套组合，起初只是被编辑体验吸引，用久了才发现真正的价值在于整个构建和调试链路都可以被脚本化、自动化。Makefile让编译逻辑完全透明，不再依赖某个IDE的工程文件格式；JLink的命令行模式让烧录、产测、解锁这些操作都能批量执行；VSCode的配置文件全部是JSON文本，放进Git里能清楚地看到每个人改过什么。这些优势在一个人开发时体现不明显，一旦进入团队协作、持续交付阶段，差距就拉得非常明显。
当然，这套方案也有它的代价。前期配置确实比Keil繁琐，要理解启动文件、链接脚本、GCC参数这些概念，对于只玩过图形化IDE的新手来说，头一两个项目会走一些弯路。但换个角度看，正是这些“麻烦”逼着你把芯片的启动过程、内存布局、编译原理这些底层知识补扎实了。我用这套环境做了几个GD32的项目之后，对片子本身的理解比之前用了几年Keil还深。
最后再分享一个开头没来得及说的小技巧：如果你手头同时有多个GD32型号的项目，建议把公共配置（比如c_cpp_properties.json的通用部分、Makefile的公共变量）抽出来，用VSCode的${workspaceFolder}相对路径替代绝对路径，然后复制到各项目里稍作修改。这样既能保持每个项目的独立性，又避免了维护多份完全相同配置的痛苦。折腾这套环境的过程里，我反复体会到一件事：工具链本身不是目的，它最终服务于“更快定位问题、更稳交付产品”。当你不再把时间浪费在环境问题上，才有更多精力去打磨真正有价值的功能逻辑。
