那个让你装四个软件的人多半只丢下一句“先把环境配好”然后你就盯着桌面上的新图标发呆Keil、STM32CubeMX、ST-Link驱动、串口助手……这四个到底谁负责干什么为什么不能像装微信一样一个安装包全搞定这篇我就把话说透。作为《基于STM32的嵌入式C编程之旅》的第四篇这篇不讲C语法、不讲寄存器操作专门把工具链这层窗户纸捅破。先说结论后面逐件拆解STM32CubeMX负责“配置”Keil MDK负责“编译”ST-Link驱动负责“下载与调试”串口助手负责“看结果”。搞懂这条流水线你后面写的每一行嵌入式C代码踩坑率至少降一半。1. 为什么嵌入式开发要让你装一堆软件——先理解工具链的分工很多从Web开发、上位机开发转过来的朋友第一反应是“你们嵌入式怎么这么原始”写个Java用IDEA写个Python用PyCharm一个软件全包了。怎么到了STM32反而要装四个1.1 从源码到芯片运行一条完整的流水线先别急着吐槽我们看程序从“你脑子里的想法”变成“芯片引脚翻电平”中间要经过多少环节。第一步你得先告诉芯片“我用哪个引脚、接了什么外设、时钟跑多快”这个叫硬件配置第二步把你的C/C代码翻译成Cortex-M内核能读懂的机器码这个叫编译第三步把编译出来的机器码文件通过调试器写进芯片的Flash里这个叫下载第四步芯片跑起来以后它到底跑没跑对总得有个途径把信息反馈给你这个叫调试与通信。四件事正好对应四个软件。换句话说不是别人非要折腾你而是嵌入式开发的产出物不是“能双击的exe”而是一颗裸芯片里烧录的二进制文件从这个文件诞生到落地的每一环都需要对应的工具。这跟盖房子的逻辑一模一样设计院出图纸施工队按图施工监理验收最后你住进去。STM32CubeMX是设计院Keil是施工队ST-Link是监理串口助手是你验收时往里看的窗户。没有哪个角色能同时胜任四份工作你硬让设计院去验收那肯定要出问题。1.2 为什么不能像IDE那样“一个软件全搞定”这个问题的答案牵扯到嵌入式行业的生态结构。芯片厂商意法半导体擅长造芯片和提供底层库但它们不擅长做IDE做出来的IDE用户体验经常被吐槽Keil公司的老本行是嵌入式编译器和IDE但它不可能替每家芯片厂商做引脚配置工具调试器本质上是硬件需要单独的驱动程序串口调试更是独立于芯片平台的存在——你要调试一个Arduino照样得用串口助手。这种“分段式”生态的好处是每一环都可以替换。你不用Keil可以用IAR、GCC不用ST-Link可以用J-Link、DAPLink串口助手更是多到数不过来。工具链的灵活性换来的代价就是新手一开始要装的东西有点多。所以这篇文章不只是解释“这四个软件是干嘛的”更是帮你在脑子里搭好一张工具链地图以后看到任何新工具都能自己把它归类到“配置、编译、下载、调试”这四步里去。2. 第一个软件STM32CubeMX——它帮你干了最脏最累的活很多人上来就点开Keil打开一个空的工程想着像写C语言作业一样开始敲代码。结果发现敲了三百行连一个LED都没点亮过。因为STM32不是桌面程序你敲代码之前得先告诉芯片“PA9这个引脚我不用做普通IO我要让它当串口发送引脚用”。这个设置过程专业上叫引脚复用Alternate Function靠手写寄存器配置非常繁琐而且极易出错。2.1 CubeMX到底在配置什么第一次打开STM32CubeMX你会看到一个芯片引脚图密密麻麻的引脚旁边带有各种颜色标记。这就是整个工具的核心——可视化配置界面。它帮你完成三件事。引脚功能分配。比如你的开发板上LED接在PB0号引脚你需要把PB0设置为GPIO输出模式把PA9设置为USART1_TX串口发送把PA10设置为USART1_RX串口接收。在CubeMX里你只需要在芯片图上点一下引脚选择对应的功能即可。芯片到底哪些引脚能复用成串口、哪些能复用成定时器PWM这张映射表是固化在芯片数据手册里的CubeMX帮你内置了不用背。时钟树配置。这是新手最容易忽略的部分。STM32上电默认用内部16MHz时钟HSI但如果你想让CPU跑到72MHzF103系列甚至168MHzF407系列就得配置PLL锁相环、分频器。CubeMX把整棵时钟树画成了结构图你只需在输入框里填目标频率它自动算好上下行分频系数。我见过很多人程序烧进去没反应查半天发现是时钟没配好外设挂了。外设参数初始化。配置完引脚和时钟还得告诉串口“波特率1152008位数据1位停止位无校验”告诉定时器“自动重装载值999分频器71开启PWM输出”。这些参数对应的是外设寄存器的一堆初始化代码手写的话光是结构体赋值就有几十行但在CubeMX里就是几个对话框。2.2 嵌入式C编程为什么更要依赖CubeMX有人可能会问我们系列标题写的是“嵌入式C编程”C讲究的是封装、抽象、类的设计CubeMX生成的偏偏是纯C语言的HAL库初始化代码这不是和C理念冲突吗我的看法恰恰相反。CubeMX承担的是“硬件描述”和“初始化”这部分枯燥且容易出错的工作生成的代码是稳定的、可重复的。你在它生成的HAL初始化代码之上再写C的外设类封装比如把UART初始化代码收进一个Uart类的构造函数把引脚操作收进Led类的on()/off()方法两层结构非常清晰。如果不用CubeMX你就要手动写这些初始化代码而手动写寄存器初始化的最大问题是代码量一大你这个C类的边界就不可能干净——每初始化一个外设就要查数据手册、查寄存器位定义你的精力全被细节耗光了哪还有心思设计对象模型所以CubeMX不是C的敌人反而是在帮C清理战场。这也是为什么行业内做嵌入式C项目前端配置依然会用CubeMX、STM32CubeCLT这样的工具。2.3 实操要点与注意事项安装芯片包慢的问题。很多人第一次打开CubeMX选择芯片型号时会卡在下载芯片支持包Firmware Package这一步。原因很简单软件包托管在境外服务器上网络波动会频繁中断。解决办法有两种一是用CubeMX主界面“Help - Manage embedded software packages”里手动下载网络好时能过二是到ST官网用镜像地址下载对应版本的包文件然后在“From Local”指定本地包路径。注意版本要对应包文件不要乱改名。引脚冲突报警。在CubeMX的引脚配置界面如果你把一个引脚又设成串口TX又设成定时器通道软件会用红色标注冲突编译前就能发现。这个功能非常实用比你在Keil里来回翻报错舒服多了。不要乱改自动生成的代码。CubeMX生成的代码分两块一块是“用户代码区”USER CODE BEGIN xxx到USER CODE END xxx这块你怎么改都行下次重新生成代码时它会保留另一块是STM32CubeMX自己维护的初始化逻辑你改了它下次再生成就会覆盖掉。很多新手习惯性在MX_GPIO_Init函数里加自己的逻辑结果一重新生成就丢还以为是软件坏了。我的建议是所有自己加的代码一律放进USER CODE区段强迫自己遵守这个规则你能少掉很多头发。3. 第二个软件Keil MDK——把C/C翻译成机器指令的翻译官CubeMX生成了工程骨架和初始化函数但它不会把你写的业务逻辑变成能烧录的文件。这时候轮到Keil MDK登场。MDK的全称是Microcontroller Development Kit它是目前STM32初学者最主流的集成开发环境。很多新手在Keil里的第一个困惑是我明明把代码写完了然后呢然后点那个“Build”按钮让编译器和链接器接管。3.1 IDE、编译器、链接器三件套混在同一个窗口里Keil这个软件严格来说是“外壳”里面装了三样东西代码编辑器、编译器ARMCC或AC6/armclang、调试器UI。平时你写代码用的是编辑器点Build按钮的时候其实是编译器在工作——它把你的main.c、main.cpp翻译成汇编指令再由汇编器翻译成目标文件.o最后由链接器把多个目标文件和启动文件、库函数拼成最终的镜像文件。这里有一个嵌入式开发特有的概念交叉编译。你的电脑是x86架构的CPU你的STM32芯片是ARM Cortex-M架构的CPU两种处理器根本不认识对方“原生”的机器码。所以Keil里那套编译器不是“把你写的代码编成本机程序”而是“在x86电脑上生成ARM芯片能运行的机器码”。你可以把Keil想象成一个会双语翻译的人工翻译——翻译出来的语言当前电脑自己听不懂但它服务的对象听得懂。3.2 map文件、hex文件、axf文件都是干什么的编译成功之后Keil的Build Output窗口会显示一段统计信息我第一次看到的时候一脸懵。Program Size: Code9088 RO-data648 RW-data92 ZI-data1044简单解释一下Code是程序代码占用的Flash空间RO-data是只读常量比如字符串字面量占用的Flash空间RW-data是初始化为非零值的全局变量占用RAM空间ZI-data是零初始化变量比如未初始化的全局变量占用RAM空间。这四类数据的分配明细都记录在同目录下生成的.map文件里。map文件就是你的内存地图。排查内存溢出、变量地址冲突时它就是第一手资料。很多嵌入式老手拿到别人的工程第一件事就是打开map文件看内存布局这一步的含金量远大于看代码。等你哪天开发程序突然HardFault硬件错误中断你会回来感谢这个习惯的。Keil最终还会生成.hex或.bin文件前者是Intel十六进制格式带地址信息后者是纯二进制的裸数据。ST-Link烧录器和一些Bootloader工具两者都能接受但STM32CubeProgrammer烧写至少需要hex不含地址信息的bin有时候会出错。3.3 Keil与C51的坑同名软件、完全不同的核心有个热词叫“keil5兼容c51和stm32安装”这个坑值得单独说。Keil公司有两个产品线Keil C51用于8051单片机Keil MDK用于ARM内核单片机。两者都叫“Keil”界面长得几乎一样但它们的编辑器、编译器、调试器内核完全是两套东西。如果你的电脑装了C51版本然后拿它去打开STM32工程会发现弹窗“No Target Device Connected”或者“Device not found”不是板子坏了是你的软件和芯片型号不匹配。正确的做法是先安装MDKARM版想同时搞51单片机再安装C51的兼容包让两个版本共存。在同一个集成环境里新建工程时会有“Create a new project”选项如果你能看到ARM与C51两个工具链说明安装成功了。需要特别注意的是MDK 5的芯片支持是按“器件包”方式管理的你光装了MDK本体还不够还得到Keil官网下载你所用芯片对应的Device Family Pack——STM32F1、STM32F4、STM32G0等系列分别对应不同的打包文件。热词里“stm32芯片包安装”指的就是这个。不装芯片包你新建工程时根本找不到STM32F103C8T6这个型号。3.4 Keil里启用C编译的实用设置回到我们的主题“嵌入式C”。Keil MDK默认情况下文件后缀是.c的会交给C编译器后缀是.cpp的会交给C编译器。你只需要把主程序文件命名为main.cpp就可以在Keil里愉快地写C类了。但要注意两件事。第一HAL库是C语言写的头文件你在C文件里包含它时最好加上extern C保护。Keil的armclang编译器在实际项目中通常能自动兼容C头文件但如果你遇到“链接阶段undefined reference”一类的问题十有八九是名字修饰Name Mangling导致的这时候把包含部分包进extern C {}即可。第二armclang编译器对C标准的核心支持比较新但ST官方HAL库测试较多的是纯C环境所以F1系列上用C时某些宏定义或回调函数写法需要做小调整。我的建议是第一年先用C写业务逻辑层比如LED类、UART类底层驱动仍然调HAL库的C接口。这样既享受了C面向对象的好处又不至于遇到太多与工具链相关的深坑。4. 第三个软件ST-Link驱动和调试器——让电脑能“看见”芯片内部第三个要装的东西看起来更不起眼甚至有人装完都不知道自己装了个啥。我说句实话你装的那个小小的“ST-Link驱动”本身不是软件它是为了让电脑能驱动一个硬件。真正的ST-Link是一个长得像U盘的硬件调试器。4.1 ST-Link硬件和驱动的关系来一次彻底理清现在市面上的STM32开发板绝大多数板载了ST-Link调试器——也就是“烧录器 调试器”二合一模块通过USB线连电脑。电脑要跟这个硬件通信需要驱动程序插上开发板后如果Windows设备管理器里出现一个带黄色感叹号的设备那就说明驱动没装好。装好ST-Link驱动后Keil才能通过USB接口向ST-Link发送“下载固件”的指令。ST-Link的调试通信接口叫SWD只用四根线SWDIO数据、SWCLK时钟、GND地、3.3V电源。如果你用的是独立的ST-Link模块而非板载需要把这四根线接到STM32的最小系统板上。这里很多人会犯一个错误只看线名不看板子丝印。杜邦线接错一根烧录器就识别不到芯片还会出现“Error: Flash Download failed - Target DLL has been cancelled”这类报错。SWD接口的优点是IO占用少、速度快还支持在程序跑飞时通过复位引脚把芯片拉回来。相比之下老式的JTAG接口需要5根线现在基本被SWD取代了。4.2 下载失败经验里最有效的排查顺序我从初学到带学生见过太多“烧不进去”的案例。这里给你一个排查顺序按这个查至少能解决八成问题。第一步确认设备管理器的驱动状态。拔插开发板听声音看“通用串行总线设备”里有没有“STM32 STLink”字样。没有的话重装驱动或换USB线。第二步确认Keil里选对了调试器。打开“Options for Target - Debug”页签在右侧下拉框选“ST-Link Debugger”再点Settings看能否识别出设备。能识别出SW Device且显示芯片型号基本就稳了。第三步确认电源和接线。板载ST-Link的板子要确认板上电源跳线帽在位。独立ST-Link接最小系统板的3.3V和GND必须接对SWDIO和SWCLK要交叉对应——很多人的问题就出在这ST-Link的SWDIO是有方向性的接错会相当于把芯片和调试器的IO短路结果就是连接失败。第四步降低下载速度。在ST-Link Settings里把SWD的频率从默认的4MHz改成1MHz甚至更低对线材较长、接触不良的场合成功率立马提升。特别是用杜邦线的面包板电路4MHz经常触发通信错误这不是芯片坏了是信号完整性不够。4.3 调试器不只是“烧录”断点调试才是它的高光新手往往把ST-Link当成“烧录工具”烧完就拔线。其实它真正的价值是在线调试。在Keil里点一下断点那一列代码运行到那一行就会停下来你可以查看每个变量的实时值、单步执行、观察函数调用栈。这个能力在排查逻辑错误时是神器。原理层面STM32的Cortex-M内核支持硬件断点。简单说内核里有一组断点比较寄存器你设置的断点会被写成一条特殊的BKPT指令或者比较器条件CPU执行到该地址时自动产生异常并暂停调试器再把PC值、寄存器值同步回电脑界面。Flash里的代码不能原地修改但断点寄存器是CPU的一部分不需要改Flash所以能实现“硬断”。我个人的实操心得点灯程序靠编译下载就能搞定但是从第100行之后不学会调试器断点排查效率至少低10倍。尤其是C类这种层层调用的代码一个参数传错定位起来没有调试器简直折磨。所以不要嫌ST-Link麻烦它是嵌入式工程师唯一一双能“透视”芯片的眼睛。5. 第四个软件串口调试助手——开发者的“眼睛”前三个软件都是“把代码送进芯片”第四个软件反而是“从芯片里拿信息出来”。如果说ST-Link是透视眼串口调试助手就是搭在芯片和电脑之间的一条对讲机频道。5.1 串口调试助手和USB虚拟串口的配合STM32的USART外设是芯片自带的串口接口通过两个引脚TX发送、RX接收传递数据。但要和电脑通信得让电脑也出一根串口线。早期电脑有九针DB9串口现在笔记本电脑几乎绝迹了所以STM32开发板上通常用两种方式把串口引到USB口一种是板载USB转串口芯片比如CH340、CP2102另一种是直接走内部USB接口把STM32的USB模块虚拟成一个串口也就是热词里“stm32 usb虚拟串口发送数据”的场景。如果你用的是带板载ST-Link的开发板通常会默认引出“虚拟串口”——因为ST-Link模块内部也有串口转换功能你电脑上会多出一个COM口。用串口调试助手打开这个COM口STM32发来的数据就能显示在屏幕上。这整个链条的本质就是串口助手负责PC端的显示与协议解析它本身跟STM32品牌无关任何带串口接口的芯片都能用。5.2 把printf重定向到串口让调试像桌面程序一样舒服写桌面程序时我们习惯用printf打印调试信息。嵌入式C语言开发里printf也是可以做重定向的——只要你能实现一个底层字符输出函数让它把字符从串口发出去printf就会把字符串逐个字符交给这个函数发送。在Keil MDK环境下标准做法是重写fputc#include stdio.h int fputc(int ch, FILE *f) { /* 等待发送完成然后将字符写入USART2数据寄存器 */ while (!(USART2-ISR USART_ISR_TXE)); USART2-TDR (ch 0xFF); return ch; }这颗芯片的USART2发送寄存器满fputc就阻塞等待直到把字符发完。只要实现这个函数整个C标准库的printf就被“骗”到了串口上。到了嵌入式C我更推荐把这条链路封装起来。写一个UartConsole类构造函数里初始化串口参数send(const char*)成员函数负责发送字符串再配合一个简单的operator重载调试信息就能用类似uart hello count \r\n的方式输出。这样既符合C风格代码在真实项目里也更好维护。当然printf重定向对初学阶段仍然足够你先把工具跑通了再谈抽象。5.3 串口收到乱码百分之八十是这三类问题乱码问题几乎是每个嵌入式新手都会撞上的墙。串口助手显示“一堆奇怪的符号像乱码又不全像”这时候不用怀疑人生按顺序排查。第一是波特率不匹配。发送端STM32初始化代码设置的波特率是115200串口助手右下角的波特率选成了9600数据位节奏完全对不上显示必然乱码。确认两边的波特率完全一致后再重试。第二是接线有问题。STM32的TX应该接串口模块的RXSTM32的RX接串口模块的TX。如果有转接板把TX和RX都引出很多人直接“TX接TX、RX接RX”结果全乱。这个错误属于“交叉连接”问题检查一下立刻明白。第三是地线没接好。串口调试助手能看到数据但是每隔几条就出现一个错码很大概率是GND没共地。嵌入式系统里面电平参考地是双方的“基准线”不共地时逻辑电平的参考就变了信号自然失真。给单片机和USB转串口模块连接相同的GND这类现象马上消失。花生壳大小的模块、看起来朴素的串口助手却是整个工具链里最直观的“反馈渠道”。我说过一句话永远让你的嵌入式项目保留一条串口输出链路它能在你调试任何诡异问题的时候给你第一手线索。6. 四个软件怎么配合——从CubeMX到串口打印的完整实操光说理论没用我把这四个软件串起来走一遍从零到“串口打印Hello”的完整流程。这个过程是嵌入式开发最典型的最小闭环你走通了后面的所有项目都只是在这个闭环上增加复杂度。6.1 一次完整的“配置—编译—烧录—验证”四步曲打开CubeMX新建工程选择你的STM32型号比如STM32F103C8T6。在Pinout页签把PA9设置为USART1_TXPA10设置为USART1_RX配置USART1的波特率为115200。时钟树部分在HCLK输入框里填72软件会自动配好PLL。Project Manager里Project Name填hello_uartToolchain选择MDK-ARM然后点击生成代码。等CubeMX生成完直接点击“Open Project”它会调起Keil MDK打开这个工程。到了Keil里找到main.c在/* USER CODE BEGIN */区段中加入fputc重定向函数和printf调用编译点击Build按钮。如果编译输出显示0 Error说明代码已经编译成hex文件了。接下来插上开发板在Keil里点Load或者下载按钮ST-Link驱动开始工作几秒钟后烧录成功。最后打开串口调试助手选择开发板对应的COM口如果是板载ST-Link通常是“STMicroelectronics Virtual COM Port”波特率设为115200点击打开串口。按下开发板的复位键串口窗口里出现“Hello from STM32!”这行字意味着四个软件全部串联成功。从这一刻起你就拥有了一个可扩展的最小开发环境想点灯就加GPIO逻辑想测距离就接超声波模块想跑FreeRTOS就加操作系统组件。工具链真的只是工具链它不会限制你的想象力限制你的是你愿不愿意多写多试。6.2 用VSCode替代Keil是不是更好我的中立看法网上越来越多教程推荐用VSCode arm-none-eabi-gcc CMake OpenOCD来做STM32开发因为Keil的界面老气、代码补全弱。说实话作为进阶方向这套组合拳确实很强VSCode有更好的代码提示支持c语言服务器还能用git管理版本。但我不建议刚入门的人直接走这条路。原因很朴素这套工具链的配置成本和学习曲线比Keil高一个数量级。你需要理解链接脚本、CMake语法、OpenOCD配置文件还要手动处理那些Keil帮你自动搞定的启动文件与库依赖。在你还分不清“编译错误”和“烧录失败”的时候把问题归因到工具链上会极大打击自信心。我的建议是入门阶段用Keil跑通至少两三个完整项目等理解了核心原理再主动切换到VSCodeGCC方案那时候你自己就明白为什么有人愿意折腾extension配置——因为编译速度、代码体验确实差着一个时代。工具链是手段不是目的别让手段绑架了你的学习节奏。6.3 我自己的快速排错习惯我实际开发中用的排查顺序跟官方教程不太一样。如果烧录后芯片没反应我第一件事不是看代码而是摸芯片温度——冷冰冰的说明根本没上电第二件事是测量3.3V供电用万用表量一下电源脚和GND之间的电压第三件事看复位引脚的电平很多板子要求复位脚是高电平如果被拉低芯片永远处于复位状态第四件事才是重新编译烧录。再就是改代码前先想清楚“这次改动到底影响哪个环节”。如果加了个外设初始化代码后突然下载失败那就把新加的外设代码注释掉确认是不是引脚配置把SWD的两个下载引脚占用了。F103系列里PA13、PA14默认是SWDIO和SWCLK新手如果不知道这回事把它们配置成了普通GPIO输出下一次烧录就会报错。解决办法很简单烧录时按住复位键或把工程改成在RAM中调试实在不行用ST-Link Utility连上板子在它的设置里复用SWD引脚。7. 常见问题与排查技巧实录这章节我整理一份高频率“踩坑清单”都是我从自己带项目、带新人时遇到最多的问题。遇到就查表能省下几小时的搜索时间。7.1 环境安装与连接问题速查表现象可能原因解决思路CubeMX下载芯片包卡住网络波动/源服务器慢手动下载芯片包后在Manage Software Packages里本地导入Keil新建工程找不到芯片型号未安装对应Device Family Pack到Keil官网下载STM32F1/F4等系列器件包双击安装设备管理器里ST-Link带黄色感叹号驱动未正确安装卸载驱动后重新安装ST-Link驱动更换USB线再试Keil Target Settings识别不到SW DeviceSWD接线错/频率过高检查SWDIO、SWCLK、GND接法降低SWD频率到1MHz下载时报“No Cortex-M SW Device Found”芯片处于低功耗或复位状态按住复位键的同时点击下载或短接Boot0到3.3V进入系统Bootloader串口助手乱码波特率不一致/TX RX接反/未共地三处逐一排查最常见是波特率设置问题程序烧录成功但板子没反应供电不足或引脚配置错误先量3.3V和GND测复位脚电平再检查CubeMX配置7.2 从装软件到跑通第一个程序我建议你做个备份清单环境搭建这种事一次成功是运气两次成功是经验三次以上还不做记录就是把时间往水里扔。我建议你准备一个笔记记录四件事装的是什么软件、什么版本、是从哪下载的、装的过程中出现过什么问题。别小看这份记录半年后你要重装电脑或帮朋友配环境翻出这篇笔记效率是别人的十倍。具体到软件版本方面Keil MDK的版本更新非常频繁不建议追新。我用一个非常老但稳定的MDK 5.30版本带了一整年的学生项目没出过大问题。CubeMX的版本升级也一样除非新工程用了新芯片否则不必天天升级。嵌入式开发最忌讳的就是“为了升级而升级”——芯片原厂库经常更新但你的项目需求没变多一次升级就多一次变动风险。记住这句话嵌入式环境的稳定比环境的“新”重要得多。8. 最后补一句这些软件背后的C视角这篇通篇讲的都是工具链但我希望你别把工具链想象成和C编程割裂的东西。回想一下我们为什么要在STM32上用C因为C的封装、资源管理、代码复用能力比纯C更适合中大型项目。但前提是你得先有一个能持续复现的工具链——CubeMX保证初始化可复现Keil保证编译可复现ST-Link保证烧录可复现串口助手保证观察可复现。四者可复现你的C代码才算真正活在了一个工程化环境里。我个人的实操体会是先花一天时间把这篇提到的工具链彻底跑通比花三天看语法书更值。因为嵌入式C和桌面C最不一样的地方就在于你写的对象最终要驱动一个真实的物理世界。当你第一次用串口助手看到自己写的那行std::string拼出来的字符串出现在电脑屏幕上时那种“我的程序真的在这个裸片上跑起来了”的感觉会让后面所有的学习都有了方向感。下一篇我会接着讲在CubeMX生成的HAL代码之上怎么用C封装一个像样的GPIO和UART类。这四件工具就是那棵树的土壤。