📚 课程目录第2章开发环境搭建

2. 开发环境搭建：交叉编译工具链安装、IDE配置、调试器与仿真器设置

说实话，很多初学者在IoT开发上栽跟头，不是栽在代码逻辑上，而是栽在环境搭建上。工具链没配好、调试器连不上、仿真器不识别——这些坑我几乎都踩过一遍。今天咱们就把这套环境彻底捋顺。

我习惯把开发环境拆成三层来看：编译层（工具链）、编辑层（IDE）、调试层（调试器/仿真器）。三层打通了，后面移植协议栈和OTA升级才能跑得顺。

本章核心目标：在你的PC上搭建一套完整的IoT MCU开发环境，能编译、能烧录、能单步调试。以ARM Cortex-M系列（STM32/EFM32）和RISC-V系列（CH32/BL602）为例。

2.1 交叉编译工具链安装

交叉编译，说白了就是在PC上编译出MCU能跑的代码。PC是x86架构，MCU是ARM或RISC-V架构，指令集不同，所以需要专门的交叉编译器。

我个人习惯用GNU Arm Embedded Toolchain，开源、免费、社区活跃。对于RISC-V，则用Xpack RISC-V GCC或平头哥的C-Sky Toolchain。

2.1.1 ARM GCC 安装步骤（以Windows为例）

下载：从ARM官网或GitHub Releases下载gcc-arm-none-eabi-xxx-win32.zip。我建议选10.3-2021.10这个版本，稳定且兼容性好。
解压：解压到C:\arm-gcc，路径不要带中文和空格。
配置环境变量：将C:\arm-gcc\bin添加到系统PATH。
验证：打开命令行，输入arm-none-eabi-gcc --version，看到版本信息就对了。

我的经验：别用太新的GCC版本（比如12.x），有些老芯片的启动文件和新GCC不兼容。我踩过这个坑——编译通过，但芯片跑起来就死机，查了两天才发现是GCC版本问题。

2.1.2 RISC-V GCC 安装

RISC-V的工具链稍微麻烦点。以沁恒CH32V系列为例，官方提供的是MounRiver Studio，它内置了GCC。如果你喜欢命令行，可以单独下载xpack-riscv-none-embed-gcc。

MCU架构	推荐工具链	验证命令	备注
ARM Cortex-M	gcc-arm-none-eabi	`arm-none-eabi-gcc --version`	通用，支持STM32/EFM32/NXP
RISC-V (CH32)	xpack-riscv-none-embed-gcc	`riscv-none-embed-gcc --version`	沁恒官方推荐
RISC-V (BL602)	Xuantie-900-gcc	`riscv64-unknown-elf-gcc --version`	平头哥系列

2.2 IDE配置

IDE选什么？我见过有人用Keil，有人用IAR，有人用VS Code。我的建议是：做产品用Keil/IAR，做学习用VS Code。为什么？

Keil/IAR：编译优化好，调试稳定，但收费、跨平台差。
VS Code：免费、插件生态丰富、跨平台。配合Cortex-Debug插件，调试体验不输Keil。

我个人现在主力用VS Code。下面以VS Code为例，讲一下配置要点。

2.2.1 VS Code + Cortex-Debug 配置

安装VS Code，然后装这几个插件：
- C/C++（微软官方）
- Cortex-Debug（ARM调试）
- Makefile Tools（编译管理）
配置编译任务：在.vscode/tasks.json里定义Makefile调用。
配置调试启动：在.vscode/launch.json里指定调试器类型、芯片型号、SVDFile路径。

注意：Cortex-Debug需要配合J-Link GDB Server或OpenOCD使用。如果你用ST-Link，记得装ST-Link GDB Server。我曾经因为没装GDB Server，折腾了一下午连不上调试器。

2.2.2 一个典型的launch.json配置片段

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Cortex Debug",
            "type": "cortex-debug",
            "request": "launch",
            "servertype": "jlink",
            "cwd": "${workspaceRoot}",
            "executable": "./build/firmware.elf",
            "device": "STM32F407VG",
            "interface": "swd",
            "svdFile": "./STM32F407.svd"
        }
    ]
}

这里要注意svdFile——它描述了芯片的外设寄存器地址。没有它，调试时你看不到外设寄存器的值。很多新手忽略这个，结果调试时一脸懵。

2.3 调试器与仿真器设置

调试器是连接PC和MCU的桥梁。常见的调试器有：

J-Link：SEGGER出品，速度快、稳定、支持芯片多。我项目里90%的情况都用它。
ST-Link：ST官方调试器，便宜，但只支持STM32。
DAP-Link：ARM开源方案，淘宝几十块一个，够用。
CMSIS-DAP：很多开发板自带，比如NUCLEO系列。

2.3.1 接线与驱动

调试器一般用SWD接口（Serial Wire Debug），只需要4根线：

SWD引脚	功能	连接目标
SWDIO	数据线	MCU的SWDIO引脚
SWCLK	时钟线	MCU的SWCLK引脚
GND	地线	MCU的GND
3.3V	供电（可选）	MCU的VDD

避坑指南：我曾经在调试一个低功耗项目时，发现调试器一接上，MCU电流就多了2mA。后来才发现是调试器的3.3V和板子供电冲突了。解决办法：不接调试器的VCC线，只用SWDIO、SWCLK、GND三根线。

2.3.2 OpenOCD配置

如果你用DAP-Link或CMSIS-DAP，OpenOCD是首选。它开源、跨平台、支持多种调试器。一个典型的启动命令：

openocd -f interface/cmsis-dap.cfg -f target/stm32f4x.cfg

启动后，OpenOCD会在本地开一个GDB端口（默认3333），然后VS Code或命令行GDB连上去就能调试。

我的习惯：写一个debug.sh脚本，把OpenOCD启动命令和GDB连接命令写在一起。每次调试就运行这个脚本，省得每次敲一堆参数。

2.4 环境验证：从编译到烧录

环境搭好了，怎么验证？我一般走一个最小闭环：写一个LED闪烁程序，编译→烧录→运行。能亮，说明环境通了。

写代码：一个main.c，控制GPIO翻转。
写Makefile：指定交叉编译器、芯片型号、链接脚本。
编译：make，生成.elf和.hex。
烧录：用JLinkExe或openocd烧录。
调试：在VS Code里按F5，单步执行，看寄存器变化。

关键检查点：

arm-none-eabi-objdump -d firmware.elf 能看到反汇编，说明编译正确。
调试器能识别芯片IDCODE，说明SWD连接正常。
单步执行时PC指针能跑，说明复位向量表正确。

嗯，到这里，你的开发环境应该已经跑起来了。后面章节我们会基于这个环境，开始移植协议栈和做OTA升级。环境稳了，后面的事才稳。