GD32H759+RT-Thread环境搭建：Cortex-M7开发板点灯实战

GD32H759 RT-Thread 这套组合最近在工控圈里讨论度确实上来了。Cortex-M7 内核、主频拉到 600MHz再加上 RT-Thread 这种自带设备框架和软件包生态的国产 RTOS做中小型工业控制器、数据采集网关、人机交互面板我觉得比传统裸机方案要省心得多。这篇是系列的第 0 篇不玩虚的就是把环境从零搭起来让板子上的 LED 按我们的想法亮起来。这篇文章适合刚入手 GD32H759 开发板、想从裸机开发转到 RTOS 开发、或者已经在用 RT-Thread 但想换个高性能片子做项目的朋友。看完你就能拥有一个可以跑 RT-Thread 的工程骨架后面再往里头加网口、Modbus、模拟量采集都不会慌。1. 实战目标与方案选型思路1.1 为什么选 GD32H759 这块芯片我在选型的时候其实同时对比过 STM32H743、GD32F4 系列和 GD32H759。STM32H7 性能确实强生态也成熟但这两年供货和价格波动让我有点顾虑GD32F4 用起来稳定可遇到需要同时跑图形界面、以太网和多个采集任务的场景运算余量总觉得不够。GD32H759 属于兆易创新的高性能产品线几个点比较戳我一是 Cortex-M7 内核带双精度浮点主频 600MHz应付 PID 运算、FFT、简单图像处理都不成问题二是片内资源够厚大容量 Flash 和 SRAM 意味着跑完整版 RT-Thread 加上一堆中间件内存也不会捉襟见肘三是外设接口很全以太网 MAC、USB、CAN-FD、多路 ADC/DAC、高级定时器都有工业现场常用的通信接口基本覆盖了。另外它还带硬件加解密和图形加速相关的特性后续做数据安全或者 HMI 方案时能省不少事。我特意说一句选型这事没有绝对的最优关键是匹配你的应用场景。如果你只是做传感器数据采集然后走串口上报GD32F4 甚至 GD32E 系列就够用但如果你预判后续要上以太网、要跑协议栈、要做人机交互GD32H759 这个级别可以让你少换一次平台。1.2 为什么选 RT-Thread 而不是裸机或其它 RTOS裸机开发在简单项目里很直观main 函数里一个 while(1) 轮询就完事。可一旦任务多了串口要收发、屏幕要刷新、按键要扫描、数据要存储轮询方式会带来两个头疼的问题实时性没法保证代码耦合越来越严重。这时候就需要一个 RTOS 来管理任务调度和资源同步。RTOS 也不是只有 RT-ThreadFreeRTOS 用的人也很多。FreeRTOS 轻量、简单但坦白讲它更像一个调度内核设备驱动、文件系统、网络协议栈这些都要自己另外搭。RT-Thread 的中文文档和软件包生态是我比较看重的设备驱动框架抽象了 GPIO、UART、SPI、I2C 这些接口驱动和应用可以解耦FinSH 控制台让调试变得非常直接设备状态、线程运行情况敲命令就能查软件包仓库里还有各种现成组件像各版本 Modbus 协议栈、网络库、文件系统用 menuconfig 或者 RT-Thread Settings 点选就能集成进来省下的开发时间相当可观。对于工控项目来说RT-Thread 还提供了一些面向可靠性设计的机制比如信号量、互斥量、消息队列、事件集处理多任务同步和互斥时比裸机里用全局变量硬扛要安全得多。而且它本身就出自国内开源社区技术资料和支持渠道都比较接地气。1.3 整体工程蓝图第 0 篇在整个系列里的位置我把这个系列规划成一条循序渐进的路环境搭建和点灯是第 0 篇先把工具链和工程框架跑通确认开发板、调试器、编译环境、下载链路都没问题。第三步是串口和 FinSH 的进阶使用把调试入口打通。再往后是定时器、PWM、外部中断、ADC/DAC 这些基础外设。等这些基础打牢就能进入更有工控味道的阶段以太网通信、Modbus RTU/TCP 协议栈集成、数据采集与远程上报、看门狗与可靠性设计。第 0 篇的目标很聚焦创建一个可以编译下载的 RT-Thread 工程用最简单的方式操作一次 GPIO验证整个开发链路通畅。点灯不是目的目的是通过点灯把流程走通后续所有章节都会基于这个工程继续迭代。所以我后面会把每一步操作写得比较细包括容易踩的坑尽量让你少走弯路。2. 环境搭建全流程2.1 硬件准备板子到手先备齐这些东西工欲善其事必先利其器。开发 GD32H759我建议你准备这些硬件GD32H759 开发板或核心板我使用的是官方 EVAL 板带有板载调试器如果你的是核心板可能还需要额外配一个调试器。调试器最常见的是 CMSIS-DAP 和 J-Link。板载 DAP 的好处是省事一条 USB 线同时供电和调试独立调试器灵活性更高可以调试外部目标板。USB 转串口模块或者开发板上已经集成了 USB 转串口芯片也行串口是 RT-Thread FinSH 的主要通道调试必备。若干杜邦线和 LED 模块点灯实验需要外接 LED 的话可以用。万用表排查供电异常、引脚短路这类问题时的必备工具。我说一个比较务实的经验调试器与目标板之间的连接线越短越好特别是 SWDIO、SWCLK 这两根线长了容易受干扰导致下载失败。如果遇到“连接不上调试器”的问题往往不是调试器坏了而是线太长或者接触不良。2.2 软件工具链清单与安装要点软件这一块核心是这四个第一Keil MDK。GD32 系列的开发官方支持 MDK 和 GCC我用 MDK 比较多主要是工程管理方便调试界面熟悉。需要注意安装 MDK 后必须安装对应的器件支持包 DFP不然在芯片选择列表里找不到 GD32H759。DFP 在 GigaDevice 官网的“工具与软件”页面可以下载也可以通过 Keil 的 Pack Installer 在线安装。第二RT-Thread Studio。这是 RT-Thread 官方推出的 IDE基于 Eclipse 二次开发内置了 RT-Thread 源码管理、构建配置、下载调试等工具链。我主要用它的 BSP 导入功能可以快速生成一个完整的 RT-Thread 工程省去手动添加源文件的时间。Studio 要求 JDK 环境不过现在安装包一般都带专用运行时不需要单独配置 JDK。第三串口助手。Windows 下可以用 MobaXterm、SecureCRT或者轻量的 SSCOM。注意 RT-Thread FinSH 默认串口参数可能是 115200-8-N-1如果你修改过 BSP 里的串口配置要记得保持一致。第四Git。从开源仓库拉取 RT-Thread 源码和 BSP 会用到。如果你不想装 Git也可以直接在网页端下载 ZIP 压缩包但后续更新代码没 Git 方便。安装顺序也有讲究我一般先装 MDK 和 DFP再装 RT-Thread Studio最后装串口工具。驱动方面GD-Link/CMSIS-DAP 调试器需要安装驱动一些开发板用的 USB 转串口芯片是 CH340也要装对应驱动否则设备管理器里看不到串口。强调一下调试器驱动装好后一定要到设备管理器里确认枚举成功这一步很多人忽略结果后面下载失败排查半天。2.3 获取 RT-Thread 源码与 BSP两个入口RT-Thread 的官方源码仓库在 Gitee 和 GitHub 都有同步建议优先从 Gitee 拉取国内网络环境下速度更友好。仓库地址我就不贴了搜索“rt-thread gitee”就能找到。仓库根目录下有个 bsp 文件夹里面按厂商分类进入 gd32 目录后能看到类似 gd32h759i-eval 这样的文件夹这就是针对 GD32H759 官方 EVAL 板的 BSP。BSP 的含义是 Board Support Package即板级支持包它把芯片厂商的库函数、启动文件、链接脚本、板级外设初始化都做好了我们只需要在这个基础上改配置、写应用代码。用 Git 拉取源码的命令大致是这样git clone https://gitee.com/rtthread/rt-thread.git拉取完成后进入bsp/gd32/gd32h759i-eval目录。第一次使用可以把整个 rt-thread 文件夹放到一个路径简单的目录比如D:/workspace/rt-thread尽量不要放到中文路径下。我踩过这个坑中文路径在某些版本的 GCC 工具链下会出现编译错误或者调试时定位不到源文件的问题。2.4 用 RT-Thread Studio 导入 BSP一条高效路径RT-Thread Studio 导入 BSP 的方式有两种一种是工作区直接新建项目时选择“导入 RT-Thread BSP 项目”另一种是通过“文件-导入”菜单。操作流程都不复杂关键是选中正确的 BSP 路径。具体步骤是这样打开 RT-Thread Studio选择工作区目录建议单独建一个目录比如D:/workspace/rtthread_projects。点击“文件 - 导入”选择“RT-Thread BSP 项目”。在 BSP 根目录一栏选择刚才克隆好的bsp/gd32/gd32h759i-eval文件夹。工程名和编译配置可以保持默认点击“完成”后 Studio 会自动解析并导入工程。导入完成后Studio 会基于 BSP 中的 SConscript 脚本生成构建配置。这个时候先不要急着编译先去左下角的“RT-Thread Settings”视图里检查一下组件配置。首次生成时很多组件默认是关闭的我们需要确认 FinSH 控制台组件是启用的一般 BSP 默认会开启如果没开启在“内核 - FinSH”里勾上。最后点击工具栏的“构建”按钮也就是小锤子图标等待编译完成。第一次全量编译 GD32H759 工程会比较久几分钟到十几分钟不等这取决于电脑配置和是否全量编译。看到Build Finished且没有 error 就说明工程骨架没问题了。2.5 用 MDK 编译的方式另一个可选路径如果你习惯用 KeilBSP 目录下通常也保留了 MDK 的工程文件直接打开.uvprojx就能编译。不过这里有一个坑RT-Thread 官方现在主推 RT-Thread Studio 和 scons 构建系统MDK 工程版本有时候滞后或者缺少某些源的引用导致编译报错。要是你真想用 MDK我建议按这个顺序操作先把 BSP 下通过 scons 生成的 MDK 工程打开然后确认三处一是 Device 选择是否指向 GD32H759二是 C/C 头文件包含路径是否包含了libraries和rt-thread/include这些核心目录三是全局宏定义是否有GD32H759和USE_STDPERIPH_DRIVER。这三处如果不全MDK 编译基本都会挂在头文件找不到或者外设库函数未定义上。无论选择哪条路径核心原则是同一个 BSP 工程只选择一种构建方式维护不要今天用 Studio 生成一次明天又用 MDK 打开另存一次很容易出现配置不一致的问题。3. 点灯实验从寄存器到线程3.1 GPIO 点灯原理拆解先弄清 LED 是怎么被点亮的点灯的本质是控制 MCU 某个 GPIO 引脚的电平。LED 一般有两种接法一种是引脚输出高电平点亮另一种是引脚输出低电平点亮取决于 LED 是接到了电源还是接到了地。很多开发板为了节省电流会采用低电平点亮的方式LED 一端接 VCC另一端通过限流电阻接到 GPIOGPIO 输出低电平时形成电流回路。GD32H759 的 GPIO 虽然叫 GPIO但操作它并不像单片机课程里说的“写一个 1”这么简单需要配置的东西有好几项。首先需要使能 GPIO 所挂载的时钟GD32H759 的时钟管理单元叫 RCUGPIOA 到 GPIOK 挂在不同总线上必须先把对应 RCU 时钟打开寄存器访问才有效。这一步漏掉后面配置全部白搭这也是很多初学者点不亮 LED 的首要原因。其次是配置引脚模式。GD32 的 GPIO 模式包括输入、输出、复用、模拟四大类。做 LED 控制要选推挽输出模式配置为 GPIO_MODE_OUTPUT同时还要设置输出类型为推挽、输出速度以及是否需要上下拉电阻。LED 通常是推挽输出加不上拉即可。然后是写输出数据。GD32 每个 GPIO 组有两个数据寄存器一个叫输出数据寄存器一个叫输入数据寄存器。往对应引脚位写 0 或写 1引脚就会输出对应的低电平或高电平。执行这个操作之前配置好模式和时钟是不可省略的前置步骤。3.2 自己动手写一个寄存器级点灯程序为了把原理讲透我建议你第一次点灯先不要急着用 RT-Thread 的设备驱动框架而是直接用库函数或者寄存器操作写一个最小程序。以 Keil 环境为例新建一个简单的应用文件在主函数里完成时钟使能、GPIO 初始化和电平翻转#include gd32h7xx.h #define LED_PIN GPIO_PIN_5 #define LED_GPIO_PORT GPIOA #define LED_RCU RCU_GPIOA void led_init(void) { rcu_periph_clock_enable(LED_RCU); gpio_mode_set(LED_GPIO_PORT, GPIO_MODE_OUTPUT, GPIO_PUPD_NONE, LED_PIN); gpio_output_options_set(LED_GPIO_PORT, GPIO_OTYPE_PP, GPIO_OSPEED_50MHZ, LED_PIN); gpio_bit_reset(LED_GPIO_PORT, LED_PIN); } int main(void) { led_init(); while (1) { gpio_bit_set(LED_GPIO_PORT, LED_PIN); delay_ms(500); gpio_bit_reset(LED_GPIO_PORT, LED_PIN); delay_ms(500); } }请注意这段代码里的LED_PIN、LED_GPIO_PORT、LED_RCU是我假设的引脚具体引脚编号一定要查你自己开发板的原理图。官方 EVAL 板的 LED 可能接到了 PB15、PE3 或其它引脚网上每个人的板子不一样直接复制粘贴不查原理图结果大概率是灯不亮。在实际练习中我强烈建议你自己动手查一遍数据手册里的 GPIO 章节对照寄存器说明过一遍。之后再切换到 RT-Thread 的设备驱动框架你会更清楚底层发生了什么遇到异常排查时也更有方向。3.3 接入 RT-Thread用线程优雅地闪烁 LED当你能用裸机方式点亮 LED就可以跨入 RT-Thread 的世界了。RT-Thread 的设备驱动框架把 GPIO 抽象成了 PIN 设备API 是rt_pin_find、rt_pin_mode、rt_pin_write。好处是应用代码可以不用关心芯片具体型号换个平台只要驱动层匹配应用层几乎不用改。先看一下基于 PIN 设备的 LED 初始化#include rtthread.h #include rtdevice.h #define LED_PIN_NUM 35 /* 这个数字要换成你实际引脚对应的编号 */ static void led_thread_entry(void *parameter) { rt_uint8_t level 0; rt_pin_mode(LED_PIN_NUM, PIN_MODE_OUTPUT); rt_pin_write(LED_PIN_NUM, PIN_LOW); while (1) { rt_pin_write(LED_PIN_NUM, level); level !level; rt_thread_mdelay(500); } } static int led_thread_init(void) { rt_thread_t tid rt_thread_create(led, led_thread_entry, RT_NULL, 1024, 20, 20); if (tid ! RT_NULL) { rt_thread_startup(tid); } return 0; } INIT_APP_EXPORT(led_thread_init);这里有三个细节值得展开。rt_pin_find这个 API 需要传入一个引脚编号这个编号不是 GPIO 寄存器里的位号而是驱动框架统一分配的 PIN 序号。不同芯片的 PIN 序号映射规则不同你可以调用rt_pin_find(PE3)这类方式从引脚名反查序号也可以直接在 BSP 的 pin 驱动文件里找到映射表。不要凭感觉瞎填数字。线程的栈大小我给了 1024 字节这个例子里线程做的事很少1024 足够。如果你的线程里有大的局部数组、调用较深的函数就要把栈调大否则可能会溢出导致系统跑飞。线程优先级我给了 20这个数值在 RT-Thread 里越低优先级越高。点灯线程属于低优先级任务实际项目中 LED 闪烁往往是状态指示优先级不用设太高如果你有通信任务、控制任务再把合适的优先级排上去。3.4 增加 FinSH 命令让 LED 可以手动控制点灯光靠固定频率闪烁还不够带感我习惯把它做成可调试的既可以在系统跑起来后自动闪烁也能通过命令行手动控制。这样测试继电器外设、或者排查日志时非常有用。用 RT-Thread 的 FinSH 组件可以很方便导出命令示例代码如下static void led_on(void) { rt_pin_write(LED_PIN_NUM, PIN_HIGH); rt_kprintf(led is on\n); } MSH_CMD_EXPORT(led_on, turn on the led); static void led_off(void) { rt_pin_write(LED_PIN_NUM, PIN_LOW); rt_kprintf(led is off\n); } MSH_CMD_EXPORT(led_off, turn off the led);编译下载后打开串口终端连接目标板复位运行在 FinSH 命令行输入help就能看到led_on和led_off这两个命令。输入led_on回车LED 就会点亮输入led_off就会熄灭。MSH_CMD_EXPORT宏的作用是把命令名称和函数绑定起来rt_kprintf是 RT-Thread 提供的日志输出接口输出会重定向到 FinSH 所绑定的串口。在你还没有调试器的情况下这套命令机制能让你快速验证引脚配置是否生效。4. 常见问题与排查技巧实录4.1 编译阶段的典型报错与对策编译报错是新手最容易卡住的环节我梳理了三类高频问题。第一类编译器报找不到头文件比如fatal error: gd32h7xx.h: No such file or directory。出现这个错误基本是头文件搜索路径没配好。在 RT-Thread Studio 里BSP 的 SConscript 脚本已经配置好了路径正常情况不会出这种问题但在自己修改工程结构或者用 MDK 手动建工程时就容易漏。修复思路是检查头文件搜索路径是否包含libraries/GD32H7xx_standard_peripheral/Include这类文件夹。第二类文件编码问题。某些 BSP 文件在仓库里是 UTF-8 编码如果你的工程配置或编译器默认读成 GBK中文字符串注释可能报 warning 或乱码。这个不影响编译通过但会影响阅读建议统一设置为 UTF-8。第三类内存不足。编译链接时报No space in execution regions或者region ... overflowed说明 Flash 或 RAM 超出了芯片规格。常见原因是开启了太多组件比如完整版 RT-Thread 加上文件系统、网络协议栈后体积会明显上涨。对策是在 RT-Thread Settings 里关掉暂时用不到的组件先把点灯工程瘦身跑通后面需要再加。4.2 下载调试失败连接问题的排查顺序点灯程序编译通过后很多人会在下载这一步卡住。我个人总结了一套排查顺序先看设备管理器插上调试器后有没有正确识别如果识别不到大概率是驱动问题或者调试器本身接触不良。再看 IDE 的调试器设置RT-Thread Studio 默认可能会选 CMSIS-DAP如果你用的是 J-Link要改成 J-Link 并在设置里选对接口类型。接着检查硬件连接SWDIO、SWCLK、GND 三根线必须接好有些板子还要接上复位引脚。最后检查目标板供电调试器可以给目标板供电但电流有限如果板子外设多建议外部 USB 供电两边共地。还有一个容易忽略的细节如果你之前往芯片里烧过程序并且把它配置成了休眠或者关掉了调试端口可能导致调试器连接失败。处理办法是按住复位键在点击下载的瞬间松开复位也就是所谓的“刷复位”很多情况下能救回来。4.3 LED 不亮从灯到芯片的逐级检查程序编译下载都没问题但 LED 就是不亮这是点灯实验里最让人抓狂的情况。我建议按这个顺序查先确认芯片确实在运行可以把一个 GPIO 接到示波器或万用表上测量是否有电平翻转如果没有波形优先怀疑程序没有跑起来检查启动文件和时钟配置。然后确认引脚编号是否选对对照原理图和数据手册重新核对这是最高频的错误来源。接着确认 GPIO 时钟已经使能如果你直接写了寄存器但忘了开 RCU 时钟寄存器写入会被忽略这是第二高频的错误。最后确认高低电平逻辑是否反了开发板如果是高电平点亮你却初始化成了低电平点亮那灯自然常灭。我还遇到过一次比较隐蔽的情况片上外设的复用功能被其它初始化代码抢占了比如串口初始化和 LED 引脚冲突导致 LED 引脚被复用成串口功能。遇到这种问题检查 BSP 的 board 初始化代码里是否对多个外设做了引脚分配确保没有冲突。4.4 运行时系统跑飞利用 FinSH 和调试器定位问题当 LED 不亮但是芯片似乎有动作时需要更深入的定位手段。RT-Thread 的 FinSH 控制台是第一个利器。系统能响应命令说明内核和串口驱动没大问题如果输入命令完全无响应大概率是系统在启动早期就挂了这时候用调试器在线调试在HardFault_Handler处打断点看调用栈能定位到具体是哪一行代码触发了异常。栈溢出也是 RTOS 项目的通病点灯线程虽然简单但如果同时开启了很多任务每个任务的栈都偏大整体内存可能不够。RT-Thread 提供了list_thread命令可以查看每个线程的栈使用峰值。我在实际项目中见过线程栈设成 512 字节正常跑没问题但调试打印时rt_kprintf的缓冲一压栈就爆了。所以建议线程栈宁大勿小等稳定后再逐步调小。4.5 关于时钟配置为什么有些板子跑得快有些跑得慢GD32H759 的时钟树比普通 MCU 复杂不少最高主频 600MHz 需要通过 PLL 倍频得到。BSP 里已经默认配置好了一般不需要改但如果你自己移植或者改了外部晶振可能会遇到两种现象一是系统主频变慢串口波特率对不上打印乱码二是外设时钟频率异常定时器时间不准确。排查方法很简单先在 main 函数里调用rt_hw_board_init之后打印一下SystemCoreClock确认当前主频是否符合预期再看串口初始化时设置的波特率是否和实际分频匹配。如果要在裸机环境下验证可以翻转一个 GPIO用逻辑分析仪测量频率快速判断时钟是否正常。我个人的习惯是遇到任何“看起来不太对”的现象第一件事永远是确认时钟配置时钟一旦不对所有时间相关的东西都会连锁出错。5. 从点灯到工控下一步规划与几个真心建议5.1 后续章节的路线图点灯之后做什么点灯实验只是万里长征第一步从工控实战的角度我建议按照下面的顺序继续推进先把串口和 FinSH 用熟学会用命令行查看线程状态、设备状态、内核对象这是后续开发的“手电筒”。然后做外部中断实验用按键做输入熟悉中断优先级和底半部处理机制。接着做定时器和 PWM这两个是电机控制、信号输出的主力外设。再往后是 ADC 和 DAC把模拟量采集和输出打通工控里温度、压力、流量基本都是模拟量信号。等这些基础外设都跑熟了就可以进入系统集成阶段用软件包集成 Modbus RTU/TCP 协议栈做远程数据采集把看门狗加进来提升系统稳定性如果需要本地存储可以集成文件系统。每一步都建议基于第 0 篇这个工程增量开发不要每章都另起炉灶。这样你的工程会越来越丰满对 RT-Thread 构建系统的理解也会越来越深。5.2 从裸机思维到 RTOS 思维三个转变如果你是从裸机开发转过来的有三个思维上的转变我觉得值得提前适应。第一个转变是“全局变量能不用就不用”。裸机开发时不同模块之间经常用全局变量共享数据但在多线程环境下共享数据涉及到同步问题必须用信号量或消息队列保护否则会出现数据不一致、竞态条件等随机故障。第二个转变是“中断处理函数越短越好”。RTOS 环境下中断服务函数里只做标记置位和数据接收真正的业务处理要放到线程里通过信号量或消息队列去完成这样既避免了中断嵌套带来的不确定性也缩短了关中断的时间。第三个转变是“不要指望 delaying 大法”。裸机里到处用软件延时控制时序到了 RTOS 里要使用rt_thread_mdelay让出 CPU把宝贵的处理器时间交给其它任务。你会发现各个任务之间合理分工之后系统的实时响应能力反而比裸机轮询好很多。5.3 工程管理与备份习惯一个不是技术但很重要的点工控项目周期普遍长硬件改版、需求变更都是常态。我见过不少开发者把工程目录放在桌面文件命名带“最终版”“最终版2”一旦工程文件损坏或者误删追悔莫及。我的建议是从一开始就用 Git 管理整个 RT-Thread 工程目录。每次完成一个可用功能就提交一次提交信息写清楚改了什么、为什么改方便后续回溯。RT-Thread BSP 里有些产品相关的配置比如引脚分配、时钟配置这些信息也建议记录在 Git 提交信息里。顺便说一句同一个工程目录尽量保持单一平台开发。我给自己定的规矩是RT-Thread Studio 工程生成后不要拿着 MDK 再打开去编译避免两边构建配置互相覆盖。如果团队里有人用 MDK 有人用 Studio那就在 Git 里维护两套工程配置但产出物要分开。5.4 我的个人体会把基础流程走通比追求高级功能重要得多最后分享一点我自己的感受。很多初学者拿到高性能开发板第一反应是去调一堆高级外设比如先跑个以太网、接个屏幕结果被各种编译和配置问题消磨了耐心。我有一个比较土但很管用的做法无论换什么新板子、新芯片第一件事永远是先把编译、下载、串口打印、GPIO 控制这四个基本链路全部打通确认开发环境完全健康了再开始搞复杂功能。环境搭建本身没有太多高深的东西但这个小环节决定了一个项目的起始速度。第 0 篇的“0”不是指它没意义恰恰相反它是整个系列的地基。地基稳了后面的高楼怎么盖心里才有底。等你把点灯实验跑通不妨试着把 LED 闪烁的频率改一改或者加两个按键控制不同状态的灯光这就算是你和这套平台之间的第一次“交互”了。接下来的路还很长下一篇文章我会开始讲串口和 FinSH 的深度使用到时候咱们再继续折腾。