首页/资讯中心/详情

Windows下基于VSCode与GCC的STM32开发环境搭建与调试实战

Windows下基于VSCode与GCC的STM32开发环境搭建与调试实战
📅 发布时间：2026/7/31 3:54:16

1. 从Keil到Vscode：为什么我要在Windows上“折腾”STM32开发环境

如果你和我一样，长期在Windows上用Keil MDK或者IAR搞STM32开发，第一次听说用Vscode来干这事儿，心里多半会嘀咕：这不是给自己找麻烦吗？Keil点几下鼠标就能编译下载，用得好好的，干嘛要换？我最初也是这么想的，直到我被几个现实问题反复折磨：项目文件一多，Keil的编辑器代码补全和跳转就变得异常卡顿，几乎不可用；想用个现代的版本控制工具（比如Git）来管理代码，Keil对中文路径、特殊字符的支持总是出些莫名其妙的幺蛾子；最要命的是，当你需要查阅大量数据手册、参考开源库代码时，不得不在Keil、PDF阅读器、网页浏览器之间来回切换，效率低得令人抓狂。

Vscode的出现，本质上不是要替代Keil的编译和调试核心（那是ARM编译器GCC和OpenOCD等工具链的事），而是为我们提供了一个高度可定制、扩展性极强、且体验统一的现代化代码编辑中心。你可以把它理解为你工作台的一个超级控制面板。在这个面板里，你写代码有智能感知（IntelliSense）和强大的代码导航；管理项目可以用内置的终端和Git工具；阅读文档可以分屏预览Markdown或PDF；甚至画个简单的流程图都能找到插件。而Keil或者STM32CubeIDE，则退化为专司“编译、链接、下载、调试”的“后端引擎”。这种前后端分离的思路，让专业工具各司其职，开发者体验得到了质的提升。

所以，在Windows下用Vscode开发STM32，目标不是抛弃原有的工具链，而是用Vscode构建一个更舒适、更高效的前端界面，去驱动和整合那些我们熟悉的、可靠的后端工具。这个过程有点像给一辆可靠的汽车（STM32工具链）装上了一个更智能、显示信息更丰富的车机系统（Vscode）。接下来，我就把自己从零搭建这套环境，并应用到实际项目中的完整过程、踩过的坑以及最终沉淀下来的配置心得，毫无保留地分享给你。

2. 环境基石：构建不依赖特定IDE的纯命令行工具链

用Vscode开发，第一步也是最关键的一步，就是搭建一个完全可以在命令行中独立运行的STM32编译和调试工具链。这确保了我们的开发环境不依赖于任何IDE的图形界面，是后续所有流畅体验的基础。

2.1 编译器选择与安装：ARM GNU Toolchain

Keil和IAR使用其私有的编译器，而我们转向Vscode，通常选择开源的GCC ARM嵌入式工具链。这里我强烈推荐Arm官方维护的 Arm GNU Toolchain 。相比其他社区版本，它更新更及时，对Arm Cortex-M系列架构的支持也最权威。

  1. 下载：访问上述链接，选择适合Windows的版本。对于STM32（Cortex-M），选择 “AArch32 bare-metal target (arm-none-eabi)” 这个版本。通常下载那个带有最新版本号（如12.3.rel1）的Windows exe安装包。
  2. 安装：安装过程很简单，但有一个关键点：在“Select Additional Tasks”这一步，务必勾选“Add path to environment variable”。这会将编译器的bin目录添加到系统的PATH环境变量中，这样在任意位置的命令行或Vscode终端里都能直接调用arm-none-eabi-gcc等命令。
  3. 验证：安装完成后，打开一个新的命令行窗口（CMD或PowerShell），输入arm-none-eabi-gcc --version并回车。如果能看到输出版本信息，说明安装和PATH配置成功。

注意：很多教程会推荐使用MSYS2或WSL（Windows Subsystem for Linux）里的GCC。对于纯STM32开发，我建议优先使用原生的Windows版本工具链。这能避免文件路径、环境变量在Windows和Linux子系统之间转换带来的潜在麻烦，特别是当你需要与一些只有Windows版本的调试器软件（如ST-LINK Utility）配合时，原生环境的兼容性更好。

2.2 构建系统：为什么是Make而不是CMake？

有了编译器，我们需要一个“指挥家”来告诉编译器如何编译一个个源文件，并最终链接成可执行文件。这就是构建系统。常见的有Make和CMake。

  • Make：直接使用Makefile文件。它更直接，依赖关系写得很明确，对于单片机这类文件数量相对固定、结构清晰的中小型项目，编写和维护一个Makefile并不复杂。其优点是轻量、直观，与命令行工具链结合最紧密。
  • CMake：生成Makefile或其他构建文件（如Ninja）的元构建系统。它更抽象，擅长管理大型、跨平台的项目。但对于STM32项目，你需要额外编写CMakeLists.txt，并且需要处理交叉编译的工具链文件（toolchain.cmake），入门曲线稍陡。

我的选择是Make。原因很简单：STM32项目结构通常不复杂，一个精心编写的Makefile足以应对，并且它能让你更清楚地了解从源文件到.hex/.bin文件的每一个步骤，这对于排查编译问题非常有帮助。下面是一个极简的Makefile框架，你可以以此为基础扩展：

# 工具链前缀 CROSS_COMPILE = arm-none-eabi- CC = $(CROSS_COMPILE)gcc OBJCOPY = $(CROSS_COMPILE)objcopy SIZE = $(CROSS_COMPILE)size # 工程名 TARGET = my_stm32_project # 编译目录 BUILD_DIR = build # 源文件目录 C_SOURCES = \ Src/main.c \ Src/stm32f1xx_it.c \ Src/system_stm32f1xx.c \ Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_gpio.c \ # ... 添加所有需要的.c文件 # 头文件目录 C_INCLUDES = \ -ICore/Inc \ -IDrivers/STM32F1xx_HAL_Driver/Inc \ -IDrivers/CMSIS/Device/ST/STM32F1xx/Include \ -IDrivers/CMSIS/Include # 编译选项 CPU = -mcpu=cortex-m3 FPU = # 对于F1系列没有FPU，对于F4/F7等需要 -mfpu=fpv4-sp-d16 -mfloat-abi=hard MCU = $(CPU) -mthumb $(FPU) CFLAGS = $(MCU) $(C_INCLUDES) -Og -Wall -fdata-sections -ffunction-sections # 调试信息 CFLAGS += -g -gdwarf-2 # C标准 CFLAGS += -std=gnu11 # 链接脚本 LDSCRIPT = STM32F103C8Tx_FLASH.ld # 链接选项 LDFLAGS = $(MCU) -specs=nano.specs -T$(LDSCRIPT) -Wl,-Map=$(BUILD_DIR)/$(TARGET).map,--cref -Wl,--gc-sections # 自动生成对象文件列表 OBJECTS = $(addprefix $(BUILD_DIR)/,$(notdir $(C_SOURCES:.c=.o))) vpath %.c $(sort $(dir $(C_SOURCES))) # 默认目标：生成hex和bin文件 all: $(BUILD_DIR)/$(TARGET).elf $(BUILD_DIR)/$(TARGET).hex $(BUILD_DIR)/$(TARGET).bin # 链接 $(BUILD_DIR)/$(TARGET).elf: $(OBJECTS) $(CC) $(OBJECTS) $(LDFLAGS) -o $@ $(SIZE) $@ # 编译.c文件为.o文件 $(BUILD_DIR)/%.o: %.c Makefile | $(BUILD_DIR) $(CC) -c $(CFLAGS) -Wa,-a,-ad,-alms=$(BUILD_DIR)/$(notdir $(<:.c=.lst)) $< -o $@ # 生成hex文件 $(BUILD_DIR)/%.hex: $(BUILD_DIR)/%.elf $(OBJCOPY) -O ihex $< $@ # 生成bin文件 $(BUILD_DIR)/%.bin: $(BUILD_DIR)/%.elf $(OBJCOPY) -O binary -S $< $@ # 创建编译目录 $(BUILD_DIR): mkdir $@ # 清理 clean: rm -rf $(BUILD_DIR) # 烧录（需要根据你的调试器调整，例如用OpenOCD） flash: $(BUILD_DIR)/$(TARGET).elf openocd -f interface/stlink.cfg -f target/stm32f1x.cfg -c "program $< verify reset exit" .PHONY: all clean flash

这个Makefile定义了编译器、搜索路径、编译选项，并实现了自动推导依赖、创建构建目录、生成多种格式输出文件以及清理的功能。flash目标预留了使用OpenOCD烧录的接口。

2.3 调试与烧录器：OpenOCD的配置之道

调试和下载程序，我们需要一个连接电脑和ST-Link/J-Link等调试器的桥梁。OpenOCD（Open On-Chip Debugger）就是这个桥梁，它是一个开源的调试服务器。

  1. 安装：从 OpenOCD官网 下载最新的Windows二进制包，解压到一个不含中文和空格的路径，例如D:\Tools\openocd。同样，需要将其bin目录（如D:\Tools\openocd\bin）添加到系统的PATH环境变量中。

  2. 验证：命令行输入openocd --version，看到版本信息即成功。

  3. 配置文件：OpenOCD通过配置文件（.cfg）工作。它通常需要两个文件：

    • 接口配置：描述你使用的调试器。例如，对于ST-Link V2，你可以使用OpenOCD自带的interface/stlink.cfg。
    • 目标芯片配置：描述你要调试的STM32芯片。例如，对于STM32F103，使用target/stm32f1x.cfg。

    你可以在命令行中组合它们：openocd -f interface/stlink.cfg -f target/stm32f1x.cfg。运行后，OpenOCD会启动一个GDB服务器（默认端口3333）和一个Telnet服务器（默认端口4444）。此时，你的调试器就准备好了。

实操心得：OpenOCD的配置文件路径有时会比较麻烦。一个更稳妥的做法是，在你的项目根目录下创建一个openocd.cfg文件，里面直接写：

source [find interface/stlink.cfg] source [find target/stm32f1x.cfg]

然后在命令行或Vscode任务中，只需执行openocd -f openocd.cfg即可。[find]命令会让OpenOCD在其脚本目录中自动搜索配置文件，避免了写绝对路径的麻烦。

至此，一个独立的命令行工具链就搭建好了。你可以在任何终端中，通过make命令编译项目，通过openocd启动调试服务器。Vscode接下来要做的，就是让我们能更优雅、更可视化地使用这些命令。

3. Vscode核心配置：将工具链无缝接入编辑器

安装Vscode本身很简单，从官网下载安装即可。接下来的核心是安装插件和配置工作区，让Vscode“认识”我们的STM32项目。

3.1 必装插件清单与作用解析

在Vscode的扩展市场（Ctrl+Shift+X）中，安装以下插件：

  1. C/C++ (Microsoft)：这是核心中的核心。它提供代码智能感知（IntelliSense）、错误波浪线、代码导航（跳转到定义、查找引用）、代码格式化等功能。没有它，Vscode就是一个高级记事本。
  2. Cortex-Debug：这是STM32（乃至所有Cortex-M芯片）调试体验的灵魂插件。它提供了一个图形化的调试界面，可以查看外设寄存器、SFR（特殊功能寄存器）、内存、变量，并能将外设寄存器以类似STM32CubeMX的图形化方式展示，极其强大。
  3. Makefile Tools：如果你使用Makefile作为构建系统（我推荐的方式），这个插件可以让你在Vscode内直接运行make命令（如make all,make clean），并解析Makefile，在问题面板中显示编译错误和警告，点击可以直接跳转到对应代码行。
  4. Hex Editor：用于直接查看和编辑二进制文件（如.bin,.hex），在偶尔需要手动校验固件时很方便。

3.2 配置C/C++插件：解决红色波浪线的关键

安装完C/C++插件后，打开你的STM32项目文件夹，你可能会看到满屏的红色波浪线，提示“无法打开源文件stm32f1xx.h”等。这是因为插件不知道去哪里找头文件。我们需要配置c_cpp_properties.json文件。

在项目根目录下，创建一个.vscode文件夹，然后在里面创建c_cpp_properties.json文件。这个文件的配置是项目级的。一个针对STM32F1的配置示例如下：

{ "configurations": [ { "name": "STM32", "includePath": [ "${workspaceFolder}/**", // 工作区内所有文件 "D:/ARM_Toolchain/arm-gnu-toolchain-12.3.rel1-mingw-w64-i686-arm-none-eabi/arm-none-eabi/include", // 工具链系统头文件 "D:/ARM_Toolchain/arm-gnu-toolchain-12.3.rel1-mingw-w64-i686-arm-none-eabi/lib/gcc/arm-none-eabi/12.3.1/include", // GCC特定头文件 "${workspaceFolder}/Core/Inc", "${workspaceFolder}/Drivers/STM32F1xx_HAL_Driver/Inc", "${workspaceFolder}/Drivers/CMSIS/Device/ST/STM32F1xx/Include", "${workspaceFolder}/Drivers/CMSIS/Include" ], "defines": [ "USE_HAL_DRIVER", "STM32F103xB" // 根据你的芯片型号修改 ], "compilerPath": "D:/ARM_Toolchain/arm-gnu-toolchain-12.3.rel1-mingw-w64-i686-arm-none-eabi/bin/arm-none-eabi-gcc.exe", "cStandard": "gnu11", "cppStandard": "gnu++17", "intelliSenseMode": "gcc-arm", "configurationProvider": "ms-vscode.makefile-tools" } ], "version": 4 }

关键点解析：

  • includePath：这里列出了所有头文件所在的目录。前两项是工具链自带的系统头文件路径，你必须根据自己安装的实际路径进行修改！后面的路径是你的项目头文件路径。
  • defines：这里定义的宏，等同于在代码开头写的#define USE_HAL_DRIVER。这能帮助IntelliSense正确解析条件编译的代码。
  • compilerPath：这是最重要的设置之一。它告诉C/C++插件使用哪个编译器来获取系统包含路径和预定义宏。设置正确后，插件会自动填充很多系统路径，大大简化includePath的配置。同样，路径要修改为你自己的。
  • configurationProvider: 设置为"ms-vscode.makefile-tools"，可以让C/C++插件从Makefile Tools插件中获取一些构建配置信息，使两者协作更好。

配置保存后，红色波浪线通常会立刻消失，代码补全和跳转功能就正常了。

3.3 配置构建任务：让编译一键完成

虽然我们可以在终端里手动输入make，但在Vscode中集成构建任务会更方便。在.vscode文件夹下创建tasks.json文件：

{ "version": "2.0.0", "tasks": [ { "label": "Build Project", "type": "shell", "command": "make", "args": ["all", "-j4"], // “all”是Makefile中的目标，-j4表示4线程并行编译加速 "group": { "kind": "build", "isDefault": true }, "problemMatcher": ["$gcc"], // 使用GCC问题匹配器来捕获错误和警告 "detail": "使用 arm-none-eabi-gcc 编译项目" }, { "label": "Clean Build", "type": "shell", "command": "make", "args": ["clean"], "group": "build", "problemMatcher": [] }, { "label": "Flash with OpenOCD", "type": "shell", "command": "make", "args": ["flash"], "group": "build", "problemMatcher": [] } ] }

这样，你可以通过Vscode的终端菜单（Terminal -> Run Task...）选择运行这些任务，或者更常用的，使用快捷键Ctrl+Shift+B直接运行默认的构建任务（即Build Project）。编译过程中的错误和警告会显示在Vscode的“问题”面板中，点击即可跳转。

4. 图形化调试实战：使用Cortex-Debug进行源码级调试

命令行工具链和编辑环境配好后，最后的王冠就是调试。这是Vscode方案体验超越传统IDE的关键一步。

4.1 调试配置文件 launch.json 详解

在.vscode文件夹下创建launch.json文件，这是调试的配置文件。一个配合OpenOCD和Cortex-Debug插件的配置如下：

{ "version": "0.2.0", "configurations": [ { "name": "Cortex Debug (OpenOCD)", "cwd": "${workspaceFolder}", "executable": "${workspaceFolder}/build/my_stm32_project.elf", // 指向你的.elf文件 "request": "launch", "type": "cortex-debug", // 必须，指定使用Cortex-Debug插件 "servertype": "openocd", "serverpath": "openocd.exe", // 如果PATH配置正确，直接写名字即可 "configFiles": [ "interface/stlink.cfg", "target/stm32f1x.cfg" ], "searchDir": ["D:/Tools/openocd/share/openocd/scripts"], // OpenOCD脚本目录，帮助[find]命令 "runToEntryPoint": "main", // 启动后自动运行到main函数 "device": "STM32F103C8", // 你的设备型号，帮助Cortex-Debug加载SVD文件 "svdFile": "${workspaceFolder}/STM32F103xx.svd", // SVD文件路径，用于外设视图 // 以下是一些可选的优化设置 "showDevDebugOutput": false, // 减少调试控制台输出噪音 "armToolchainPath": "D:/ARM_Toolchain/arm-gnu-toolchain-12.3.rel1-mingw-w64-i686-arm-none-eabi/bin" // 指向工具链bin目录，可选 } ] }

关键配置解析：

  • executable: 必须指向编译生成的.elf文件，它包含调试符号信息。
  • servertype和serverpath: 指定使用OpenOCD作为调试服务器。
  • configFiles: 指定OpenOCD启动时使用的配置文件，和我们在命令行中使用的-f参数一样。
  • svdFile:这是实现外设图形化查看的关键！SVD（System View Description）文件是ARM公司定义的一种XML格式文件，描述了芯片所有外设寄存器的布局。你可以从ST官网下载对应芯片系列的包，里面通常包含.svd文件。将其放在项目目录并正确指向。配置后，在调试时Vscode的“外设寄存器”视图就能显示出来。

4.2 启动调试与视图运用

配置好launch.json后，在Vscode侧边栏选择“运行和调试”视图（Ctrl+Shift+D），在顶部的下拉框中选择“Cortex Debug (OpenOCD)”，然后按F5或点击绿色三角按钮开始调试。

此时，Cortex-Debug插件会自动启动OpenOCD，连接芯片，加载程序，并停在main函数入口（如果设置了runToEntryPoint）。你会看到：

  1. 调试工具栏：包含继续、单步、步入、步出等标准按钮。
  2. 变量窗口：显示局部和全局变量。
  3. 监视窗口：可以添加自定义变量或表达式进行监视。
  4. 调用堆栈：显示函数调用链。
  5. 外设寄存器窗口（Peripherals）：最强大的功能！这里会以树状结构列出芯片的所有外设（GPIOA, USART1, TIM2等）。点击任意外设，可以展开看到其所有寄存器及其每个位的名称和当前值（十六进制和二进制）。这比在Keil中查看寄存器直观得多。
  6. 内存查看窗口：可以查看任意地址的内存数据。
  7. 终端：会显示OpenOCD和GDB的交互信息。

你可以像在Keil/IAR中一样设置断点、单步执行、查看变量。当程序暂停时，外设寄存器视图会自动刷新，你可以直观地看到GPIO输出状态、定时器计数值、串口状态寄存器等是否如预期变化，极大地提升了调试效率。

4.3 常见调试问题排查

  1. OpenOCD连接失败：首先检查launch.json中的configFiles路径是否正确，或者searchDir是否指向了正确的OpenOCD脚本目录。最直接的方法是在终端手动运行openocd -f interface/stlink.cfg -f target/stm32f1x.cfg，看能否成功连接。如果命令行可以但Vscode不行，可能是路径或权限问题。
  2. 无法加载符号/找不到elf文件：检查launch.json中的executable路径是否正确，以及Makefile是否成功生成了.elf文件。
  3. 外设寄存器视图空白或报错：检查svdFile路径是否正确，以及SVD文件是否与你的芯片型号匹配。一个不匹配的SVD文件会导致解析失败。
  4. 调试时变量显示<optimized out>：这是因为编译器优化（如使用-Os）将某些变量优化掉了。在调试阶段，可以在Makefile的CFLAGS中暂时去掉优化选项（如-Og或-Os），改为-O0，并确保包含-g调试信息，重新编译后再调试。

5. 高效工作流搭建与进阶技巧

当基础环境跑通后，我们可以进一步优化工作流，提升开发体验。

5.1 与STM32CubeMX无缝协作

很多人习惯用STM32CubeMX生成初始化代码。如何将CubeMX生成的项目导入我们的Vscode环境？

  1. 生成项目：在CubeMX中，将“Toolchain / IDE”选项选为“Makefile”。这样CubeMX会生成一个完整的Makefile以及对应的源文件和头文件。
  2. 覆盖与整合：将CubeMX生成的所有文件复制到你的Vscode项目目录中。此时，你可以选择：
    • 直接使用CubeMX的Makefile：它通常已经配置得很好，你只需要根据前面章节调整Vscode的c_cpp_properties.json和launch.json即可。
    • 使用自己的Makefile：如果你有自己的Makefile模板，可以将CubeMX生成的Src，Inc，Drivers等目录复制过来，然后调整你自己Makefile中的C_SOURCES和C_INCLUDES路径，使其指向这些新文件。

最佳实践：在项目根目录下保留一个CubeMX的.ioc文件。当需要调整引脚或外设配置时，用CubeMX打开此文件，修改后重新生成代码，然后只覆盖Src和Inc中对应的用户代码文件（注意备份你自己的main.c等业务逻辑文件）。这样，硬件配置和软件逻辑可以较好地分离。

5.2 版本控制集成

这是Vscode的天然优势。在项目根目录初始化Git仓库（git init），Vscode的源代码管理视图会立即生效。你可以轻松地暂存更改、提交、查看差异。建议将以下内容添加到.gitignore文件中：

# 构建输出 build/ *.elf *.hex *.bin *.map *.lst # 编辑器临时文件 .vscode/launch.json .vscode/tasks.json .vscode/c_cpp_properties.json # 注意：此文件包含本地路径，建议忽略，团队中每人自己生成 .vscode/settings.json # CubeMX生成的文件（选择性忽略） # Drivers/ # .mxproject # *.ioc # 如果.ioc文件是项目核心，则不应忽略

对于c_cpp_properties.json这种包含绝对路径的文件，可以将其加入忽略列表，然后在仓库中存放一个模板文件（如c_cpp_properties.json.template），新成员克隆项目后复制并修改路径即可。

5.3 实用插件与设置推荐

  • GitLens：超级强大的Git增强插件，可以在代码行内显示最近提交信息、作者，方便追溯。
  • Error Lens：将错误和警告信息直接显示在代码行的末尾，更加醒目。
  • Todo Tree：扫描代码中的注释（如// TODO:，// FIXME:），并在侧边栏形成一个树状列表，方便管理待办事项。
  • Settings Sync：如果你在多台电脑上工作，可以用此插件通过GitHub Gist同步Vscode的所有设置和插件，实现环境一键还原。

在Vscode的设置（settings.json）中，可以添加一些针对嵌入式开发的优化：

{ "C_Cpp.default.configurationProvider": "ms-vscode.makefile-tools", "makefile.configureOnOpen": true, // 打开项目时自动配置Makefile Tools "files.associations": { "*.h": "c", // 将.h文件关联为C语言，以获得更好的智能感知 "stm32f1xx_hal.h": "c", "stm32f1xx_hal_conf.h": "c" }, "C_Cpp.autocomplete": "default", "C_Cpp.codeFolding": "enabled", "editor.formatOnSave": true, // 保存时自动格式化（需配置格式化工具如clang-format） "editor.codeActionsOnSave": { "source.organizeImports": true } }

5.4 性能与体验调优

对于大型项目，Vscode的C/C++智能感知可能会有些慢。可以尝试以下方法：

  1. 使用compile_commands.json：这是一个更精确的编译数据库文件，记录了每个文件确切的编译命令。你可以通过修改Makefile，使用bear或compiledb工具在编译时生成它。然后在c_cpp_properties.json中设置"compileCommands": "${workspaceFolder}/compile_commands.json"，并移除includePath和defines（因为它们会从这个文件读取）。这能提供最准确的智能感知。
  2. 限制搜索范围：在c_cpp_properties.json的includePath中，尽量不要使用${workspaceFolder}/**这种过于宽泛的匹配，而是明确列出必要的目录，可以减少索引文件的数量。
  3. 调整IntelliSense引擎：在Vscode设置中，将C_Cpp > Intelli Sense Engine设置为Default，对于大型项目，Tag Parser模式可能更快，但功能会受限。

从Keil切换到Vscode开发STM32，初期确实需要一些学习和配置成本，但一旦这套环境搭建完成，其带来的效率提升和舒适体验是传统IDE难以比拟的。你获得了一个高度自由、可定制、且与现代开发工具链无缝集成的编码环境。它迫使你更深入地理解编译、链接、调试的底层过程，这本身也是一种能力的提升。当你在Vscode中流畅地编写代码、一键编译、并通过强大的图形化界面洞察芯片内部的每一个寄存器状态时，你会觉得之前的“折腾”都是值得的。这套方法论不仅适用于STM32，经过简单的工具链和配置调整，完全可以扩展到其他Arm Cortex-M甚至RISC-V架构的MCU开发上，具备很强的通用性。