企业官网建设流程全解析

1. 为什么我劝你尽早把STM32开发环境从MDK5迁到PlatformIO

搞STM32的兄弟大概率都有过这样的经历：新装一台电脑，第一件事就是翻出MDK5的安装包，然后开始找注册机、找License、找器件支持包，折腾大半天环境还没跑通。更别提MDK5那个上古时代的编辑器界面，代码补全基本靠猜，跳转定义经常失灵，用久了真的会让人怀疑自己是不是在2024年写代码。

我最早也是MDK5的重度用户，从F103一路做到F407，工程建了不下几十个。但后来项目里开始混用ESP32、GD32、甚至一些国产RISC-V芯片，MDK5的局限性就暴露得非常明显了——它只擅长ARM Cortex-M这一亩三分地，换个平台就得换一套工具链，学习成本和维护成本都在叠加。

后来我全面转向了VSCode + PlatformIO这套组合，说实话，回不去了。PlatformIO本质上是一个跨平台的嵌入式开发框架，它把编译器、调试器、烧录工具、库管理全部封装成一套统一的配置体系，你只需要在platformio.ini里写几行配置，剩下的它全帮你搞定。而VSCode作为编辑器，代码补全、跳转、Git集成、终端、远程开发这些能力都是现成的，体验比MDK5强了不止一个档次。

这篇文章我打算把STM32F103C8T6这颗经典芯片在PlatformIO下的完整开发环境搭建流程讲透，包括标准库的配置方式。为什么强调标准库？因为网上大部分PlatformIO教程默认用的是HAL库或者Arduino框架，但很多从MDK5转过来的朋友手里积累了大量标准库代码，直接扔掉太可惜。而且标准库对于F103这种资源有限的芯片来说，代码体积更小、执行效率更高，学习底层寄存器的逻辑也更直观。

这套方案适合谁？如果你手上有一块STM32F103C8T6最小系统板，想摆脱MDK5的束缚；或者你刚入门STM32，不想一上来就折腾License问题；又或者你同时玩多种芯片，想要一套统一的开发环境——那这篇内容应该能帮你省下不少试错时间。

2. 环境搭建前的整体思路与工具选型

2.1 为什么是PlatformIO而不是Keil或CubeIDE

先说说工具选型的逻辑。嵌入式开发环境的核心诉求无非几个：编译要快、调试要稳、库管理要方便、跨平台要支持。MDK5在编译和调试上确实成熟，但它的生态是封闭的，器件支持包要单独下载，库管理基本靠手动拷贝。STM32CubeIDE虽然免费，但它是基于Eclipse改的，那个卡顿感用过的人都懂，而且它强绑定HAL库，对标准库的支持并不友好。

PlatformIO的优势在于它的抽象层次设计得很合理。底层它调用的是arm-none-eabi-gcc这套开源工具链，编译质量完全没问题；中间层它用Python脚本管理构建流程，支持几千种开发板；上层它和VSCode深度集成，你几乎感觉不到自己在用一个"框架"。最关键的是，PlatformIO的库管理是声明式的，你在配置文件里写一行lib_deps，它自动帮你下载、解析依赖、配置头文件路径，这个体验是MDK5完全给不了的。

还有一个容易被忽略的点：PlatformIO天然支持多环境配置。同一个项目里，你可以定义多个env，比如一个用于F103C8T6，一个用于F407VET6，切换的时候只需要在VSCode底部点一下，不用改任何代码。这在做产品多版本维护的时候特别香。

2.2 标准库在PlatformIO下的定位

这里要澄清一个概念：PlatformIO官方对STM32的支持主要是通过stm32cube框架（也就是HAL库）和arduino框架。标准库并不在官方框架列表里，但这不代表不能用。标准库本质上就是一堆C文件和头文件，只要你把编译路径和宏定义配对，GCC照样能编。

我选择标准库的原因有三个。第一，代码体积可控。HAL库为了通用性加了很多抽象层，一个简单的GPIO翻转编译出来可能比标准库大好几倍，F103C8T6只有64KB Flash，省着点用很重要。第二，寄存器操作直观。标准库的函数命名和寄存器手册对应得很紧密，比如GPIO_SetBits(GPIOA, GPIO_Pin_0)，你一看就知道它在操作哪个寄存器的哪个位，对理解硬件很有帮助。第三，存量代码复用。网上大量F103的例程、项目、毕设代码都是基于标准库的，直接迁移过来能省很多事。

当然，标准库也有它的局限，比如ST官方已经停止更新了，新芯片支持不好。但对于F103C8T6这颗"国民芯片"来说，标准库的成熟度完全够用，甚至可以说是最合适的选择。

2.3 整体搭建流程概览

整个环境搭建可以拆成几个阶段：先装VSCode和PlatformIO插件，这是基础；然后准备标准库文件，这是核心；接着创建PlatformIO工程并配置platformio.ini，这是关键；最后写一个LED闪烁的测试程序验证环境，这是收尾。

听起来步骤不多，但每一步都有坑。比如PlatformIO默认会去下载HAL库，你得想办法让它用你的标准库；比如标准库的启动文件和链接脚本需要和PlatformIO的构建系统对接；再比如烧录方式的选择，ST-Link、串口ISP、DAPLink各有各的配置方法。这些细节我会在后面逐一展开。

3. VSCode与PlatformIO的安装配置实操

3.1 VSCode安装与基础插件配置

VSCode的安装没什么好说的，去官网下载对应系统的安装包，一路下一步就行。Windows下建议勾选"添加到PATH"，这样在终端里可以直接用code命令打开项目。安装完成后，我建议先做几件事：设置中文界面（如果你习惯中文的话）、配置字体和主题、开启自动保存。

插件方面，除了PlatformIO本身，我强烈建议装这几个：C/C++（微软官方的，提供代码补全和跳转）、GitLens（看代码提交历史很方便）、Better Comments（注释高亮）、Hex Editor（查看bin文件）。如果你还要写Python脚本处理数据，那Python插件也装上。

这里有个细节要注意：PlatformIO插件自带了一个C/C++的配置，它和微软官方的C/C++插件有时候会打架，导致头文件路径识别错误。我的做法是，在PlatformIO项目里以PlatformIO的配置为准，如果出现红色波浪线但能正常编译，那就不用管它，是IntelliSense的索引问题，重启一下VSCode或者重新加载窗口通常能解决。

3.2 PlatformIO插件安装与首次初始化

在VSCode的扩展面板里搜索"PlatformIO IDE"，认准那个蚂蚁图标的，安装。安装过程会稍微有点久，因为它要下载PlatformIO Core（一堆Python包）和工具链。国内网络环境下可能会卡在下载工具链这一步，这时候可以配置一下镜像源。

安装完成后，VSCode左侧会出现一个蚂蚁头图标，那就是PlatformIO的主页。第一次打开它会自动初始化，下载编译器和调试工具。这个过程可能需要几分钟到十几分钟，取决于网络。如果卡住了，可以打开终端手动执行pio pkg install看看具体卡在哪。

初始化完成后，你可以点击"PIO Home"里的"Platforms"标签，搜索"ST STM32"，确认这个平台已经安装。如果没有，点进去安装一下。这个平台包含了STM32系列的所有构建脚本和工具链配置，是后面创建工程的基础。

3.3 工具链与烧录工具的确认

PlatformIO安装STM32平台的时候，会自动下载arm-none-eabi-gcc工具链和openocd调试工具。你可以在~/.platformio/packages/目录下看到它们。Windows下路径通常是C:\Users\你的用户名\.platformio\packages\。

烧录工具方面，我手头用的是ST-Link V2，便宜好用，淘宝十几块钱一个。PlatformIO对ST-Link的支持很好，配置里写upload_protocol = stlink就行。如果你用的是串口ISP烧录，那需要配置upload_protocol = serial，并且要手动让芯片进入Bootloader模式（BOOT0接高电平，复位，然后BOOT0接回低电平）。DAPLink的话，upload_protocol = cmsis-dap。

提示：ST-Link的驱动在Windows下可能需要手动装一下，去ST官网下载ST-Link Utility或者STM32CubeProgrammer，安装后驱动就带上了。如果设备管理器里能看到ST-Link并且没有黄色感叹号，那就没问题。

4. STM32标准库在PlatformIO下的配置全流程

4.1 标准库文件的获取与目录结构规划

标准库的获取有几个途径。最正规的是去ST官网下载STM32F10x_StdPeriph_Lib_V3.5.0，这是最后一个版本，也是用得最广的。不过ST官网现在下载需要注册账号，稍微有点麻烦。另一个途径是从一些开源项目或者GitHub仓库里找，很多开发者把标准库整理好了放在上面。

下载下来之后，你会看到这样的目录结构：Libraries文件夹下有STM32F10x_StdPeriph_Driver（外设驱动）、CMSIS（内核相关）；Project文件夹下有各种例程和模板；Utilities下是评估板的驱动，一般用不到。

在PlatformIO项目里，我建议这样组织目录：

项目根目录/ ├── platformio.ini ├── src/ │ └── main.c ├── lib/ │ └── STM32F10x_StdPeriph_Driver/ │ ├── inc/ │ └── src/ ├── startup/ │ └── startup_stm32f10x_md.s ├── cmsis/ │ ├── core_cm3.h │ ├── stm32f10x.h │ └── system_stm32f10x.c └── ldscript/ └── stm32f103c8t6.ld

把标准库的inc和src放到lib目录下，PlatformIO会自动把lib下的所有源文件加入编译。CMSIS的核心头文件和系统文件单独放一个目录，启动文件和链接脚本也单独放。这样结构清晰，后面维护起来方便。

4.2 platformio.ini核心配置逐行解析

platformio.ini是整个项目的灵魂，所有构建、烧录、调试的配置都在这里。下面是我常用的一个配置模板，逐行解释：

[env:stm32f103c8t6] platform = ststm32 board = bluepill_f103c8 framework = stm32cube upload_protocol = stlink debug_tool = stlink build_flags = -D STM32F10X_MD -D USE_STDPERIPH_DRIVER -I cmsis -I lib/STM32F10x_StdPeriph_Driver/inc -I startup build_src_filter = +<../lib/STM32F10x_StdPeriph_Driver/src/*.c> +<../cmsis/system_stm32f10x.c> +<../startup/startup_stm32f10x_md.s> board_build.ldscript = ldscript/stm32f103c8t6.ld

platform = ststm32指定了平台，board = bluepill_f103c8是开发板型号，这个型号对应的是F103C8T6最小系统板。framework = stm32cube这里虽然写的是stm32cube，但我们通过build_flags和build_src_filter覆盖了默认的源文件选择，实际编译的是标准库。

build_flags里的-D STM32F10X_MD是告诉编译器这是中容量产品（F103C8T6属于中容量，64KB Flash），-D USE_STDPERIPH_DRIVER是启用标准库驱动。后面的-I是头文件搜索路径。

build_src_filter是关键，它告诉PlatformIO哪些源文件要参与编译。默认情况下PlatformIO会编译src目录下的文件，我们用+<../lib/...>把标准库的源文件加进来。注意路径是相对于src目录的。

board_build.ldscript指定链接脚本，这个脚本定义了Flash和RAM的起始地址、大小，以及各个段怎么摆放。F103C8T6的Flash是64KB，起始地址0x08000000；RAM是20KB，起始地址0x20000000。

4.3 启动文件与链接脚本的适配要点

启动文件是芯片上电后执行的第一段代码，它负责初始化堆栈指针、设置中断向量表、调用SystemInit、最后跳转到main。标准库的启动文件是汇编写的，文件名一般是startup_stm32f10x_md.s，md代表中容量。

这里有个坑：标准库的启动文件默认是给Keil或者IAR用的，语法和GCC不完全兼容。你需要找GCC版本的启动文件，或者自己改一下。GCC版本的启动文件在ST的例程里通常放在GCC目录下，文件名类似startup_stm32f10x_md.s，但内容不一样。

链接脚本也是类似的情况。Keil用的是.sct分散加载文件，GCC用的是.ld链接脚本。你需要一个针对F103C8T6的GCC链接脚本。这个脚本的核心内容是：

MEMORY { FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 64K RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 20K } SECTIONS { .text : { . = ALIGN(4); *(.isr_vector) *(.text) *(.rodata) . = ALIGN(4); _etext = .; } > FLASH .data : { . = ALIGN(4); _sdata = .; *(.data) . = ALIGN(4); _edata = .; } > RAM AT > FLASH .bss : { . = ALIGN(4); _sbss = .; *(.bss) . = ALIGN(4); _ebss = .; } > RAM }

这个脚本定义了Flash和RAM的布局，以及.text、.data、.bss三个段的摆放规则。.data段比较特殊，它的初始值存在Flash里，运行时拷贝到RAM，所以有AT > FLASH这个标记。

注意：链接脚本里的LENGTH一定要和芯片实际资源匹配。F103C8T6是64KB Flash、20KB RAM，如果你用的是F103C6T6，Flash只有32KB，那就要改成32K。写大了编译能过但烧录会出问题，写小了浪费资源。

4.4 中断向量表与系统时钟配置

中断向量表在启动文件里定义，它是一张函数指针数组，每个中断源对应一个入口。标准库的启动文件里已经定义好了所有中断的弱符号（weak symbol），你在C代码里重新定义一个同名函数，就会覆盖掉弱符号，这就是中断服务函数的注册方式。

系统时钟配置在system_stm32f10x.c里，默认的SystemInit函数会把时钟配到72MHz（使用外部8MHz晶振）。如果你板子上的晶振不是8MHz，或者你想用内部RC振荡器，就需要改这个文件。F103C8T6最小系统板一般都是8MHz晶振，所以默认配置就能用。

这里有个细节：system_stm32f10x.c里有一堆宏定义，比如SYSCLK_FREQ_72MHz，你需要确保对应的宏是打开的。默认情况下，这个文件会根据STM32F10X_MD这个宏来选择配置，所以只要build_flags里定义对了，一般不用改。

5. 从零创建工程到点亮第一颗LED

5.1 创建PlatformIO工程并导入标准库

在VSCode里按Ctrl+Shift+P打开命令面板，输入"PlatformIO: New Project"，然后填写工程名、选择开发板（搜索"bluepill"或者"STM32F103C8"）、选择框架（随便选一个，后面会改）。创建完成后，你会得到一个标准的PlatformIO工程结构。

接下来把前面准备好的标准库文件、CMSIS文件、启动文件、链接脚本按照4.1节的目录结构放进去。然后修改platformio.ini，填入4.2节的配置内容。保存后，PlatformIO会自动重新加载配置。

这时候你可以点一下VSCode底部的"Build"按钮（那个对勾图标），看看能不能编译通过。如果报错说找不到头文件，检查build_flags里的-I路径对不对；如果报错说找不到源文件，检查build_src_filter里的路径。路径问题是最常见的，多试几次就熟了。

5.2 编写LED闪烁测试程序

环境配好后，写一个最简单的LED闪烁程序验证。F103C8T6最小系统板上一般有一个板载LED，接在PC13上，低电平点亮。代码如下：

#include "stm32f10x.h" void Delay(__IO uint32_t nCount) { for(; nCount != 0; nCount--); } int main(void) { GPIO_InitTypeDef GPIO_InitStructure; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC, ENABLE); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_13; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOC, &GPIO_InitStructure); while (1) { GPIO_SetBits(GPIOC, GPIO_Pin_13); Delay(8000000); GPIO_ResetBits(GPIOC, GPIO_Pin_13); Delay(8000000); } }

这段代码的逻辑很直白：开GPIOC的时钟，配置PC13为推挽输出，然后在主循环里翻转电平。Delay函数是个简单的忙等待，8000000这个值是我实测在72MHz下大概能产生0.5秒左右的延时，具体值可以根据需要调整。

编译通过后，点"Upload"按钮烧录。如果ST-Link连接正常，你会看到板子上的LED开始闪烁。到这一步，环境就算跑通了。

5.3 编译、烧录与调试的完整验证

编译的时候注意看终端输出，PlatformIO会打印出编译了哪些文件、占用了多少Flash和RAM。F103C8T6的Flash是64KB，一个LED闪烁程序大概占用2-3KB，RAM占用1KB左右。如果你看到Flash占用突然变得很大，那可能是把不需要的标准库文件也编进去了，可以在build_src_filter里排除掉。

烧录的时候，ST-Link需要连接SWD接口：SWCLK、SWDIO、GND、3.3V四根线。有些板子还需要接复位线，但一般不用。烧录成功后，终端会显示"SUCCESS"。

调试方面，PlatformIO支持GDB调试。在VSCode里按F5启动调试，可以设断点、单步执行、查看变量和寄存器。这个体验比MDK5的调试器好很多，尤其是查看外设寄存器的时候，VSCode的界面更清爽。

实操心得：如果烧录时报"target not found"或者"no device found"，先检查ST-Link的驱动和连线。有时候是SWD速率太高导致通信不稳定，可以在platformio.ini里加一行upload_speed = 1000000把速率降下来试试。

6. 常见问题排查与避坑经验实录

6.1 编译报错类问题速查

编译类问题大部分是路径和宏定义的问题。我的经验是，先把build_flags和build_src_filter打印出来看看，确认路径拼写正确。PlatformIO的终端里可以用pio run -v查看详细的编译命令，能看到实际传给GCC的参数，对排查很有帮助。

6.2 烧录与连接类问题排查

烧录问题最常见的就是连不上芯片。先确认硬件：ST-Link的SWDIO接PA13，SWCLK接PA14，GND对接，3.3V对接。如果板子是从外部供电的，ST-Link的3.3V可以不接，但GND必须接。

软件方面，检查platformio.ini里的upload_protocol和debug_tool是否配置正确。如果用的是山寨ST-Link，有时候需要降速，加upload_speed = 500000试试。还有一种情况是芯片被读保护了，需要先解锁，用STM32CubeProgrammer连一下，解除读保护再烧录。

串口ISP烧录的话，需要把BOOT0接高电平，按复位，然后烧录，烧录完再把BOOT0接回低电平，再复位。这个流程比较繁琐，建议还是用ST-Link。

6.3 标准库特有的坑与解决方案

标准库在GCC下编译有几个特有的坑。第一个是__weak关键字，Keil下用__weak，GCC下要用__attribute__((weak))。标准库的GCC版本已经处理好了，但如果你从Keil工程移植代码，可能会遇到这个问题。

第二个是内联汇编的语法差异。Keil用的是ARMCC的内联汇编格式，GCC用的是AT&T格式，两者不兼容。标准库里用到内联汇编的地方主要是__disable_irq、__enable_irq这些，GCC版本的标准库已经用CMSIS的函数替代了，一般不用改。

第三个是printf重定向。Keil下用fputc重定向到串口，GCC下需要实现_write函数。这个在调试的时候很有用，可以打印变量值到串口助手。

int _write(int file, char *ptr, int len) { for (int i = 0; i < len; i++) { while (USART_GetFlagStatus(USART1, USART_FLAG_TXE) == RESET); USART_SendData(USART1, ptr[i]); } return len; }

避坑技巧：如果你从MDK5移植标准库工程到PlatformIO，建议先把启动文件和链接脚本换成GCC版本的，然后逐个文件编译，遇到报错再针对性修改。不要一次性全搬过来，那样报错太多会很难定位。

6.4 性能与资源占用的优化建议

F103C8T6的资源有限，优化很重要。编译的时候加-Os优化等级可以减小代码体积，在build_flags里加-Os就行。但要注意，-Os有时候会优化掉一些看似没用的代码，比如空的延时循环，这时候可以用__IO修饰变量，或者用__NOP()指令。

标准库的stm32f10x_xxx.c文件里有很多条件编译，只编译你用到的外设可以减小体积。比如你只用GPIO和USART，那就在build_src_filter里只加stm32f10x_gpio.c和stm32f10x_usart.c，其他的不加。但要注意依赖关系，比如USART可能依赖GPIO和RCC，这些也要加上。

RAM的优化主要是减少全局变量和大的数组。如果RAM不够用，可以把一些常量数据放到Flash里，用const修饰。栈的大小也可以在启动文件里调整，默认是1KB，如果用了递归或者大的局部数组，可能需要加大。

7. 从MDK5迁移到PlatformIO的实战建议

7.1 工程文件与源码的迁移策略

从MDK5迁移到PlatformIO，最省事的做法是保留原有的源码结构，只替换构建系统。具体来说，把MDK5工程里的.c和.h文件按功能分类，放到PlatformIO的src和lib目录下。启动文件和链接脚本换成GCC版本，然后配置platformio.ini。

MDK5的工程文件.uvprojx是XML格式的，里面记录了源文件列表、头文件路径、宏定义、编译选项等信息。你可以手动把这些信息翻译到platformio.ini里。源文件列表对应build_src_filter，头文件路径对应build_flags里的-I，宏定义对应-D，编译选项对应build_flags里的其他参数。

如果工程比较大，手动翻译太累，可以写个Python脚本解析.uvprojx，自动生成platformio.ini。这个脚本不难写，用xml.etree.ElementTree解析就行。我写过一版，大概一百多行，能处理大部分情况。

7.2 编译选项与宏定义的对应关系

MDK5的编译选项和GCC的编译选项不是一一对应的，需要做一些转换。比如MDK5的-O0对应GCC的-O0，-O1对应-O1，但-Ospace和-Otime在GCC里没有直接对应，一般用-Os和-O2替代。

宏定义方面，MDK5里常用的USE_STDPERIPH_DRIVER、STM32F10X_MD这些在GCC下是一样的，直接搬过来就行。但有些MDK5特有的宏，比如__CC_ARM，在GCC下要改成__GNUC__。标准库的代码里有很多这样的条件编译，GCC版本的标准库已经处理好了，但如果你自己写的代码里有，就需要改。

还有一个容易忽略的点：MDK5默认使用MicroLIB，这是一个精简版的C库，GCC下没有直接对应。如果你用了printf、malloc这些函数，GCC下需要链接newlib或者newlib-nano。PlatformIO默认用的是newlib-nano，体积小，适合嵌入式。

7.3 调试体验的差异与适应

MDK5的调试器功能很强大，尤其是外设寄存器查看和逻辑分析仪。PlatformIO的调试基于GDB和OpenOCD，功能上稍微弱一些，但日常调试够用。VSCode的调试界面可以查看变量、调用栈、断点，也可以查看寄存器，但外设寄存器的可视化不如MDK5直观。

不过PlatformIO有一个优势是多平台统一。你可以在同一个VSCode窗口里调试STM32、ESP32、甚至Linux程序，调试快捷键和界面都是一样的。这种一致性带来的效率提升，长期来看是值得的。

如果你确实需要查看外设寄存器，可以装一个VSCode插件叫"Cortex-Debug"，它提供了外设寄存器的可视化查看功能，配置一下SVD文件就能用。SVD文件在ST的官网或者CMSIS包里能找到，放到项目里，在launch.json里配置一下路径就行。

7.4 团队协作与版本管理的优势

从团队协作的角度看，PlatformIO比MDK5强太多了。MDK5的工程文件是二进制或者XML，Git diff基本看不出什么有用信息，合并冲突更是灾难。PlatformIO的platformio.ini是纯文本，所有配置一目了然，Git diff清清楚楚。

而且PlatformIO的库管理是声明式的，lib_deps里写清楚依赖的库和版本，团队成员拉下代码后，PlatformIO自动下载对应版本的库，不会出现"我这里能编译你那里编译不过"的情况。MDK5的库管理基本靠手动拷贝，版本混乱是常态。

还有一点，PlatformIO支持CI/CD集成。你可以在GitHub Actions里配置自动编译，每次提交代码自动跑一遍编译，确保没有破坏构建。这个在MDK5下很难做到，因为MDK5是商业软件，CI环境里装不了。

8. 我在这套环境上踩过的几个真实坑

第一个坑是启动文件的选择。我一开始用的是Keil版本的启动文件，编译报了一堆汇编语法错误。后来换成GCC版本的才通过。这个坑的本质是ARMCC和GCC的汇编语法不兼容，Keil的启动文件用的是ARMCC语法，GCC不认。

第二个坑是链接脚本的RAM大小。我一开始抄了一个F103C8T6的链接脚本，但那个脚本写的是20KB RAM，而我的板子实际上是20KB，没问题。但后来换了一块国产替代的板子，RAM只有20KB但链接脚本写的是20KB，编译能过但运行不稳定。后来查手册才发现，有些国产替代芯片的RAM实际可用大小和标称有差异，链接脚本要留点余量。

第三个坑是ST-Link的固件版本。我手头有一个很老的ST-Link V2，固件版本太旧，PlatformIO的OpenOCD不认。后来用STM32CubeProgrammer升级了固件才正常。如果你遇到连不上芯片的情况，先检查一下ST-Link的固件版本。

第四个坑是标准库的assert_param。标准库默认开启了参数断言，每个库函数入口都会检查参数合法性，这会增加代码体积和运行时间。在Release版本里可以关掉，在build_flags里加-D NDEBUG就行。但调试阶段建议开着，能帮你发现一些参数错误。

第五个坑是VSCode的IntelliSense。PlatformIO的头文件路径和VSCode的C/C++插件有时候不同步，导致代码里一堆红色波浪线但实际能编译。解决方法是打开命令面板，运行"C/C++: Edit Configurations (UI)"，在"Include Path"里手动加上标准库的路径。或者干脆忽略波浪线，只要编译能过就行。

这套环境我用了快两年，从F103到F407，从标准库到HAL库，从ST-Link到DAPLink，各种组合都试过。总体来说，PlatformIO+VSCode的体验是碾压MDK5的，尤其是对于需要多平台开发的场景。唯一的门槛是初始配置稍微复杂一点，但配好之后就是一劳永逸。如果你还在犹豫要不要迁移，我的建议是：花一个下午把环境搭起来，后面省下的时间绝对不止一个下午。