VSCode嵌入式开发环境搭建：从Keil迁移实战指南

1. VSCode嵌入式开发环境重构：从Keil迁移的工程实践

在嵌入式开发领域，IDE选择从来不是简单的工具偏好问题，而是直接影响开发效率、代码质量与团队协作能力的系统性工程决策。Keil MDK作为ARM Cortex-M系列开发的长期主流工具，其成熟稳定无可争议，但其商业授权成本、Windows平台绑定、AI辅助能力缺失以及编译速度瓶颈，在当前多核异构、快速迭代的开发场景下日益凸显。VSCode凭借其轻量级架构、开放插件生态与强大的AI集成能力，正成为嵌入式工程师重构开发工作流的核心载体。本节将系统阐述如何基于VSCode构建一个完整、可靠、可复现的嵌入式开发环境，重点解决从传统IDE迁移过程中最核心的三大挑战：编译工具链集成、项目结构自动化管理与硬件调试闭环验证。

1.1 系统级安装与权限模型设计

VSCode的安装起点即决定了后续环境的稳定性。必须采用 System Installer 版本（而非User Installer），这是整个环境健壮性的基石。User Installer在Windows系统中运行于受限用户上下文，其对注册表、系统路径及设备驱动的访问权限存在固有缺陷。当后续集成ST-Link或DAP-Link调试器时，驱动程序安装、USB设备枚举及OpenOCD通信均可能因权限不足而失败，表现为设备识别异常、烧录超时或调试会话无法建立。System Installer则以管理员权限安装，确保所有组件能在一致、可信的系统上下文中运行。

安装完成后，首要任务是建立清晰、可扩展的工具链目录结构。强烈建议在系统根目录（如 C:\tools ）下创建统一的 pass （Portable Application Suite）文件夹，该命名并非随意，而是源于嵌入式开发中“可移植应用套件”的工程实践共识。在此目录下，集中存放所有第三方工具：
- gcc-arm-none-eabi ：ARM官方GNU工具链
- openocd ：开源片上调试服务器
- stlink ：ST官方调试工具集
- arm-none-eabi-gdb ：GNU调试器

此结构的价值在于：第一，避免工具散落在用户目录或桌面，导致路径混乱与版本失控；第二，为环境变量配置提供唯一、明确的锚点；第三，便于团队间通过文档共享 pass 路径，实现环境一键同步。环境变量 PATH 的配置必须精确指向 C:\tools\pass\gcc-arm-none-eabi\bin 等具体 bin 子目录，任何层级偏差都将导致 arm-none-eabi-gcc 等命令在终端中不可用。

1.2 C/C++智能感知引擎的深度配置

VSCode的代码编辑体验高度依赖C/C++扩展（ ms-vscode.cpptools ）的索引能力。其核心配置文件 c_cpp_properties.json 中的 includePath 字段，是打通头文件解析、符号跳转与错误检查的生命线。一个典型的、面向多平台的配置需覆盖三层包含路径：

{
  "configurations": [
    {
      "name": "STM32_HAL",
      "includePath": [
        "${workspaceFolder}/**",
        "C:/tools/pass/STM32Cube_FW_F4_V1.27.1/Drivers/STM32F4xx_HAL_Driver/Inc/**",
        "C:/tools/pass/STM32Cube_FW_F4_V1.27.1/Drivers/CMSIS/Device/ST/STM32F4xx/Include/**",
        "C:/tools/pass/STM32Cube_FW_F4_V1.27.1/Drivers/CMSIS/Include/**"
      ],
      "defines": ["USE_HAL_DRIVER", "STM32F429xx"],
      "intelliSenseMode": "gcc-arm"
    }
  ]
}

此处的关键逻辑在于 目的驱动 ： includePath 的每一项都对应一个明确的工程需求。 "${workspaceFolder}/**" 确保项目内所有源码与头文件被索引，避免 #include "main.h" 报错； STM32Cube_FW 路径的引入，则是为了解决HAL库函数（如 HAL_UART_Transmit ）的声明解析，使Ctrl+Click能精准跳转至函数定义； CMSIS 路径则保障了 __IO uint32_t 等核心类型定义与 NVIC_EnableIRQ 等底层寄存器操作函数的可用性。 defines 数组中的宏定义，直接映射到编译器预处理阶段，确保 #ifdef USE_HAL_DRIVER 条件编译分支被正确识别，这是避免大量红色波浪线的根本。

对于8051开发者， c_cpp_properties.json 需额外处理Keil C51特有的内存模式关键字（ small , large , xdata ）。这些并非标准C语法，若不显式告知IntelliSense，编辑器将视其为语法错误。解决方案是在 "defines" 中添加 "__C51__" 宏，并在 "compilerPath" 中指定Keil C51编译器路径（如 "C:/Keil_v5/C51/BIN/C51.exe" ），使IntelliSense模拟C51编译器的预处理行为，从而消除误报。

1.3 EIDE插件：项目元数据与构建系统的中枢

EIDE（Embedded IDE）插件是VSCode嵌入式生态的枢纽，它超越了传统编辑器的范畴，本质上是一个 项目元数据管理器与构建流程协调器 。其核心价值在于将分散的、手工维护的构建配置（Makefile、链接脚本、启动文件）抽象为结构化的JSON描述，并通过图形化界面驱动整个工具链。安装EIDE后，其自动检测并拉取.NET 6运行时的行为，虽在首次启动时略显缓慢，但这是其跨平台兼容性与插件沙箱安全模型的必然代价。手动下载并预置.NET 6 SDK（ dotnet-sdk-6.0.x-win-x64.exe ）至 C:\tools\pass\dotnet ，可规避网络波动导致的安装失败。

EIDE的配置核心在于 eide.json 文件，它定义了项目的“数字孪生”。一个典型的STM32 HAL项目配置如下：

{
  "build": {
    "toolchain": "gcc-arm-none-eabi",
    "toolchainPath": "C:/tools/pass/gcc-arm-none-eabi/bin",
    "cpu": "cortex-m4",
    "fpu": "fpv4-d16",
    "floatAbi": "hard",
    "linkerScript": "STM32F429ZITx_FLASH.ld",
    "startupFile": "startup_stm32f429xx.s"
  },
  "debug": {
    "adapter": "openocd",
    "openocdPath": "C:/tools/pass/openocd/bin/openocd.exe",
    "configFiles": [
      "interface/stlink-v2-1.cfg",
      "target/stm32f4x.cfg"
    ]
  }
}

build 段落的每一个参数都直指硬件本质： cpu 和 fpu 选项决定了生成代码的指令集与浮点运算单元调用方式，错误配置将导致二进制无法在目标芯片上执行； linkerScript 的路径必须与CubeMX生成的 .ld 文件严格一致，因为链接脚本定义了Flash与RAM的物理地址布局（如 FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 2048K ），这是程序能否正确加载的物理基础； startupFile 则关联到启动汇编代码，其内部定义的向量表位置（ .section .isr_vector,"a",%progbits ）必须与链接脚本中 .isr_vector 段的起始地址完全匹配，否则复位后CPU将跳转至错误地址，系统无法启动。

1.4 工程导入范式：从CubeMX到VSCode的零误差迁移

直接在VSCode中新建空项目并手动添加文件，是初学者最常见的陷阱，其后果是项目结构错乱、路径引用失效、构建配置丢失。正确的范式是 以CubeMX为源头，VSCode为呈现端 。CubeMX生成的工程（无论是MDK-ARM还是Makefile）已包含了所有硬件相关的元数据：时钟树配置、外设初始化代码、中断向量表、内存布局。EIDE的“Import Project”功能正是为此设计，它能解析CubeMX生成的 *.ioc 文件或 Makefile ，自动提取并映射这些元数据。

以HAL库Makefile工程为例，导入流程如下：
1. 启动文件虚拟化 ：CubeMX生成的 startup_stm32f429xx.s 位于 Drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/gcc/ 。在VSCode资源管理器中，右键点击工作区根目录 → “Add Virtual Folder”，命名为 startup ，并将 startup_stm32f429xx.s 拖入其中。此举创建了一个逻辑容器，使启动文件在项目结构中可见且可编辑，同时避免了物理路径硬编码。
2. 源码目录物理化 ：将CubeMX生成的 Core 、 Drivers 、 Middlewares 等真实文件夹，通过“Add Folder to Workspace”逐个添加。此时， Core/Src/main.c 与 Core/Inc/main.h 等文件即被纳入工作区，其相对路径与CubeMX工程完全一致。
3. 链接脚本与构建器绑定 ：在EIDE设置中， Linker Script Path 必须指向CubeMX生成的 STM32F429ZITx_FLASH.ld （位于 Core 目录）。此文件由CubeMX根据所选芯片型号与Flash/RAM大小自动生成，其内容（如 _estack = 0x20020000; ）直接决定了栈顶地址，是RTOS任务栈分配与全局变量初始化的物理依据。

此范式确保了“一次配置，处处运行”。当CubeMX中修改了USART2的波特率或TIM1的预分频值，只需重新生成代码并覆盖 Core/Src 与 Core/Inc 目录，VSCode中的项目即可无缝继承所有变更，无需手动调整任何编译或链接参数。

2. 多平台编译工具链的协同与验证

嵌入式开发的终极目标是生成可在目标硬件上正确执行的二进制镜像。这要求编译工具链不仅在语法层面正确，更需在语义层面与硬件行为严格对齐。GCC、Keil ARMCC（AC5/AC6）与Keil C51是三类截然不同的工具链，其ABI（应用二进制接口）、启动代码与库函数实现存在本质差异。本节将深入剖析它们的集成逻辑与验证方法。

2.1 GCC-ARM-None-EABI：开源工具链的工业级实践

gcc-arm-none-eabi 是ARM官方维护的GNU工具链，专为裸机（Bare-Metal）与RTOS环境设计。其优势在于极致的编译速度与丰富的优化选项（ -O2 , -Os , -flto ），但其配置复杂度也远超Keil。关键配置项解析如下：

验证GCC工具链是否正确集成，最直接的方法是编译一个仅包含 while(1); 的 main.c ，并检查生成的 .elf 文件：

arm-none-eabi-size build/project.elf
# 输出应类似：text    data     bss     dec     hex filename
#         12345    1234    5678   19257    4b39 build/project.elf

text 大小反映代码体积， data 与 bss 之和反映RAM占用。若 data 为0而 bss 巨大，说明全局变量未被正确初始化，极可能是链接脚本中 .data 段起始地址（ _sdata ）与RAM物理地址不匹配。

2.2 Keil ARMCC（AC5/AC6）：商业编译器的兼容性桥接

尽管GCC是开源首选，但部分遗留项目或特定IP核（如某些DSP算法库）仅提供AC5/AC6编译器的预编译库（ .lib ）。EIDE支持通过 toolchainPath 指向 C:\Keil_v5\ARM\ARMCC\bin\ 来调用AC5，或指向 C:\Keil_v5\ARM\ARMCLANG\bin\ 调用AC6（基于LLVM）。AC6的 --target=arm-arm-none-eabi 标志使其输出与GCC兼容的ELF格式，这是实现混合编译的关键。

然而，AC5/AC6与GCC在启动代码上有根本差异。AC5/AC6默认使用 startup_stm32f429xx.s 中的 __main 函数，它负责 .data 段拷贝与 .bss 段清零；而GCC的 crt0.o 则由 _start 入口调用 __libc_init_array 。因此，当在VSCode中切换工具链时，必须同步更新 eide.json 中的 startupFile 与 linkerScript ，确保二者风格一致。例如，AC5/AC6通常使用 STM32F429ZITx_FLASH.scf （scatter-loading file），而GCC使用 .ld 文件。

2.3 Keil C51：8051经典架构的现代适配

C51编译器是8051开发的行业标准，其独特之处在于对51内核特殊内存空间（ idata , xdata , code ）的原生支持。在VSCode中启用C51支持，需在 c_cpp_properties.json 中进行双重配置：
1. IntelliSense层面 ： "compilerPath": "C:/Keil_v5/C51/BIN/C51.exe" ，使编辑器能识别 xdata unsigned char buffer[256]; 等非标准语法。
2. 构建层面 ：在EIDE的 build.toolchainPath 中指向 C:/Keil_v5/C51/BIN/ ，并在 build.compilerFlags 中添加 -p8051 （指定目标芯片）与 -c （仅编译，不链接）。

C51的链接过程（ BL51 ）需单独配置。EIDE通过 build.linkerPath 指向 C:/Keil_v5/C51/BIN/BL51.exe ，并用 build.linkerFlags 指定 "STARTUP.OBJ" （启动对象）与 "myproject.OBJ" （用户对象）。一个常见陷阱是 STARTUP.OBJ 的版本必须与C51编译器主版本严格匹配，否则链接时会报 *** ERROR L104: MULTIPLE PUBLIC DEFINITIONS 。因此， STARTUP.OBJ 应始终从 C:/Keil_v5/C51/LIB/ 目录下获取，而非旧项目中复制。

3. 硬件烧录与调试闭环：ST-Link与DAP-Link的双轨实践

编译成功的 .hex 或 .elf 文件只是静态镜像，其价值必须通过写入目标芯片并验证运行行为才能体现。烧录（Flashing）与调试（Debugging）是嵌入式开发的最后也是最关键的闭环。ST-Link与DAP-Link是目前最主流的两种调试探针，它们在VSCode中的集成策略既有共性，也存在关键差异。

3.1 ST-Link：ST官方生态的深度整合

ST-Link是意法半导体为其MCU定制的调试接口，其驱动与工具链高度耦合。在VSCode中实现ST-Link烧录，需完成三个层次的集成：
1. 驱动层 ：安装 STSW-LINK009 （ST-Link USB Driver）。驱动文件位于 C:\Users\<user>\.eide\toss\stlink\drivers\ ，双击 stlink_winusb.inf 并强制安装。驱动安装成功后，在设备管理器中应显示为“STMicroelectronics ST-LINK/V2-1”。
2. 工具层 ：EIDE内置 stlink 工具，其路径需在 eide.json 中配置为 "C:/tools/pass/stlink/bin/st-util.exe" 。 st-util 是一个轻量级GDB服务器，它将ST-Link硬件协议转换为GDB远程调试协议（ localhost:4242 ）。
3. 调试器层 ：VSCode的 launch.json 需配置为GDB客户端：

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "ST-Link Debug",
      "type": "cppdbg",
      "request": "launch",
      "miDebuggerPath": "C:/tools/pass/arm-none-eabi-gdb/bin/arm-none-eabi-gdb.exe",
      "miDebuggerServerAddress": "localhost:4242",
      "program": "${workspaceFolder}/build/project.elf",
      "stopAtEntry": true,
      "externalConsole": false,
      "cwd": "${workspaceFolder}"
    }
  ]
}

烧录本身由 st-util 的 --flash 参数触发，但VSCode的EIDE插件已将其封装为图形化按钮。点击“Download”时，EIDE后台执行 st-flash --reset write build/project.bin 0x08000000 ，将二进制流写入Flash起始地址。验证烧录成功最简单的方法是串口监听：若程序中配置了 printf("Hello ST-Link\r\n"); 并通过USART1（PA9/PA10）输出，则在VSCode集成终端中启动 serial monitor （波特率115200），应实时看到该字符串。

3.2 DAP-Link：ARM开源标准的灵活部署

DAP-Link是ARM官方推出的开源调试固件，其优势在于跨厂商兼容性（支持NXP、Nordic、Infineon等）与固件可升级性。但在VSCode中使用DAP-Link， 必须经由OpenOCD作为中间件 ，因为DAP-Link本身不直接提供GDB服务器接口。集成流程如下：
1. 固件验证 ：首先确认DAP-Link设备已正确刷入最新固件。将DAP-Link通过USB连接PC，在Windows中应识别为“MBED Microcontroller”。若识别为“CMSIS-DAP”，则需更新固件：从 https://github.com/ARMmbed/DAPLink/releases 下载最新 daplink_<version>.bin ，将其拖拽至“MBED”盘符下，设备将自动重启并完成升级。
2. OpenOCD配置 ： openocd.cfg 是OpenOCD的灵魂。针对STM32F429，其核心配置为：

source [find interface/cmsis-dap.cfg]
transport select swd
source [find target/stm32f4x.cfg]
reset_config srst_only

cmsis-dap.cfg 启用DAP-Link接口， stm32f4x.cfg 加载芯片专用配置（包括Flash编程算法）， srst_only 指定仅使用系统复位（而非调试复位），这对某些低功耗模式退出至关重要。
3. VSCode调试启动 ： launch.json 中 miDebuggerServerAddress 需指向OpenOCD的GDB端口（默认3333）：

{
  "name": "DAP-Link Debug",
  "type": "cppdbg",
  "request": "launch",
  "miDebuggerPath": "C:/tools/pass/arm-none-eabi-gdb/bin/arm-none-eabi-gdb.exe",
  "miDebuggerServerAddress": "localhost:3333",
  "program": "${workspaceFolder}/build/project.elf",
  "stopAtEntry": true,
  "externalConsole": false,
  "cwd": "${workspaceFolder}",
  "setupCommands": [
    { "description": "Enable pretty-printing for gdb", "text": "-enable-pretty-printing", "ignoreFailures": true }
  ]
}

一个关键实践是： 同时配置ST-Link与DAP-Link的 launch.json 。当一块板子同时连接两种调试器时（如Nucleo板自带ST-Link，外接DAP-Link），可通过VSCode左下角的调试配置选择器，一键切换调试目标，极大提升了多硬件平台的开发效率。

4. 调试会话的精细化控制与变量监视

调试（Debugging）的本质是将程序的运行时状态可视化。VSCode的调试界面提供了强大的变量监视（Watch）、内存查看（Memory View）与寄存器监控（Registers View）能力，但其效能取决于底层调试器（GDB）与目标芯片的深度协同。

4.1 ELF格式：调试信息的唯一载体

所有调试操作的前提是生成的可执行文件包含完整的调试信息（DWARF格式）。这要求编译器在编译与链接阶段均启用调试选项：
- 编译阶段： arm-none-eabi-gcc -g -O0 -c main.c -o main.o
- 链接阶段： arm-none-eabi-gcc -g main.o -o project.elf -T STM32F429ZITx_FLASH.ld

-g 标志指示编译器生成DWARF调试信息， -O0 禁用优化，确保源码行与机器指令一一对应。若使用 -O2 ，编译器可能内联函数、消除变量，导致调试时无法查看 i 变量的值，或断点无法准确停在预期行。EIDE的“Convert to ELF”选项（在项目属性中勾选）正是为此服务，它确保最终输出的是带调试信息的 .elf ，而非仅用于烧录的 .hex 。

4.2 实时变量监视：从局部到全局的洞察

VSCode调试界面的“WATCH”面板是观察程序状态的核心。其强大之处在于支持任意表达式，而不仅是简单变量名。例如：
- &i ：查看变量 i 的内存地址，验证其是否位于RAM（0x20000000起始）而非Flash。
- *(uint32_t*)0x40023800 ：直接读取RCC_CR寄存器（地址0x40023800）的原始值，验证时钟使能状态。
- HAL_GetTick() ：调用HAL库函数，实时获取系统滴答计数，用于验证SysTick中断是否正常工作。

一个易被忽视的细节是 变量作用域 。局部变量（如 for(int i=0; i<10; i++) 中的 i ）在函数退出后即失效，其值在WATCH面板中可能显示为 <optimized out> 。此时，应将变量声明为 static int i; ，使其生命周期扩展至整个程序运行期，从而保证调试时的可观测性。

4.3 断点策略：从功能验证到故障定位

断点（Breakpoint）是调试的起点，但其设置需有明确目的：
- 入口断点 ：在 main() 函数首行设置，验证程序是否能正常启动，排除复位向量或启动代码问题。
- 外设初始化断点 ：在 HAL_UART_Init(&huart1) 之后设置，检查 huart1.Instance->BRR 寄存器值是否与期望波特率（如115200）匹配，验证时钟配置与寄存器写入是否成功。
- 中断服务函数断点 ：在 USART1_IRQHandler() 内设置，确认中断是否被正确触发与响应，这是排查中断失灵的第一步。

当断点无法命中时，首要检查 launch.json 中的 stopAtEntry 是否为 true ，并确认 program 路径指向的是 .elf 而非 .hex 。其次，检查OpenOCD或ST-Util的日志输出，确认其是否报告了 target halted due to debug-request ，这表明调试器已成功接管CPU。若日志显示 Timed out waiting for ACK ，则问题大概率出在SWD线路（如NRST未接、SWCLK/SWDIO接触不良）或目标芯片处于深度睡眠模式。

5. 工程实践中的典型故障与排障路径

在将VSCode嵌入式工作流投入实际项目前，必须预见并掌握一套系统化的排障方法论。以下列举几个高频、高破坏性的故障及其根因分析。

5.1 “No Space in Memory”链接错误：Flash布局失配

当导入CubeMX生成的HAL工程后首次编译，常出现 Error: No space in memory 。这并非代码真的超出了Flash容量，而是 链接脚本中定义的Flash区域长度与实际芯片型号不匹配 。CubeMX生成的 STM32F429ZITx_FLASH.ld 文件中， LENGTH = 2048K 对应2MB Flash，但若开发者实际使用的是STM32F429VIT6（仅1MB Flash），链接器便会因空间不足而失败。

排障路径：
1. 打开 STM32F429ZITx_FLASH.ld ，定位 MEMORY 段。
2. 核对 STM32F429ZIT6 （2MB）与 STM32F429VIT6 （1MB）的数据手册，确认实际Flash大小。
3. 修改 LENGTH = 1024K ，并同步调整 _estack （栈顶地址）以适应RAM变化。
4. 在EIDE设置中，重新指定修正后的链接脚本路径。

此错误深刻揭示了嵌入式开发中“硬件即配置”的铁律：任何软件配置都必须与物理芯片的电气特性（Flash/RAM大小、外设数量）严格对齐。

5.2 “Cannot find ‘gpio.h’”：头文件路径的隐式依赖

当导入Makefile工程后，编译报错 fatal error: stm32f4xx_hal_gpio.h: No such file or directory ，表面看是头文件缺失，实则是 EIDE未能自动解析Makefile中 -I （include）参数 。Makefile中通常有 INCLUDES = -I$(CMSIS_DEVICE_PATH)/Include -I$(HAL_DRIVER_PATH)/Inc ，但EIDE的C/C++扩展并不读取Makefile。

排障路径：
1. 在VSCode中按 Ctrl+Shift+P ，输入 C/C++: Edit Configurations (UI) 。
2. 在打开的UI界面中，“Configuration Provider”选择 Default ，然后在“Include path”中，手动添加：
- C:/tools/pass/STM32Cube_FW_F4_V1.27.1/Drivers/CMSIS/Device/ST/STM32F4xx/Include
- C:/tools/pass/STM32Cube_FW_F4_V1.27.27.1/Drivers/STM32F4xx_HAL_Driver/Inc
3. 保存后，IntelliSense索引会自动重建，红色波浪线消失。

此案例强调：VSCode的编辑器环境（IntelliSense）与构建环境（Makefile）是两个独立系统，前者负责代码编写体验，后者负责二进制生成，二者需通过 c_cpp_properties.json 显式桥接。

5.3 “Target Not Found”调试失败：USB枚举与权限冲突

当点击“Start Debugging”后，VSCode输出 Error: unable to find a matching device ，这是硬件连接层的典型故障。根因往往不在软件配置，而在物理层或操作系统层。

排障路径：
1. 物理层 ：检查SWD线缆（SWCLK, SWDIO, GND）是否牢固插入，NRST线是否连接（某些调试器需此线才能复位芯片）。
2. 操作系统层 ：在Windows设备管理器中，查看“通用串行总线控制器”下是否有带黄色感叹号的“Unknown Device”或“CMSIS-DAP”。若有，右键卸载设备并勾选“删除此设备的驱动程序软件”，然后拔插调试器，让系统重新安装驱动。
3. 权限层 ：若使用WSL2，USB设备默认不可见。需在WSL2中执行 usbipd wsl list 查看设备，再用 usbipd wsl attach --busid <busid> 挂载，否则OpenOCD将永远无法找到目标。

这些排障步骤构成了一个从物理世界（电缆、芯片）到数字世界（驱动、配置）的完整映射，是嵌入式工程师必备的系统级思维。

我曾在某款工业网关项目中，因CubeMX生成的 system_stm32f4xx.c 中 SystemCoreClock 变量被声明为 __IO uint32_t （volatile），而我在 main.c 中尝试用 printf("%lu", SystemCoreClock) 打印其值，结果在GDB中监视时发现该值始终为0。排查数小时后才意识到， printf 函数本身需要重定向 _write 系统调用，而我的工程未配置 nosys.specs ，导致 printf 调用陷入死循环， SystemCoreClock 的更新被阻塞。最终解决方案是：在调试阶段，改用 HAL_UART_Transmit 直接发送字符串，并在 HAL_UART_TxCpltCallback 中更新一个非volatile的全局变量用于监视。这个坑让我彻底理解了“调试器看到的世界”与“程序实际运行的世界”之间，存在着由编译器优化、库函数实现与硬件外设共同构成的复杂鸿沟。