STM32F103C8T6点灯Demo硬核拆解：从GPIO到工程调试全流程

简介：一份基于STM32F103的32x64双色点阵屏静态显示演示工程，面向嵌入式显示驱动开发与STM32入门学习者。工程采用HUB08接口连接双色LED点阵屏，通过连续更新像素状态实现静态图像输出，覆盖系统时钟与GPIO初始化、PWM亮度控制、显示缓冲区设计、中断服务等关键环节。压缩包共74个文件，以C源码（30个.c）和头文件（31个.h）为主，另有8个汇编启动文件(.s)、Keil工程文件(.uvprojx/.uvoptx)以及一键清理编译产物的bat脚本，整体仅273KB，结构清晰便于按模块对照阅读。内容预览显示已按App、Bsp、Libraries等目录划分，方便理解外设驱动与主程序的关系。目前已有1999人学习下载，适合想通过实际项目掌握HUB08时序、双色点阵驱动及STM32F103外设配置的开发者参考复现。 在嵌入式开发圈子里，看到一个 "STM32F103C8_Demo_2020-10-10-LEDA.rar" 这样的压缩包，基本就能猜出个七八分内容了：一个基于蓝 pills 经典芯片的示例工程，八成是点灯程序，日期标得清清楚楚——2020年10月10日。这个命名习惯我非常眼熟，很多工程师在做项目归档时都爱这么干，芯片型号加日期加功能缩写，时间一长翻起老项目来比那些叫“新建文件夹”“最终版”的省心太多。

不过得说句实在话，越是这样看起来“简单”的Demo，对于刚入坑STM32或者正在做课程设计、比赛项目的朋友来说，越容易在环境搭建和底层配置上栽跟头。我见过太多人卡在“程序烧不进去”“编译报错找不到芯片”“LED死活不亮”这些关卡上，其实根子都在一些不起眼的细节里。这篇博文就把这个Demo涉及到的核心内容拆开揉碎，从硬件选型、工程创建、代码逻辑到烧录排查，一条龙讲清楚，哪怕你之前没摸过STM32，照着操作也能跑起来。

1. 整体思路与方案选型

1.1 为什么是STM32F103C8T6

STM32F103C8T6这颗芯片，是ST公司推出的主流级ARM Cortex-M3内核微控制器，江湖人称“蓝 pills”或者“最小系统板之王”。它在国内开发者社区的保有量高得离谱，价格一度被打到十块钱以内，性能却一点都不含糊：72MHz主频、64KB Flash、20KB SRAM，还有一堆USART、I2C、SPI、ADC、定时器外设。这个配置放在今天做点传感器数据采集、电机控制、小型物联网节点，依然绰绰有余。

选择这颗芯片做Demo，最大的优势在于资料生态极其丰富。不管你用标准外设库、HAL库还是LL库，网上随便一搜就是海量例程。就算完全从零开始，照着官方参考手册和原理图也能稳步推进。而且C8T6是LQFP48封装，引脚不多不少，手工焊接难度低，对学生党、DIY爱好者特别友好。这颗芯片还带USB从机控制器，虽然做不了高速USB设备，但模拟一个串口或者HID设备完全没问题，很多开发板的板载下载器就是用它实现的。

回到这个Demo本身，LEDA这个后缀我推测是LED Application或者是LED A组通道的意思，大概率工程里控制的是一个或者多个GPIO引脚输出高低电平，点亮板载LED。这种入门程序看似平平无奇，实际上把MCU最核心的GPIO操作、时钟树配置、延时逻辑全串起来了，是理解后续所有外设编程的地基。

1.2 环境与库版本的选择思路

搭建STM32开发环境，摆在你面前有几条路：Keil MDK、IAR EWARM、STM32CubeIDE、PlatformIO + VS Code。要是放在2020年那会儿，Keil MDK是绝对的主流首选，大学实验室、培训机构几乎清一色用它。现在则两极分化，老工程师继续用Keil吃老本，新入行的年轻朋友很多直接从STM32CubeIDE上手，配合CubeMX图形化配置，开发效率确实高不少。

这个Demo的时间点是2020年，从压缩包命名习惯推测，原作者的开发环境很可能是Keil MDK 5系列。这里我想多说两句工具链的选型逻辑。如果你只是跑个简单Demo，用什么IDE区别不大；但如果你后面要接触RTOS、要调试复杂的低功耗逻辑、要做代码静态分析，Keil MDK的工程管理方式和调试器集成度，依然是很多老牌工程师的心头好。而STM32CubeIDE的优势在于免费、跨平台、CubeMX一键生成初始化代码，对新手极其友好。

我个人建议是：如果完全是零基础，直接用STM32CubeIDE配合CubeMX，把图形化配置生成的代码当作学习模板，看它怎么初始化时钟、怎么配置GPIO模式；如果学校或者公司强制要求Keil，那就用标准外设库或者HAL库手写工程，务必搞清楚每一步寄存器操作的来龙去脉。两条路都走得通，最怕的是两种工具来回横跳，最后连工程文件怎么组织的都搞不清楚。

1.3 这个项目到底解决了什么问题

把点灯Demo拔高一点看，它的核心价值在于验证了一套完整的开发链路是否畅通：从工程项目创建 → 时钟树初始化 → GPIO外设配置 → 编译链接 → 下载烧录 → 运行调试，这个闭环里任何一环出了问题，LED灯都不可能按预期闪烁。所以这个Demo更像是一个“工程健康检查工具”，而不是单纯的“亮个灯”。

很多朋友在学STM32时会犯一个错误：拿到板子就急着看例程代码，噼里啪啦把main函数里的逻辑读一遍，觉得自己懂了，结果自己新建工程时连启动文件都忘了添加，链接报错一堆。这个Demo恰恰能帮你规避这种眼高手低的问题——你先把它跑通，再亲手从空工程开始一步步重建，这个过程走一遍，你对嵌入式开发的工程组织能力就真正建立起来了。

另外这个Demo还传递了一个很务实的观点：嵌入式开发不是竞赛，能跑、够稳、易维护比花哨的代码技巧重要得多。你点灯用HAL库三行代码能解决，就没必要自己造轮子去操作寄存器，除非你正在学习寄存器底层原理。

2. 硬件电路与核心引脚解析

2.1 最小系统板上的LED电路设计

市面上的STM32F103C8T6最小系统板，几乎无一例外都焊接了一个板载LED，这个LED通常连接到PC13引脚，也有个别设计连到PB12或者PA1。为什么要选PC13？我特意去查过一些资料，一个比较可信的说法是：PC13引脚在芯片上靠近RTC相关功能区域，板载LED挂在它旁边，不会干扰主功能引脚的扩展使用，同时这个引脚的驱动能力虽然有限，但驱动一个LED绰绰有余。

这个LED的电路结构非常简单：一个限流电阻串联在LED和MCU引脚之间，电阻阻值通常是1kΩ或者470Ω，另一端接3.3V电源。当引脚输出低电平的时候，LED两端产生电势差，电流流过LED，它就亮了。所以这个电路的逻辑是低电平点亮，和51单片机那种高电平点亮的接法刚好相反，初学者特别容易搞混。

咱们做个简单计算。C8T6的GPIO引脚在推挽输出模式下，最大能提供大概20mA的灌电流或者拉电流，但芯片整个VDD引脚的总电流上限有限制，所以一般不建议让单个GPIO长时间跑满电流。如果限流电阻是1kΩ，LED正向压降按2V算，工作电流就是(3.3-2)/1000=1.3mA，这个电流下LED亮度偏低但能看清；如果换成470Ω，电流就是约2.8mA，亮度会明快一些。我建议做这个Demo时直接测量一下LED两端电压和串联电阻阻值，自己算一遍电流，这比死记公式更有体感。

2.2 除了LED，板上还有什么

除了LED，这种最小系统板通常还有一个电源指示灯、一个复位按键、一个BOOT选择跳线、一个AMS1117-3.3稳压芯片、一个8MHz晶振（有的板子配的是8MHz无源晶振加两个负载电容），以及Micro-USB或者Type-C接口做供电和串口通信。这些元器件共同构成了STM32正常运行的最小闭环。

这里有个比较坑的地方：部分高仿板子的晶振焊得质量不高，可能导致芯片上电后无法正常启动。遇到这种问题，优先检查复位引脚电平、BOOT0引脚是否被拉高、芯片供电是否稳定在3.3V。我就遇到过一块板子，上电后VDD有3.3V，NRST也有3.3V，但程序就是不跑，后来用示波器量8MHz晶振引脚，发现根本没起振，吹下来重新焊了一个好的晶振就正常了。这类问题在批量采购廉价板子时并不少见，排查思路值得记一下。

2.3 了解SWD调试接口

这个Demo工程如果要下载烧录，最方便的方式是使用ST-Link V2仿真器，通过SWD接口连接目标板。SWD只需要四根线：SWDIO、SWCLK、GND、3.3V（可选）。相比传统的JTAG接口动辄十几根线，SWD接口的优势极其明显，引脚占用少、连接速度快，而且现在的ST-Link、DAP-Link都已经普及了SWD模式。

在接线细节上要注意：SWDIO和SWCLK两个引脚，在C8T6上分别对应PA13和PA14。这两个引脚默认功能是调试端口，如果你在代码里把它们重映射成了普通GPIO，那恭喜你，下次想烧录程序就得多按几回复位键抓时序了。很多初学者在调试自己的工程时，喜欢把所有引脚都用光，结果把SWD引脚也复用了，下不了程序，只好用串口ISP模式清空Flash，非常折腾。所以：在Demo阶段，PA13和PA14尽量不要复用为普通GPIO。

2.4 电源系统的排查要点

Demo板的电源通路一般是：USB 5V进入 → 经过二极管防反接 → 送入AMS1117-3.3线性稳压器 → 输出3.3V给MCU和其他外设供电。AMS1117最大可输出1A电流，但这是理想条件，实际工作温度一高电流能力就会明显下降。点个LED、跑个简单程序，电流消耗几十毫安，完全没问题。

排查电源是否正常的标准流程是三层递进：第一步，用万用表量AMS1117的输出脚，确认3.3V在允许范围内；第二步，量MCU的VDD引脚，确认电压确实到了芯片上；第三步，量NRST复位引脚，正常启动后应该是3.3V高电平。如果NRST被外部电容拉低或者有异常干扰，芯片会一直处于复位状态，LED自然不亮。这三步走完，八成以上的上电异常问题都能定位到具体环节。

3. 工程搭建与代码实现

3.1 标准外设库和HAL库的取舍

聊到代码实现，就绕不开用哪个固件库的问题。标准外设库（Standard Peripheral Library）是ST早期主推的库，它将寄存器操作封装成函数，但又不屏蔽底层细节，读起来非常直观。HAL库则是2014年后ST重点推广的新一代硬件抽象层库，接口更统一，配合CubeMX生成代码效率极高，但函数套函数，层层封装，调试起来相对晦涩。

2020年的这个Demo，用标准外设库的概率更大一些，因为当时HAL库虽然已经成熟，但很多老教程和参考书籍仍然是基于标准外设库写的。两者的选择逻辑很简单：学习原理、做深度定制，优先标准外设库；快速开发、做产品原型，优先HAL库。如果你以后要进大厂做量产项目，HAL库是绕不开的，因为ST已经停止维护标准外设库了；如果只是搞竞赛和毕设，标准外设库足够清爽，不易出错。

我在实际写这个Demo的代码时，用的是标准外设库风格，逻辑非常清晰：使能GPIO时钟 → 配置GPIO引脚模式 → 写高/低电平 → 延时循环。整个过程没有任何花哨的库函数嵌套，一眼看到底。

3.2 核心代码段的逐行拆解

一个完整的点灯Demo主程序，核心逻辑并不复杂，但每一行代码背后的含义值得我们反复琢磨。下面我贴一段极简的基于寄存器操作的点灯代码，方便理解底层原理：

#include "stm32f10x.h" void Delay(void) { uint32_t i = 0; for (i = 0; i < 720000; i++); } int main(void) { // 1. 开启GPIO C 端口的时钟 RCC->APB2ENR |= RCC_APB2ENR_IOPCEN; // 2. 配置PC13为推挽输出，最大速度2MHz GPIOC->CRH &= ~(0xF << 20); GPIOC->CRH |= (0x2 << 20); while (1) { GPIOC->BRR = (1 << 13); // 低电平点亮LED Delay(); GPIOC->BSRR = (1 << 13); // 高电平熄灭LED Delay(); } }

这段代码值得逐行解释。第一步，RCC->APB2ENR 这个寄存器是APB2总线外设时钟使能寄存器，你要用GPIO C端口，就必须先把它的时钟打开。这一步在标准外设库里对应的是 RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC, ENABLE)。很多新手会忘记这一步，结果程序卡死在GPIO配置死循环里，因为寄存器根本不可访问。

第二步，配置PC13的模式。GPIO C端口的引脚0到7由配置寄存器CRL控制，引脚8到15由CRH控制。PC13属于高位引脚，所以要用CRH。CRH中每个引脚占用4个配置位，PC13对应的是第20到23位，也就是bit20、bit21、bit22、bit23。先把这4位清零，再把bit20置1、bit21置0，对应的二进制是0010，即输出模式、最大速度2MHz。这里选用2MHz最大速度就够了，因为LED闪烁频率很低，没必要让引脚高速翻转。

第三步，主循环里的电平控制。BRR寄存器是“位复位寄存器”，向它的第13位写1，PC13就输出低电平，LED点亮；BSRR是“位设置寄存器”，向第13位写1，PC13输出高电平，LED熄灭。使用BRR和BSRR操作的好处是“原子化”，不会影响到其他引脚状态，比直接用ODR寄存器“读-改-写”更加安全，尤其是在中断环境中。

3.3 延时的原理与替代方案

代码里的Delay函数用的是“空循环计数”，也就是让CPU反复执行一条无意义的指令来消耗时间。在72MHz主频下，循环720000次大概能延时几百毫秒，具体时间受编译优化等级影响很大。如果开-O2优化，编译器发现循环变量没有被使用，可能直接把这个循环优化掉，Delay函数就失效了，LED会变成常亮。这个问题非常隐蔽，很多人遇到“代码没问题但效果不对”时，很难联想到是编译器优化干的坏事。

所以实际工程中，我更推荐使用定时器延时，比如利用SysTick系统滴答定时器，它正好是Cortex-M3内核自带的，不需要额外占用外设定时器，也非常精确。初始化好SysTick后，写一个Delay_ms函数，通过判断计数标志来实现精确延时，这套逻辑可以复用到后续所有需要定时的项目中。水平再高一些的朋友，可以直接用定时器的PWM输出模式，让LED实现呼吸灯效果，那需要的就不再是软件延时，而是硬件自动翻转IO了。

3.4 用HAL库实现的等价版本

考虑到很多朋友现在是用CubeMX+HAL库学习，我再贴一段HAL库风格的点灯代码，方便对比：

#include "main.h" int main(void) { HAL_Init(); SystemClock_Config(); __HAL_RCC_GPIOC_CLK_ENABLE(); GPIO_InitTypeDef GPIO_InitStruct = {0}; GPIO_InitStruct.Pin = GPIO_PIN_13; GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP; GPIO_InitStruct.Pull = GPIO_NOPULL; GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW; HAL_GPIO_Init(GPIOC, &GPIO_InitStruct); while (1) { HAL_GPIO_WritePin(GPIOC, GPIO_PIN_13, GPIO_PIN_RESET); HAL_Delay(500); HAL_GPIO_WritePin(GPIOC, GPIO_PIN_13, GPIO_PIN_SET); HAL_Delay(500); } }

这段代码的逻辑和寄存器版本完全一致，但是由CubeMX生成的初始化代码还包含了时钟树配置函数SystemClock_Config()，它会根据你在CubeMX里的配置生成HSE、PLL、总线分频这些寄存器的设定。如果没有这个时钟配置，芯片默认跑HSI内部8MHz，主频不对，延时和串口波特率都会出问题。

3.5 工程文件组织与归档习惯

回到这个压缩包的命名，"STM32F103C8_Demo_2020-10-10-LEDA.rar"，一个规范的工程归档应该包含以下文件夹：Core（核心文件，包括main.c、stm32f1xx_it.c等）、Drivers（驱动库文件，CMSIS和HAL库）、Hardware（自己写的板级外设驱动，比如led.c、key.c）、MDK-ARM或者EWARM（IDE工程文件）、Doc（说明文档和数据手册）。如果这个压缩包只有单个main.c加几个散乱的库文件，那工程可移植性就比较差；但如果是标准CubeMX生成的工程结构，拿到手就能直接用。

我自己归档工程的习惯是：每个项目压缩包内放一个readme.txt，写清楚硬件平台、引脚连接、开发环境版本、踩坑记录、烧录方式。这个习惯帮我省过无数次翻旧账的时间。比如半年后你要把Demo扩展成带串口通信的版本，翻readme就能快速回忆起当初PC13接限流电阻接LED、PA9/PA10接CH340这种细节，而不用对着原理图再猜半天。

4. 编译烧录与问题排查

4.1 error #550的完整排查路径

在Keil MDK环境下编译这个Demo，最让新手崩溃的就是文章开头提到的这个报错：

error #550: requested device stm32f103c8(stmicroelectronics) not found for target 'target 1'

这个报错翻译成人话就是：Keil在它的设备数据库里找不到STM32F103C8这个芯片。为什么找不到？因为你打开工程的时候，Keil没有加载对应的芯片包（Device Family Pack，简称DFP）。Keil MDK 5的芯片支持从安装包里剥离出来了，你需要单独从Keil官网或者Pack Installer里下载安装适合的Pack。以STM32F1系列为例，需要安装的Pack是Keil.STM32F1xx_DFP。

解决路径分四步：第一步，打开Pack Installer（一般在Keil的工具栏图标里）；第二步，在Pack列表中找到STMicroelectronics目录下的STM32F1系列，选中符合你Keil版本的那个Pack版本；第三步，点击Install安装，等待进度条走完；第四步，关闭并重新打开工程，再到魔术棒（Options for Target）里的Device选项卡确认芯片是不是变成了STM32F103C8。完成这四步，这个报错基本就消失了。

除了Pack没安装，还有两种情况会触发类似报错。一种是工程文件是从别人那里拷来的，对方用的Keil版本比你新，生成的工程文件版本高于你的软件版本，虽然能打开但设备识别会出问题；另一种是破解不完整导致IDE功能受限。这两种情况都需要升级软件版本或者重新安装。

4.2 烧录方式和驱动注意事项

烧录这个Demo最推荐的方案是ST-Link V2配合Keil的Flash Download功能。接线方式很清楚：ST-Link的SWDIO接板子的PA13，SWCLK接PA14，GND共地，3.3V接板子的3.3V引脚（如果ST-Link支持输出电压）。注意别接反，SWDIO和SWCLK接反了下载器是识别不到芯片的。接好线后，在Keil的Flash Download选项卡里选择ST-Link调试器，再勾选“Reset and Run”，这样烧录完成后芯片会自动复位运行程序，不用手动按复位键。

驱动方面，ST-Link V2在Win10以上系统基本是免驱的，插入USB后设备管理器里能看到“STLink dongle”或者“STM32 STLink”设备。如果设备管理器里出现黄色感叹号，说明驱动没装好。可以到ST官网下载最新的ST-Link驱动，或者通过ST官方工具STM32CubeProgrammer自带的驱动安装程序安装。这里插一句，现在很多国产DAP-Link也兼容CMSIS-DAP协议，Keil里选CMSIS-DAP Debugger就能用，这类调试器价格更便宜，也挺适合新手。

4.3 烧录失败常见原因

烧录失败是点灯Demo卡壳的高发区，我根据经验总结了几个高频原因：

芯片读保护被打开。如果芯片之前烧录过程序且被设置过读保护（RDP Level 1），直接用ST-Link烧录会报“Cannot access target”或者“Flash Download failed"。解决办法是用STM32CubeProgrammer连接芯片，在选项字节里把读保护级别降为Level 0，这个过程会擦除整个Flash。需要注意的是，改成Level 0后芯片会执行一次全片擦除，原来的程序就没了。

SWD引脚被占用。前面提过，如果代码里把PA13/PA14复用成普通GPIO，下载器就无法连接目标芯片。解决办法是在软件里设置烧录前复位芯片。Keil的Flash Download设置里有个“Reset under Debug”选项，勾选后每次连接前会拉低复位引脚让芯片停顿在复位状态，这样SWD引脚功能恢复默认，就能连上了。

供电不足。如果目标板用USB供电，而USB口电流输出能力弱，芯片启动过程中可能电压跌落，导致SWD连接不稳定。这种情况可以用外部稳压电源给板子单独供电，但注意共地，否则下载器无法建立参考电平。

接触不良。这一点最容易被忽略。杜邦线、面包板、牛角座这些连接件的氧化和松动会导致信号反射或中断。如果遇到时好时坏的情况，优先怀疑接触问题，重新插拔一下，并且尽量缩短SWD线缆长度，降低信号干扰。

4.4 点灯不亮，问题出在哪

如果程序烧录成功，但LED不亮，别慌，按这个顺序排查。首先确认LED的极性，板载LED丝印通常会标一个正负号或者引脚形状有区别，如果是自己搭的电路，发光二极管长脚为正极、短脚为负极，反接的话灯死活不亮。然后量LED两端电压，如果芯片引脚输出低电平时LED两端电压约等于0，说明MCU根本没拉低电平，去看代码里的引脚号是不是写错了；如果MCU引脚确实输出低电平但LED还是不亮，大概率是限流电阻焊错了或者LED本身损坏。

我还遇到过一个非常恶心的case：板上LED是低电平点亮，我在代码里也用BRR拉低，结果灯不亮，用万用表量PC13电压稳定在0.1V左右，说明引脚确实输出低了，但LED就是没反应。后来一查，原来这块板子的LED不是直接接在PC13上，而是经过了一个跳线帽，跳线帽没插上，电路根本不通。这类“既有电路设计”问题，只看原理图不实际测电路非常难发现，遇到LED不亮一定要动万用表实测。

5. 常见问题速查表与延伸建议

5.1 高频问题速查表

我把这个Demo调试过程中最常遇到的几类问题汇总成了一张表，方便你遇到时快速定位：

这张表里的问题，几乎每个都在我指导过的学生或者同事的项目里出现过，尤其是“程序烧录成功但LED不亮”这种看起来莫名其妙的问题，最后定位到硬件细节时，当事人往往会恍然大悟。所以做硬件调试，别怕用万用表，别怕看原理图，很多时候问题就藏在你以为理所当然的地方。

5.2 从点灯Demo到完整项目的扩展路径

跑通点灯Demo只是万里长征第一步，接下来你可以从以下维度逐步扩展，让项目复杂度一点点上来，这个过程就是嵌入式开发能力成长的过程。

最直接的扩展是加串口通信。C8T6的USART1在PA9（TX）和PA10（RX）上，接一个USB转TTL模块到电脑，就能用串口助手打印调试信息。这样一来，你可以把LED的状态、变量值、传感器数据实时发到电脑上，调试体验瞬间提升一个档次。

再进一步可以接OLED显示屏，用I2C或者SPI协议，显示温湿度、电压、系统运行时间。这个过程你会接触到DMA、中断、裸机状态机等进阶概念，对MCU的资源调度理解会更深入。很多人点灯之后就直接冲进FreeRTOS，我觉得没有必要，先把裸机的状态机跑熟练，理解前后台系统的优缺点，再用RTOS时就知道它在解决什么问题。

另外一个值得尝试的方向是低功耗设计。C8T6支持睡眠、停止、待机三种低功耗模式，你可以试着让系统平时处于停止模式，用外部中断唤醒，唤醒后点灯然后再次进入低功耗。这个实验对电池供电的项目特别有价值，也能帮助你理解时钟管理、电源管理这些平时不会在点灯程序里注意到的细节。

5.3 我给新手的几条实操建议

最后再分享几条自己踩过坑之后总结出来的实操建议，希望对刚起步的朋友有帮助。

第一，多读参考手册的GPIO章节。不要觉得自己只是点个灯，没必要看得那么深。但恰恰是GPIO章节里的推挽、开漏、浮空、上拉下拉这些概念，决定了你在不同电路场景下的配置选择。比如按键检测要配输入模式加内部上拉，驱动LED要配推挽输出，外接I2C设备要配开漏输出加上拉电阻。这些知识点在点灯Demo里不会全部用到，但理解了它们，你往后遇到的90%引脚配置问题都能自己解决。

第二，养成读原理图的习惯。很多朋友拿到开发板第一件事是找例程，而不是找原理图。其实开发板的原理图才是第一手资料，它告诉你每个引脚接到了什么器件、电源怎么分配、有没有跳线需要短接。看懂原理图，你就能脱离“照着例程抄引脚”的状态，真正理解为什么LED要接PC13而不是随便一个引脚。

第三，别害怕用调试器打断点。Keil和STM32CubeIDE都支持在线调试，你可以让程序在某个语句处暂停，查看变量的值、寄存器的状态、外设的状态。点灯Demo虽然简单，但你在Delay函数里打个断点，单步执行几轮，看看程序是怎么循环的，对理解计算机执行指令的流程非常有帮助。这个习惯如果从早期养成，后面调试复杂bug时会受益无穷。

第四，保存好能跑通的工程备份。我自己的习惯是每完成一个稳定可跑的里程碑，就手动拷贝一份工程到带日期的文件夹里保存，比如LedBlink_20240115_ok。这个习惯帮我避免过无数次改代码改到崩溃却找不到回退版本的尴尬。嵌入式开发里，能跑的版本比新功能值钱多了。

回到这个STM32F103C8的Demo，它的价值不在代码复杂程度，而在它打通了从硬件到软件、从编译到烧录的完整链路。认真把它吃透，你接下来的STM32学习曲线会比直接啃复杂项目平滑很多。

本文还有配套的精品资源，点击获取