企业官网建设流程全解析

1. 从“还差活滴”说起：这个项目到底在做什么

“哟哟哟，咱们还差活滴”——这句话一看就不是什么正经技术文档的标题，更像是一个系列连载到第六篇时，作者自己给自己打气的一句调侃。但恰恰是这种口语化的表达，暴露了一个真实的嵌入式开发场景：前面五篇已经把STM32的工程骨架搭起来了，C++的语法糖也尝了个遍，外设驱动也跑通了几个，但整个项目还“差活”——差什么活？差调试、差验证、差把代码真正烧进板子里跑起来的那个闭环。

这个项目的核心，就是基于STM32微控制器，用C++语言进行嵌入式开发，并借助GDB与Renode构建一套可调试、可验证、可复现的开发流程。关键词里出现的STM32、嵌入式C++、GDB、Renode、VSCode，正好串成了一条完整的工具链：STM32是硬件平台，C++是开发语言，GDB是调试器，Renode是仿真器，VSCode是编辑器兼集成环境。

适合谁看？如果你已经能用C语言点灯、能看懂STM32的参考手册、知道什么是寄存器什么是中断，但一提到“C++写嵌入式”就心里没底，或者每次调试都靠printf大法、遇到HardFault就抓瞎，那这篇内容就是给你准备的。它不教你C++语法基础，也不教你STM32的GPIO怎么配置，它解决的是一个更实际的问题：当你的嵌入式项目从“能跑”进入“要调”的阶段，怎么用一套现代化的工具链把效率提上去，把问题定位清楚。

我自己的经历是，早期做STM32项目时，调试基本靠三样东西：LED闪烁、串口打印、以及反复烧录试错。一个时序问题可能要烧十几次板子才能定位，遇到偶发死机更是无从下手。后来接触到GDB配合OpenOCD的调试方式，再后来发现Renode可以在没有硬件的情况下仿真整个系统，整个开发节奏就完全不一样了。这篇内容就是把这套流程拆开揉碎，把每个环节的坑和技巧都摆出来。

2. 整体设计思路：为什么是C++加GDB加Renode这套组合

2.1 嵌入式C++的取舍逻辑

很多人对嵌入式C++有误解，觉得C++就是虚函数表、异常处理、动态内存分配这些“吃资源”的东西。但实际上，C++在嵌入式领域的价值恰恰在于它的零开销抽象能力。你可以用类来封装外设寄存器，用模板来做编译期计算，用constexpr来替代宏定义，这些特性在编译后生成的机器码和纯C几乎一样，但代码的可读性和可维护性提升了一个档次。

这个项目选择C++而不是纯C，核心考量有三点。第一，外设封装。STM32的寄存器操作在C语言里通常是一堆宏定义加位操作，写起来繁琐且容易出错。用C++的类模板可以把每个外设封装成一个对象，构造函数里完成时钟使能和初始配置，成员函数对应具体操作，代码意图一目了然。第二，编译期检查。C++的强类型和模板机制可以在编译阶段发现很多C语言里要到运行时才暴露的问题，比如引脚编号写错、寄存器位域赋值越界等。第三，代码复用。通过继承和模板特化，不同型号STM32之间的外设驱动可以共享大部分逻辑，只需要特化差异部分。

但这里有个关键取舍：必须关闭C++的运行时特性。异常处理（exception）和运行时类型识别（RTTI）在嵌入式环境里通常要禁用，因为它们的实现会引入额外的代码体积和运行时开销。动态内存分配也要谨慎，最好在初始化阶段完成所有对象的构造，运行期间不再new/delete。这些配置需要在编译器和链接器层面做好设置，后面会详细说。

2.2 GDB在嵌入式调试中的角色定位

GDB在这个项目里扮演的是“最终裁判”的角色。不管你在VSCode里写代码多顺手，不管Renode仿真跑得多流畅，最终代码要烧进真实的STM32芯片里，GDB就是你和芯片之间唯一的对话通道。

嵌入式GDB调试和桌面GDB调试最大的区别在于目标连接方式。桌面程序调试时，GDB直接fork一个子进程就能控制；嵌入式场景下，GDB需要通过一个“调试探针”（比如ST-Link、J-Link、DAPLink）连接到芯片的调试接口（SWD或JTAG），中间还要经过OpenOCD或pyOCD这样的“翻译层”。这个链路是：GDB客户端 → OpenOCD服务 → 调试探针硬件 → SWD接口 → STM32内核。每一层都可能出问题，每一层都有自己的配置参数。

这个项目里GDB的核心用途有三个：断点调试（在特定函数或行号处暂停，查看变量和寄存器状态）、内存检查（直接读取Flash或RAM中的内容，验证数据是否正确写入）、故障回溯（当程序进入HardFault时，通过GDB查看调用栈和故障寄存器，定位问题源头）。这三个用途覆盖了嵌入式开发中80%的调试场景。

2.3 Renode的仿真价值与适用边界

Renode是一个开源的嵌入式系统仿真器，它可以在PC上模拟整个STM32微控制器的行为，包括CPU内核、外设寄存器、中断控制器、甚至部分外设的时序行为。这意味着你可以在没有物理硬件的情况下运行和调试STM32程序。

这个项目引入Renode的动机很实际：硬件资源有限，团队协作需要统一的验证环境。一块STM32开发板几十块钱不贵，但如果团队有五个人，每人一套外设模块（OLED、传感器、电机驱动），成本就上去了。更麻烦的是，硬件环境不一致会导致“我这里能跑你那里不行”的扯皮。Renode提供了一个标准化的虚拟硬件平台，所有人跑的是同一套“芯片”，行为完全一致。

但Renode不是万能的。它的仿真精度有限，特别是涉及模拟信号、精确时序、外部干扰的场景，仿真结果和真实硬件可能有差异。所以这个项目的策略是：Renode用于逻辑验证和早期开发，真实硬件用于最终确认和性能测试。两者不是替代关系，而是互补关系。

2.4 VSCode作为统一入口的整合逻辑

VSCode在这个项目里的定位是“驾驶舱”。你不需要在多个终端窗口之间来回切换，所有操作——编辑代码、编译、烧录、调试、查看外设寄存器——都可以在VSCode一个界面里完成。这靠的是VSCode的任务系统和调试配置。

具体来说，通过.vscode/tasks.json定义编译和烧录任务，通过.vscode/launch.json定义GDB调试配置，再配合Cortex-Debug插件，就能实现“按F5自动编译、烧录、附加调试器、停在main函数”的一键操作。这个体验在纯命令行环境下需要敲好几条命令才能达到，而在VSCode里就是一次按键的事。

3. 核心细节解析：工具链配置中的关键参数与避坑点

3.1 STM32的C++工程编译配置

用C++开发STM32，第一步是把编译器的C++支持打开，同时把不必要的运行时特性关掉。以arm-none-eabi-gcc为例，关键编译选项如下：

arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 \ -std=c++17 -fno-exceptions -fno-rtti -fno-threadsafe-statics \ -ffunction-sections -fdata-sections -Os -Wall -Wextra \ -c src/main.cpp -o build/main.o

这里每个参数都有讲究。-mcpu=cortex-m4指定目标内核，-mthumb启用Thumb指令集（Cortex-M只支持Thumb），-mfloat-abi=hard和-mfpu=fpv4-sp-d16启用硬件浮点单元（如果你的芯片有FPU的话）。-std=c++17选择C++标准版本，-fno-exceptions和-fno-rtti禁用异常和RTTI，-fno-threadsafe-statics禁用局部静态变量的线程安全保护（裸机环境不需要）。-ffunction-sections和-fdata-sections让每个函数和数据段独立成节，配合链接器的--gc-sections可以剔除未使用的代码，减小固件体积。

链接阶段的参数同样关键：

arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 \ -T STM32F407VGTx_FLASH.ld -Wl,--gc-sections -Wl,-Map=build/output.map \ --specs=nano.specs --specs=nosys.specs \ build/*.o -o build/firmware.elf

-T指定链接脚本，这个文件定义了Flash和RAM的起始地址、大小、以及各个段（.text、.data、.bss）的放置位置。--gc-sections配合前面的-ffunction-sections做死代码消除。--specs=nano.specs使用newlib-nano（精简版C库），--specs=nosys.specs提供空实现的系统调用桩，避免链接时找不到_write、_sbrk等函数。

注意：如果你在C++代码里使用了std::vector或std::string，链接阶段可能会报错找不到operator new。解决办法是提供一个简单的内存池分配器，或者直接避免在嵌入式代码中使用这些动态容器。我个人的习惯是，运行期间绝不动态分配内存，所有容器都用固定大小的数组或自定义的静态容器替代。

3.2 GDB与OpenOCD的联调配置

GDB要连接到STM32，中间需要OpenOCD做协议转换。OpenOCD的配置文件通常包含两部分：接口配置（用哪种调试探针）和目标配置（芯片型号）。以ST-Link和STM32F407为例：

openocd -f interface/stlink.cfg -f target/stm32f4x.cfg

这条命令启动后，OpenOCD会监听3333端口（GDB Server）和4444端口（Telnet控制台）。然后GDB通过target remote localhost:3333连接上去。

在VSCode的launch.json里，对应的配置大概是这样的：

{ "name": "STM32 Debug (OpenOCD)", "type": "cortex-debug", "request": "launch", "servertype": "openocd", "cwd": "${workspaceRoot}", "executable": "build/firmware.elf", "device": "STM32F407VG", "configFiles": [ "interface/stlink.cfg", "target/stm32f4x.cfg" ], "svdFile": "STM32F407.svd", "runToMain": true, "preLaunchTask": "build" }

这里有几个关键点。svdFile指定了芯片的SVD文件，这个文件描述了所有外设寄存器的地址和位域定义，有了它，VSCode的调试界面里可以直接查看外设寄存器的值，不用手动去算地址。runToMain让调试器在连接后自动运行到main函数暂停，省去了手动下断点的麻烦。preLaunchTask指定调试前自动执行编译任务，保证调试的是最新代码。

实操心得：OpenOCD的版本和调试探针的固件版本要匹配。我曾经遇到过ST-Link固件太旧导致OpenOCD识别不到目标芯片的情况，升级ST-Link固件后问题解决。另外，如果用的是山寨ST-Link，可能会遇到连接不稳定、偶尔掉线的问题，建议在OpenOCD配置里加上adapter speed 1000降低SWD时钟频率，牺牲一点烧录速度换取稳定性。

3.3 Renode的STM32平台描述文件

Renode通过.repl文件（平台描述文件）来定义一个虚拟的STM32系统。这个文件描述了CPU型号、内存布局、外设实例及其地址映射。以STM32F407为例，一个简化的平台描述如下：

uart4: UART.STM32_UART @ sysbus 0x40004C00 frequency: 84000000 -> nvic@52 gpioPortD: GPIOPort.STM32_GPIOPort @ sysbus 0x40020C00 [0-15] -> nvic@EXTI15_10

这段描述定义了一个UART4外设，基地址0x40004C00，时钟频率84MHz，中断号52；以及GPIO端口D，基地址0x40020C00，外部中断线映射到NVIC的EXTI15_10中断。

在Renode的启动脚本（.resc文件）里，加载平台描述、加载固件、启动仿真的流程如下：

mach create "stm32f407" machine LoadPlatformDescription @platforms/boards/stm32f4_discovery.repl sysbus LoadELF @build/firmware.elf showAnalyzer uart4 start

showAnalyzer uart4会打开一个UART分析窗口，实时显示串口输出的内容。这对于没有物理串口线的情况特别方便，相当于把串口终端集成到了仿真环境里。

注意：Renode的仿真精度取决于平台描述文件的完善程度。官方提供的STM32平台描述覆盖了常用外设，但某些高级功能（比如DMA的复杂传输模式、ADC的精确采样时序）可能仿真不完整。如果你的项目依赖这些功能，建议在Renode里做逻辑验证，最终行为还是要以真实硬件为准。

3.4 VSCode的C++开发环境配置

VSCode本身只是一个编辑器，要变成STM32的C++ IDE，需要安装几个关键插件：C/C++（提供代码补全和跳转）、Cortex-Debug（提供GDB调试集成）、ARM Assembly（查看反汇编代码）。另外，c_cpp_properties.json里要配置好头文件搜索路径和宏定义，否则代码补全会报一堆红线。

{ "configurations": [ { "name": "STM32", "includePath": [ "${workspaceFolder}/**", "${workspaceFolder}/Drivers/CMSIS/Include", "${workspaceFolder}/Drivers/STM32F4xx_HAL_Driver/Inc" ], "defines": [ "STM32F407xx", "USE_HAL_DRIVER" ], "compilerPath": "/usr/bin/arm-none-eabi-gcc", "cStandard": "c11", "cppStandard": "c++17", "intelliSenseMode": "gcc-arm" } ] }

compilerPath指向交叉编译器，这样VSCode的IntelliSense就能用正确的编译器内置宏来解析代码。defines里的宏定义要和编译时保持一致，否则条件编译的代码块可能显示不正确。

4. 实操过程：从零搭建一个可调试的STM32 C++工程

4.1 工程目录结构与文件组织

一个清晰的项目结构能省去很多后续的麻烦。我习惯的布局是这样的：

project/ ├── .vscode/ │ ├── launch.json │ ├── tasks.json │ └── c_cpp_properties.json ├── Core/ │ ├── Inc/ │ │ ├── main.hpp │ │ └── stm32f4xx_hal_conf.h │ └── Src/ │ ├── main.cpp │ ├── system_stm32f4xx.c │ └── stm32f4xx_hal_msp.c ├── Drivers/ │ ├── CMSIS/ │ └── STM32F4xx_HAL_Driver/ ├── Middlewares/ ├── build/ ├── STM32F407VGTx_FLASH.ld └── Makefile

Core/Src/main.cpp是C++的主入口，Drivers下放ST官方的HAL库和CMSIS头文件，build是编译输出目录，链接脚本放在根目录。这个结构的好处是源文件和生成文件分离，清理工程时直接删build目录就行，不会误删源码。

4.2 编写第一个C++外设类

以GPIO点灯为例，用C++封装一个LED类：

// led.hpp #pragma once #include "stm32f4xx_hal.h" template <GPIO_TypeDef* Port, uint16_t Pin> class Led { public: static void init() { GPIO_InitTypeDef cfg = {}; cfg.Pin = Pin; cfg.Mode = GPIO_MODE_OUTPUT_PP; cfg.Pull = GPIO_NOPULL; cfg.Speed = GPIO_SPEED_FREQ_LOW; HAL_GPIO_Init(Port, &cfg); } static void toggle() { HAL_GPIO_TogglePin(Port, Pin); } static void set() { HAL_GPIO_WritePin(Port, Pin, GPIO_PIN_SET); } static void reset() { HAL_GPIO_WritePin(Port, Pin, GPIO_PIN_RESET); } }; using LedGreen = Led<GPIOD, GPIO_PIN_12>; using LedOrange = Led<GPIOD, GPIO_PIN_13>;

这个类模板把端口和引脚作为模板参数，编译期就确定了具体操作哪个寄存器，没有任何运行时开销。init()、toggle()这些方法都是静态的，不需要实例化对象，调用方式就是LedGreen::toggle()，和直接调HAL函数一样直接，但语义更清晰。

在main.cpp里使用：

#include "led.hpp" int main() { HAL_Init(); SystemClock_Config(); LedGreen::init(); LedOrange::init(); while (true) { LedGreen::toggle(); HAL_Delay(500); LedOrange::toggle(); HAL_Delay(500); } }

4.3 用GDB定位一个HardFault问题

假设程序运行一段时间后进入了HardFault_Handler，传统的做法是在Handler里加个死循环，然后靠LED判断。但有了GDB，你可以直接看到故障现场。

首先在launch.json里配置好调试环境，启动调试后，在HardFault_Handler处下断点。当程序停在Handler里时，在GDB控制台输入：

(gdb) info registers

查看CFSR（Configurable Fault Status Register）、HFSR（HardFault Status Register）、BFAR（BusFault Address Register）等故障寄存器。比如CFSR的IMPRECISERR位为1，说明发生了不精确的总线错误，通常是访问了非法地址。BFAR里会记录出错的地址。

然后通过backtrace命令查看调用栈：

(gdb) bt #0 HardFault_Handler () at stm32f4xx_it.c:78 #1 <signal handler called> #2 0x08001234 in SomeFunction (ptr=0x0) at main.cpp:45

如果调用栈显示SomeFunction在操作一个空指针，问题就定位了。但有时候调用栈会被破坏，bt只能看到Handler本身。这时候需要手动分析栈帧：在Cortex-M上，异常发生时硬件会自动把R0-R3、R12、LR、PC、xPSR压入当前栈（MSP或PSP）。通过info registers查看MSP的值，然后用x/8xw $msp读取栈内容，找到压入的PC值，就能知道异常发生时程序执行到了哪里。

实操心得：在HardFault_Handler的入口处加一句__asm volatile("bkpt #0")，可以让GDB在进入Handler的第一时间中断，避免因为Handler里的其他操作破坏栈帧。另外，在编译时加上-fno-omit-frame-pointer可以保留帧指针，让backtrace更可靠，代价是稍微增加一点代码体积和运行时开销。

4.4 Renode仿真运行与GDB远程调试

Renode支持GDB远程调试，这意味着你可以在Renode里运行固件，同时用GDB连接上去下断点、查看变量。启动Renode并开启GDB Server的命令如下：

mach create "stm32" machine LoadPlatformDescription @platforms/boards/stm32f4_discovery.repl sysbus LoadELF @build/firmware.elf machine StartGdbServer 3333 start

然后在VSCode的launch.json里把servertype改成external，gdbTarget指向localhost:3333，就能像调试真实硬件一样调试Renode里的仿真程序。

这个流程的最大价值在于早期开发阶段。硬件还没到货、或者硬件被同事借走了、或者你只是想验证一段纯逻辑代码，Renode都能让你先把代码跑起来。等硬件到位后，只需要把调试目标从Renode切换到OpenOCD，代码本身不需要任何修改。

4.5 编译、烧录、调试的一键化任务配置

在.vscode/tasks.json里定义两个任务：build和flash。

{ "version": "2.0.0", "tasks": [ { "label": "build", "type": "shell", "command": "make", "args": ["-j4"], "group": { "kind": "build", "isDefault": true }, "problemMatcher": ["$gcc"] }, { "label": "flash", "type": "shell", "command": "openocd", "args": [ "-f", "interface/stlink.cfg", "-f", "target/stm32f4x.cfg", "-c", "program build/firmware.elf verify reset exit" ], "dependsOn": ["build"] } ] }

build任务调用Makefile编译工程，flash任务先依赖build，然后用OpenOCD把固件烧进芯片并复位运行。在VSCode里按Ctrl+Shift+B执行默认构建任务，按Ctrl+Shift+P输入Run Task选择flash任务即可烧录。

5. 常见问题与排查技巧实录

5.1 GDB连接失败问题速查

5.2 C++与C混合编译的链接问题

STM32的HAL库是C语言写的，在C++文件里包含HAL头文件时，必须用extern "C"包裹，否则链接时会报“undefined reference toHAL_Init”之类的错误。标准做法是在HAL头文件里已经有条件编译：

#ifdef __cplusplus extern "C" { #endif // HAL函数声明 #ifdef __cplusplus } #endif

但如果你自己写的C语言模块没有加这个保护，就需要在C++文件里手动包裹：

extern "C" { #include "my_c_module.h" }

另一个常见问题是全局对象的构造函数。C++的全局对象会在main之前构造，但此时HAL库可能还没初始化，时钟也没配置。如果构造函数里调用了HAL_Delay或操作了外设，行为是不可预期的。解决办法是避免定义需要初始化的全局对象，或者使用“构造后初始化”模式：全局对象只做简单的数据成员初始化，真正的外设配置放在main里显式调用。

5.3 Renode仿真中的时序偏差处理

Renode的仿真时间线和真实时间不是严格对应的。默认情况下，Renode会尽可能快地执行指令，而不是按真实时钟频率。这会导致依赖精确延时的代码在仿真中行为异常。比如HAL_Delay(1000)在真实硬件上等1秒，在Renode里可能瞬间就过去了。

解决办法是在Renode脚本里启用实时同步：

emulation SetGlobalQuantum "0.0001" emulation SetGlobalAdvanceImmediately false

SetGlobalQuantum设置每个时间片的大小（单位秒），SetGlobalAdvanceImmediately false让Renode按照虚拟时间推进，而不是尽可能快地执行。这样仿真速度会慢下来，但时序行为更接近真实硬件。

注意：即使启用了实时同步，Renode的时序精度也有限，特别是微秒级的延时。如果你的代码依赖__NOP()循环做精确延时，仿真结果和真实硬件会有明显差异。这类代码建议在真实硬件上验证。

5.4 VSCode IntelliSense报错的常见原因

IntelliSense报红但编译能通过，通常是因为c_cpp_properties.json里的includePath和defines与Makefile不一致。比如Makefile里定义了STM32F407xx，但c_cpp_properties.json里没定义，那么#ifdef STM32F407xx包裹的代码在编辑器里就是灰色的，相关的类型和函数也找不到定义。

另一个常见问题是编译器路径不对。compilerPath必须指向arm-none-eabi-gcc的完整路径，如果只写arm-none-eabi-gcc，VSCode可能找不到。在Linux下可以用which arm-none-eabi-gcc确认路径，在Windows下通常是C:\Program Files (x86)\GNU Arm Embedded Toolchain\...\bin\arm-none-eabi-gcc.exe。

如果IntelliSense还是不正常，可以尝试在VSCode命令面板里执行C/C++: Reset IntelliSense Database，然后重新打开文件。

5.5 固件体积优化的几个实用手段

C++模板和HAL库容易导致固件体积膨胀。除了前面提到的-ffunction-sections加--gc-sections，还有几个手段可以试试。

用-Os而不是-O2。-Os优先优化代码体积，对于Flash紧张的芯片（比如STM32F103C8只有64KB Flash）很有必要。实测一个简单的HAL工程，-Os比-O2能省10%到15%的Flash。

裁剪HAL库。在stm32f4xx_hal_conf.h里把不需要的外设模块注释掉，比如不用CAN、不用USB、不用SDIO，就把对应的HAL_XXX_MODULE_ENABLED宏注释掉。这样链接时就不会把那些模块的代码链进来。

避免使用printf浮点格式化。newlib-nano默认不支持浮点格式化，如果代码里用了printf("%f", x)，链接器会拉入一大坨浮点格式化代码，Flash占用可能增加几KB。解决办法是用整数格式化替代，或者自己写一个轻量的浮点转字符串函数。

检查map文件。编译后生成的.map文件里列出了每个函数和变量占用的空间，按大小排序就能找到“体积大户”。我经常在map文件里发现一些意想不到的函数被链接进来了，比如某个库函数只是因为一处调用就被整个拉进来，这时候可以考虑自己实现一个精简版替代。

5.6 调试时变量被优化看不到的解决办法

GDB调试时经常遇到“optimized out”的提示，变量值看不到。这是因为编译器优化后，变量可能被放到寄存器里、被常量传播替代、或者生命周期被缩短。解决办法有几个层次。

编译时加-g3而不是-g。-g3包含宏定义信息，调试体验更好。对关键文件单独降低优化等级。在Makefile里对需要重点调试的文件用-O0，其他文件保持-Os。使用volatile关键字。对于需要观察的变量，加volatile阻止编译器优化它。但volatile会影响性能，只建议在调试阶段临时加，正式发布时去掉。

最彻底的办法是调试版本用-O0 -g3编译，发布版本用-Os编译，两套配置分开。在Makefile里通过DEBUG=1这样的变量来控制。

6. 从能跑到好用：一些个人体会

这套工具链搭起来之后，最大的感受是调试从“猜”变成了“看”。以前遇到问题，第一反应是“可能哪里不对”，然后加打印、改代码、重新烧录，一轮下来十分钟过去了。现在遇到问题，第一反应是“下个断点看看”，GDB连上去，变量值、寄存器状态、调用栈一目了然，大部分问题几分钟内就能定位。

Renode的价值在项目初期特别明显。硬件还没到的时候，我可以先把外设驱动框架写好，在Renode里验证逻辑，等硬件到了直接烧录，一次通过的概率高很多。但Renode不能完全替代硬件，特别是涉及模拟外设和精确时序的场景，最终还是要上真板子测。

C++在嵌入式里的甜头是代码组织更清晰了。以前一堆全局变量和宏定义，现在用类和模板封装起来，每个外设的职责边界很清楚。但也要克制，不要为了用C++而用C++，虚函数、异常、动态内存这些能不用就不用，保持代码的“嵌入式友好性”。

最后分享一个我常用的调试技巧：在main函数开头加一句__asm volatile("bkpt #0")，配合runToMain配置，调试器会在连接后直接停在main入口，省去了手动下断点的步骤。等调试稳定后把这句删掉就行。这个技巧在频繁烧录调试的阶段特别省时间。