写在前头

    VSCode的用法和插件是月初参加ST官方北京站举办的线下培训中，厂家AE工程师给我们讲的，不同于已经很多人用的（并且一直在吵的）keil assistant什么的，用的是CMake编译，抛弃了原有的keil，IAR什么的，而且ST官方的东西，仿真器也暂时只能是ST-Link，可能老工程师会有些不习惯，而且没有接触过大型、多语言编程的项目的话会不适应VSCode C调试器这种调试方式。
    个人见识也是浅薄，但接触过一些开源项目，也做过无人机系统的编译，也是用makefile编译的，但具体采用哪种方式，还是看项目具体使用环境和开发团队的情况再定，因为一旦选择了CubeMX的生成方式后，再修改，很多配置就都不在了，需要重新配，这是很麻烦的。

---

• VSCode安装STM32 VS插件（同步检查是否安装了ARM Device Manager 插件）
  
  

• 安装STM32Cube CLT工具

• 使用STM32CubeMX正常配置工程，但是编译器选择CMake，生成工程

• 回到VSCode STM32插件Import建好的工程，当前窗口打开即可
  
  
  确认各项配置正确后，点击Import project 的 Actions
  
  按自己意愿，默认就行，新开也可
  
  打开工程后，会自动构建项目，打印类似下面的日志
  
  而这个Build和下面的Build功能一样，后面有需要手动构建的时候，点击下方时刻存在的Build按钮也可以。
  

注意！前提是没有在调试中，否则报错

• 若构建时提示分支选择，可以选择Debug分支进行编译。
  debug和release的区别请自行学习，原厂工程师培训的时候提到两个分支类似于git管理，是分别独立的，可以深入研究

• 接上板子和仿真器，官方NUCLEO板自带仿真器，下方确认是否有STLink，没有的到Device Manager中刷新看
  
  
  一路OK
  
  名字自己起，默认的话要考虑相同型号，多个仿真器的重复问题
  之后，是可以发现仿真器设备信息的
  
  在下方也会一直存在仿真器信息
  

• 完成用户代码后，利用VSCode自带调试功能进行编译烧录调试
  
  出现两个带ST-Link后缀的即可，我们用默认的Debug
  若跑起来后出现此情况，一般不会是代码问题
  
  考虑是STLink不支持CMake的编译方式，即版本过低，通过
  
  或者STM32CubePrg中的Firmware Update
  
  更新后再调试
  

• 编译后自动烧录进去debug模式，全速运行验证功能即可