简介嵌入式开发中参考例程是工程师快速上手芯片外设的重要资源。以STM32F103C8T6为例其HAL库风格代码覆盖时钟树、GPIO、串口、定时器与ADC等关键模块理解启动文件和时钟配置顺序是确保程序正确运行的前提。掌握参考例程的工程结构、调试方法与常见陷阱能显著提升从原型验证到自制PCB项目的迁移效率。本文围绕STM32F103C8T6参考例程剖析HAL库外设驱动的参数拆解并给出烧录配置、启动文件选择、BOOT引脚等避坑经验帮助开发者在实际项目中快速定位问题并沉淀可复用的固件模板。1. 拿到STM32F103C8T6开发参考例程代码先别急着编译很多人收到开发板或者克隆下一个例程包第一反应是打开工程、点编译看到“0 Error”就长舒一口气。但真正把这段STM32F103C8T6开发参考例程代码用进自己项目时串口乱码、定时器不触发、ADC读出来全是满量程这些问题一个接一个。参考例程的价值从来不是给你一段能点亮LED的代码而是给你一套每个外设“默认行为”的样本时钟配置顺序、外设初始化参数、中断回调在哪里返回。这篇文章不谈包装华丽的入门教程只讲拿到这套例程后怎么判断它靠不靠谱、怎么跑通以及从例程到自制PCB项目之间那条最容易翻车的路。适合自己画最小系统板、做原型验证或者刚开始用HAL库做产品的开发者。2. 例程代码的目录与启动链路先分清哪些文件能删、哪些不能动2.1 为什么现在的参考例程几乎都是 HAL 库风格早期的 STM32F103 参考例程多用标准外设库函数名简洁比如 GPIO_Init、USART_SendData直接操作寄存器结构体。后来 HAL 库成为主流现在的 STM32F103C8T6 开发参考例程代码基本都切到 HAL 风格原因有三一是厂商的图形化配置工具只生成 HAL 工程新开项目用旧库反而要手工迁移二是 HAL 把外设状态、超时处理、中断回调封装成统一接口换芯片型号时业务代码改动小三是例程里想查某个函数行为时HAL 源码路径清晰能直接跳到驱动文件里看寄存器赋值。但代价也很明显。HAL 代码本身占用空间比标准库大F103C8T6 只有 64KB Flash、20KB RAMHAL 全功能编译产物通常在 30KB 以上如果跑 RTOS 或者塞大量字符串会明显紧张。我的选择习惯是原型验证、快速出功能用 HAL量产资源吃紧且外设简单时把 HAL 初始化完的寄存器值固化下来删除不用的驱动分支。参考例程正好提供这个“中间态”——它能跑你才有一个可靠基准去裁剪。提示不要拿到例程就全局搜索删 HAL 代码试图省 Flash先打开 .map 文件确认实际占用再动手。2.2 参考例程目录拆解启动文件、时钟配置、外设驱动各管一段一个典型的 STM32F103C8T6 参考例程包目录结构通常由图形化配置工具生成长这样project/ ├─ Core/ │ ├─ Inc/ # 用户头文件main.h、gpio.h、usart.h │ └─ Src/ # 用户源码main.c、gpio.c、usart.c ├─ Drivers/ │ ├─ CMSIS/ # 内核寄存器定义、系统初始化、启动文件 │ └─ STM32F1xx_HAL_Driver/ # HAL 库源码按外设拆成 .c/.h ├─ MDK-ARM/ # MDK 工程文件、编译产物、烧录配置 └─ project.ioc # 图形化配置工具的工程描述文件这个目录里真正决定代码能否运行的灵魂文件是启动文件对应 C8T6 中容量芯片的是startup_stm32f103xb.s。它定义栈大小、中断向量表以及复位后调用 SystemInit 和 main 的流程。启动文件选错编译照样通过下载后就是没反应。F103C8T6 属于中容量产品如果你发现例程里放的是startup_stm32f103xe.s对应大容量芯片下载到 C8T6 上大概率跑飞。CMSIS 目录不能动它提供寄存器定义和内核抽象层。HAL_Driver 目录里不用的 .c 文件可以删除省编译时间但删之前要确认代码没有引用对应外设头文件否则编译报缺定义。MDK-ARM 目录放工程文件如果打不开多数出在 IDE 版本过旧或者编译器切换上后面章节会专门讲。整个目录里你真正频繁修改的只有 Core/Src 下的用户代码。2.3 从启动文件到 main初始化顺序决定例程能不能跑参考例程的 main 函数虽然外设不同但结构基本固定。我把最典型的骨架拆出来int main(void) { HAL_Init(); // 复位外设、配置Flash预取、初始化SysTick SystemClock_Config(); // 配置HSE - PLL - 系统时钟72MHz MX_GPIO_Init(); // 用户外设初始化GPIO、串口、定时器都在这里 while (1) { HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin); HAL_Delay(500); } }HAL_Init 做三件事复位所有外设、打开 Flash 预取缓冲、以 1ms 周期配置 SysTick。SysTick 被 HAL_Delay 使用所以不要在 HAL_Init 之前调用任何 HAL 函数。SystemClock_Config 是例程里最容易出错的地方因为它是图形化工具自动生成的新手往往忽略。F103C8T6 外部晶振常用 8MHz内部经 PLL 倍频到 72MHzvoid SystemClock_Config(void) { RCC_OscInitTypeDef RCC_OscInitStruct {0}; RCC_ClkInitTypeDef RCC_ClkInitStruct {0}; RCC_OscInitStruct.OscillatorType RCC_OSCILLATORTYPE_HSE; RCC_OscInitStruct.HSEState RCC_HSE_ON; // 开启外部8MHz晶振 RCC_OscInitStruct.HSEPredivValue RCC_HSE_PREDIV_DIV1; RCC_OscInitStruct.PLL.PLLState RCC_PLL_ON; RCC_OscInitStruct.PLL.PLLSource RCC_PLLSOURCE_HSE; RCC_OscInitStruct.PLL.PLLMUL RCC_PLL_MUL9; // 8MHz x 9 72MHz HAL_RCC_OscConfig(RCC_OscInitStruct); RCC_ClkInitStruct.ClockType RCC_CLOCKTYPE_HCLK | RCC_CLOCKTYPE_SYSCLK | RCC_CLOCKTYPE_PCLK1 | RCC_CLOCKTYPE_PCLK2; RCC_ClkInitStruct.SYSCLKSource RCC_SYSCLKSOURCE_PLLCLK; RCC_ClkInitStruct.AHBCLKDivider RCC_SYSCLK_DIV1; RCC_ClkInitStruct.APB1CLKDivider RCC_HCLK_DIV2; // APB1最高36MHz RCC_ClkInitStruct.APB2CLKDivider RCC_HCLK_DIV1; // APB2最高72MHz HAL_RCC_ClockConfig(RCC_ClkInitStruct, FLASH_LATENCY_2); }RCC_OscInitStruct 负责配置时钟源HSE_ON 表示启用外部晶振PLLMUL9 把 8MHz 倍频到 72MHz。RCC_ClkInitStruct 负责总线分频AHB 不分频APB1 分频 2 得到 36MHzAPB2 不分频保持 72MHz。这里有个特别容易踩的问题如果板子晶振不是 8MHz 而是 16MHzPLLMUL9 会把系统超频到 144MHz芯片可能直接死掉或者发热明显。改例程的第一件事永远是确认板子外部晶振频率再回来看 PLL 配置。FLASH_LATENCY_2 是 Flash 等待周期系统时钟超过 48MHz 必须设为 2否则 Flash 读取跟不上内核频率程序随机跑飞。这也是参考例程和自制板的第一个契合点时钟配置吃透后面所有外设的波特率、PWM 频率、ADC 采样时钟才有计算基准。3. 把参考例程跑起来编译、烧录与第一次断点调试的实际配置3.1 工具链选型MDK、STM32CubeIDE 与命令行 makefile 怎么选STM32F103C8T6 开发参考例程代码最常见的载体是 MDK 工程其次是 STM32CubeIDE 工程少部分给 makefile。选型标准很实际如果手头调试器是 CMSIS-DAP 类兼容设备MDK 和 CubeIDE 都能直接跑如果习惯命令行脚本做自动化编译或者想把编译过程集成到现有工具链里选 makefile 工程配 arm-none-eabi-gcc。工具链上手难度断点调试自动化集成适合场景MDK低好用一般存量工程最多中文资料多STM32CubeIDE低好用一般新开项目、免费、内置配置向导makefile GCC中需搭配调试器命令强批量编译、持续集成、模板复用我的建议是不要同时开三个工程。选定一套工具链后把例程从另外两种格式里提取出 Core 和 Drivers 目录重新建工程导入即可。例程代码本身跨编译器重点不在工程格式而在 main.c、外设初始化文件、启动文件三个要素是否配套。3.2 烧录配置里必须设对的几个关键参数无论用 MDK 还是 CubeIDE例程第一次烧录都有几个参数要检查否则会遇到目标芯片连接失败。在调试器设置里核心配置是这一组调试器类型按实际硬件选择CMSIS-DAP 或 ST-Link 兼容设备 接口SWD 连接速度1MHz ~ 4MHz Flash算法STM32F10x Med-density FlashSWD 只需要 PA13 和 PA14 两根线加上 GND。开发板上这两个引脚通常直连调试器接口但自制板要留意SWD 引脚旁边不要走高频信号线否则下载到一半报错率极高。连接速度是玄学重灾区4MHz 以下最稳面包板飞线时降到 1MHz失败率会明显下降。Flash 算法选错是另一个经典翻车点。C8T6 是 Med-density中密度64KB Flash选成 High-density 或 Low-density 都会出现下载失败或者烧完不运行。每次换例程工程我都先看这个配置项它比代码本身更容易让板子沉默。3.3 用 GPIO 翻转和调试器确认例程真的在跑很多例程自带的点灯代码能证明编译器没毛病但证明不了时钟配置和外设初始化正确。我常用的验证方式是加一个 1 秒周期的 GPIO 翻转把示波器探头放对应引脚上看真实频率// 在 main 的 while(1) 里替换原有 LED 操作 while (1) { HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_1); // PB1 翻转 HAL_Delay(500); // 500ms 延时 }如果系统时钟是 72MHz、HAL_Delay 工作正常PB1 上应该量到约 1Hz 方波占空比 50%。如果量到明显不对的频率比如接近 2Hz 或极慢基本可以断定 SystemClock_Config 里的 PLL 配置和实际晶振不匹配。没有示波器时直接用调试器下断点在 while 循环里断住全速运行再停下看 SysTick 计数值是不是每秒增长约 1000 次。这个方法不需要额外仪器确认时钟是否跑对非常快。3.4 例程下载后无反应时的排查起点代码能下载成功说明调试口正常、Flash 写入正常但不代表板子能跑。按下面顺序排查最省时间第一测 3.3V 和 GND 之间的纹波劣质 USB 转串口模块供电不足会让芯片频繁复位第二检查 BOOT0 和 BOOT1 引脚状态BOOT0 悬空时芯片可能进入系统存储器模式程序不执行第三看复位引脚 NRST 有没有上拉到 3.3V很多最小系统板复位脚悬空也能跑但周边有电机或继电器干扰时会随机复位的正是它。这三项检查完例程还不跑才需要怀疑启动文件或烧录算法。4. 例程里最该吃透的 3 类外设驱动串口、定时器与 ADC 的参数拆解4.1 串口例程从轮询方式升级到中断方式参考例程里串口通常先给轮询收发因为代码最短HAL_UART_Transmit(huart1, (uint8_t*)ready\r\n, 7, 100); // 阻塞发送超时100ms轮询方式在 while 循环里持续占用 CPU实际项目很快就会被中断方式替代。改成中断接收时关键改动是先在初始化末尾挂起接收// 串口初始化完成后开启单字节中断接收 HAL_UART_Receive_IT(huart1, rx_buf, 1); // 每收到一个字节HAL 库自动回调这个弱函数 void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART1) { rx_index (rx_index 1) % RX_BUF_SIZE; HAL_UART_Receive_IT(huart1, rx_buf[rx_index], 1); // 必须重新挂起 } }HAL_UART_Receive_IT 配置的不是等一条完整消息而是接收指定字节数后触发回调。上面例程每次只收 1 字节所以回调里必须再次调用 Receive_IT否则通信只进行一次就停摆。rx_buf 是环形缓冲区rx_index 取模避免越界这是串口例程最常见也最容易漏掉的维护点。波特率方面F103 的 USART1 挂载在 APB2 总线72MHz计算波特率时要注意分频系数。例程默认 115200、8-N-1 通常没问题但使用无源晶振时误差来自晶振本身便宜晶振误差几十 ppm高波特率下会偶发丢字节。真遇到串口乱码但代码看不出问题先量晶振频率别急着改代码。提示中断回调函数名是固定的弱函数多个外设共用回调函数时务必检查函数签名编译阶段重复定义不报错跑到运行时才异常。4.2 定时器例程PWM 频率与分辨率的冲突选型定时器例程里 PWM 应用最广。F103C8T6 的通用定时器 TIM2、TIM3、TIM4 都挂载在 APB1 总线APB1 预分频设为 2 时定时器时钟是 72MHz。PWM 频率和占空比分辨率由预分频 PSC 和自动重装载 ARR 共同决定void MX_TIM2_Init(void) { TIM_OC_InitTypeDef sConfigOC {0}; htim2.Instance TIM2; htim2.Init.Prescaler 72 - 1; // 72MHz / 72 1MHz 计数频率 htim2.Init.Period 1000 - 1; // 1MHz / 1000 1kHz PWM htim2.Init.CounterMode TIM_COUNTERMODE_UP; HAL_TIM_PWM_Init(htim2); sConfigOC.OCMode TIM_OCMODE_PWM1; sConfigOC.Pulse 500; // 占空比 500 / 1000 50% HAL_TIM_PWM_ConfigChannel(htim2, sConfigOC, TIM_CHANNEL_1); HAL_TIM_PWM_Start(htim2, TIM_CHANNEL_1); }参数说明PWM 频率 72MHz / (Prescaler1) / (Period1)。占空比分辨率由 Period1 决定周期越大分辨率越高但频率随之降低。做电机调速需要 10kHz 以上频率Period 只能取 7200 以内占空比精度约 0.014%做呼吸灯用 1kHz、Period1000 就足够。例程给的值通常偏向展示效果而不是应用需求复制到项目里务必重新计算这两个参数。定时器例程里连续更新中断的写法也值得留意。很多人初始化外设后忘记调用 HAL_TIM_Base_Start_IT中断标志永远不会置位这是定时器例程最常见的“代码对但行为不对”。4.3 ADC 例程多通道扫描与 DMA 搬数的配置顺序ADC 参考例程最容易被照抄出问题的场景是多通道采集。F103C8T6 的 ADC 是 12 位逐次逼近型采样时间、通道顺序、数据对齐都会影响结果。单通道采集的例程简单但做多路电压检测时要开扫描模式并配合 DMAvoid MX_ADC1_Init(void) { ADC_ChannelConfTypeDef sConfig {0}; hadc1.Instance ADC1; hadc1.Init.ScanConvMode ENABLE; // 多通道扫描模式 hadc1.Init.ContinuousConvMode ENABLE; // 连续转换DMA搬数必须开 hadc1.Init.NbrOfConversion 2; // 共扫描2个通道 HAL_ADC_Init(hadc1); sConfig.Channel ADC_CHANNEL_0; // PA0 sConfig.Rank ADC_REGULAR_RANK_1; // 第1个转换 HAL_ADC_ConfigChannel(hadc1, sConfig); sConfig.Channel ADC_CHANNEL_1; // PA1 sConfig.Rank ADC_REGULAR_RANK_2; // 第2个转换 HAL_ADC_ConfigChannel(hadc1, sConfig); HAL_ADC_Start_DMA(hadc1, dma_buf, 2); // 结果直接搬运到内存数组 }DMA 模式下 ADC 完成一次转换后自动把半字数据搬到 dma_bufCPU 不需要参与适合连续监测多路模拟量。ScanConvMode 决定是否逐通道扫描NbrOfConversion 必须与实际配置的通道数一致漏一个会导致数据错位。ContinuousConvMode 配合 DMA 循环模式可以达到“每个采样周期整批更新”的效果。要注意F103 的 ADC 最大输入时钟为 14MHz采样时间不足时内阻大的信号源会测出偏低电压。例程的采样周期参数在高阻信号源场景下要调大。ADC 结果的 12 位数据默认右对齐范围 0~4095。如果例程里看到结果除以 4095 再乘以 3.3这是标准换算。但做电流采样或电桥测量时零点偏移和增益误差不能只靠这个线性公式需要用标准源做两点校准参考例程不会替你算这一步。5. STM32F103C8T6 例程避坑指南6 个让板子沉默的典型问题这一章的经验来自我反复跑参考例程、改造成产品原型的过程。每条按现象、原因、解决三个步骤写方便直接对照排查。5.1 第一次能烧录第二次点击下载就提示连接失败现象新板子第一次下载例程成功跑了一会儿 LED 也亮再改代码下载时调试器报“Cannot access target”或连接错误。原因用户代码把 SWDIO 或 SWCLK 所在引脚PA13、PA14配置成了普通 GPIO 或复用功能。程序下载后立刻跑起来调试口被占用调试器自然连不上芯片。解决在调试器设置里打开 Connect under Reset 选项让调试器在复位期间连接芯片此时用户代码还没执行调试口处于默认状态。如果选项无效按住板子复位键的同时点击下载等进度条开始转动再松开。这是调试配置问题不是芯片坏了。5.2 把点灯例程的引脚从 PB1 改到 PA5 后灯就不亮了现象直接修改 main.c 里 HAL_GPIO_TogglePin 的参数或者在初始化文件里把引脚号改了重新编译下载LED 没反应。原因F103 的 GPIO 外设挂在 APB2 总线上使用前必须打开对应端口时钟。例程初始化函数里往往只开了原来那个端口的时钟改成 PA5 后没有调用开启 GPIOA 时钟的函数。解决在初始化函数里先调用__HAL_RCC_GPIOA_CLK_ENABLE()再配置 GPIOA 的引脚模式。另外确认引脚配置是GPIO_MODE_OUTPUT_PP推挽输出而不是GPIO_MODE_INPUT输入模式下读不到输出电平灯自然不亮。提示凡是例程里“复制过来就改个引脚”的操作先检查三件事——时钟开没开、模式是不是 OUTPUT_PP、引脚号和板子原理图对不对。5.3 串口助手收到的前几个字节是乱码再往后就正常现象每次上电串口输出的固定字符串前面多出几个随机字符之后的数据完全正常。原因芯片上电瞬间TXD 引脚电平不稳定或者主控和 USB 转串口模块冷启动时序不一致调试助手在双方都未稳定时就开始接收。另一个常见来源是 HAL_Init 到串口初始化完成之间有一段时间此时引脚状态未定。解决在 main 函数初始化串口前加HAL_Delay(50)等电源和复位稳定后再配置引脚。串口调试工具里不要勾选“随启动自动打开串口”先给板子上电再手动点打开。如果乱码出现在波特率切换之后优先怀疑晶振频率偏差。5.4 BOOT0 引脚悬空导致例程时跑时不跑现象代码烧录成功按复位键偶尔正常、偶尔完全没反应手碰到芯片附近引脚程序又正常了。原因F103C8T6 的 BOOT0 引脚内部没有可靠下拉。BOOT0 悬空时引脚电平受周边电场和手指影响跳到 1 时芯片从系统存储器启动跳过用户 Flash例程不执行。解决在 BOOT0 引脚接 10kΩ 下拉电阻到 GNDBOOT1 引脚同样接 10kΩ 下拉保持启动配置为从用户 Flash 启动。自制板最容易漏的就是这两个电阻例程能烧进去但板子不稳定时先查这里。5.5 在串口接收回调里调用 HAL_Delay 导致死机现象例程本身跑得好好的在 HAL_UART_RxCpltCallback 回调里加了一个 HAL_Delay 或阻塞发送结果程序卡死调试器停在 HardFault_Handler。原因SysTick 中断的优先级在 HAL 库中初始化为最低数值而串口全局中断优先级较高。串口中断正在执行回调时如果回调里调用 HAL_Delay 等待 SysTick 中断SysTick 此时无法抢占串口中断形成死锁代码卡死在等待标志位。解决不要在中断回调里调用 HAL_Delay、HAL_UART_Transmit 这类阻塞函数。回调里只做数据搬移和置标志位真正的延时和串口发送放到主循环。若必须高精度延时用独立定时器而不是 SysTick。5.6 代码编译零错误下载也显示成功但芯片没有任何反应现象例程工程编译 0 错误 0 警告下载进度条走完复位后 LED 不亮、串口无输出调试器能看到内核但程序停不下来。原因启动文件与芯片容量不匹配。F103C8T6 是中容量 64KB正确启动文件是startup_stm32f103xb.s。如果例程包保留了高容量芯片的启动文件向量表地址偏移出错复位后 PC 指针跳错位置程序直接跑飞。解决在工程设置里检查目标芯片型号是否选 STM32F103C8确认启动文件是startup_stm32f103xb.s并核对烧录算法是 STM32F10x Med-density。型号选错还会影响编译器对 Flash 容量的判断即使代码很小也可能报区域溢出。6. 把参考例程改造成个人固件模板验证方法与一个长期收益的好习惯例程跑通不是终点真正的收益来自把它沉淀成自己可复用的固件模板。我的做法是不直接复制例程文件夹到新项目而是维护一个自己的模板工程。每次从参考例程里拿到验证过的外设初始化代码用图形化配置工具重新生成一遍替换掉例程里手工写的部分。图形化工具生成的初始化函数带完整参数结构体和注释改了引脚或时钟后能再次生成比在例程里手工修改安全得多。每个外设模块在模板里都保留独立的 .c/.h 文件和一段自测代码串口模块用回环测试验证收发定时器模块用示波器确认 PWM 频率ADC 模块用精密稳压源对照采样值。验证记录直接写在源文件头部注释里记测试日期、实测数据和环境参数。这个习惯的收益在三个月后非常明显——当你需要把旧项目的外设配置迁移到新板子模板文件里的验证记录比参考手册还可靠。调试三板斧也固定下来先看寄存器值再确认外部电平最后才怀疑代码逻辑。我吃过最大的亏就是对着一个“能跑”的例程反复调 ADC 采样值最后发现是外部参考电压没接好。从那以后每个模板都先验证参考电压和 GND 的实测值再进入信号调试。这套方法看着琐碎却能让 STM32F103C8T6 例程到量产固件之间的距离缩短一大截希望帮到你。本文还有配套的精品资源点击获取
简介嵌入式开发中参考例程是工程师快速上手芯片外设的重要资源。以STM32F103C8T6为例其HAL库风格代码覆盖时钟树、GPIO、串口、定时器与ADC等关键模块理解启动文件和时钟配置顺序是确保程序正确运行的前提。掌握参考例程的工程结构、调试方法与常见陷阱能显著提升从原型验证到自制PCB项目的迁移效率。本文围绕STM32F103C8T6参考例程剖析HAL库外设驱动的参数拆解并给出烧录配置、启动文件选择、BOOT引脚等避坑经验帮助开发者在实际项目中快速定位问题并沉淀可复用的固件模板。1. 拿到STM32F103C8T6开发参考例程代码先别急着编译很多人收到开发板或者克隆下一个例程包第一反应是打开工程、点编译看到“0 Error”就长舒一口气。但真正把这段STM32F103C8T6开发参考例程代码用进自己项目时串口乱码、定时器不触发、ADC读出来全是满量程这些问题一个接一个。参考例程的价值从来不是给你一段能点亮LED的代码而是给你一套每个外设“默认行为”的样本时钟配置顺序、外设初始化参数、中断回调在哪里返回。这篇文章不谈包装华丽的入门教程只讲拿到这套例程后怎么判断它靠不靠谱、怎么跑通以及从例程到自制PCB项目之间那条最容易翻车的路。适合自己画最小系统板、做原型验证或者刚开始用HAL库做产品的开发者。2. 例程代码的目录与启动链路先分清哪些文件能删、哪些不能动2.1 为什么现在的参考例程几乎都是 HAL 库风格早期的 STM32F103 参考例程多用标准外设库函数名简洁比如 GPIO_Init、USART_SendData直接操作寄存器结构体。后来 HAL 库成为主流现在的 STM32F103C8T6 开发参考例程代码基本都切到 HAL 风格原因有三一是厂商的图形化配置工具只生成 HAL 工程新开项目用旧库反而要手工迁移二是 HAL 把外设状态、超时处理、中断回调封装成统一接口换芯片型号时业务代码改动小三是例程里想查某个函数行为时HAL 源码路径清晰能直接跳到驱动文件里看寄存器赋值。但代价也很明显。HAL 代码本身占用空间比标准库大F103C8T6 只有 64KB Flash、20KB RAMHAL 全功能编译产物通常在 30KB 以上如果跑 RTOS 或者塞大量字符串会明显紧张。我的选择习惯是原型验证、快速出功能用 HAL量产资源吃紧且外设简单时把 HAL 初始化完的寄存器值固化下来删除不用的驱动分支。参考例程正好提供这个“中间态”——它能跑你才有一个可靠基准去裁剪。提示不要拿到例程就全局搜索删 HAL 代码试图省 Flash先打开 .map 文件确认实际占用再动手。2.2 参考例程目录拆解启动文件、时钟配置、外设驱动各管一段一个典型的 STM32F103C8T6 参考例程包目录结构通常由图形化配置工具生成长这样project/ ├─ Core/ │ ├─ Inc/ # 用户头文件main.h、gpio.h、usart.h │ └─ Src/ # 用户源码main.c、gpio.c、usart.c ├─ Drivers/ │ ├─ CMSIS/ # 内核寄存器定义、系统初始化、启动文件 │ └─ STM32F1xx_HAL_Driver/ # HAL 库源码按外设拆成 .c/.h ├─ MDK-ARM/ # MDK 工程文件、编译产物、烧录配置 └─ project.ioc # 图形化配置工具的工程描述文件这个目录里真正决定代码能否运行的灵魂文件是启动文件对应 C8T6 中容量芯片的是startup_stm32f103xb.s。它定义栈大小、中断向量表以及复位后调用 SystemInit 和 main 的流程。启动文件选错编译照样通过下载后就是没反应。F103C8T6 属于中容量产品如果你发现例程里放的是startup_stm32f103xe.s对应大容量芯片下载到 C8T6 上大概率跑飞。CMSIS 目录不能动它提供寄存器定义和内核抽象层。HAL_Driver 目录里不用的 .c 文件可以删除省编译时间但删之前要确认代码没有引用对应外设头文件否则编译报缺定义。MDK-ARM 目录放工程文件如果打不开多数出在 IDE 版本过旧或者编译器切换上后面章节会专门讲。整个目录里你真正频繁修改的只有 Core/Src 下的用户代码。2.3 从启动文件到 main初始化顺序决定例程能不能跑参考例程的 main 函数虽然外设不同但结构基本固定。我把最典型的骨架拆出来int main(void) { HAL_Init(); // 复位外设、配置Flash预取、初始化SysTick SystemClock_Config(); // 配置HSE - PLL - 系统时钟72MHz MX_GPIO_Init(); // 用户外设初始化GPIO、串口、定时器都在这里 while (1) { HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin); HAL_Delay(500); } }HAL_Init 做三件事复位所有外设、打开 Flash 预取缓冲、以 1ms 周期配置 SysTick。SysTick 被 HAL_Delay 使用所以不要在 HAL_Init 之前调用任何 HAL 函数。SystemClock_Config 是例程里最容易出错的地方因为它是图形化工具自动生成的新手往往忽略。F103C8T6 外部晶振常用 8MHz内部经 PLL 倍频到 72MHzvoid SystemClock_Config(void) { RCC_OscInitTypeDef RCC_OscInitStruct {0}; RCC_ClkInitTypeDef RCC_ClkInitStruct {0}; RCC_OscInitStruct.OscillatorType RCC_OSCILLATORTYPE_HSE; RCC_OscInitStruct.HSEState RCC_HSE_ON; // 开启外部8MHz晶振 RCC_OscInitStruct.HSEPredivValue RCC_HSE_PREDIV_DIV1; RCC_OscInitStruct.PLL.PLLState RCC_PLL_ON; RCC_OscInitStruct.PLL.PLLSource RCC_PLLSOURCE_HSE; RCC_OscInitStruct.PLL.PLLMUL RCC_PLL_MUL9; // 8MHz x 9 72MHz HAL_RCC_OscConfig(RCC_OscInitStruct); RCC_ClkInitStruct.ClockType RCC_CLOCKTYPE_HCLK | RCC_CLOCKTYPE_SYSCLK | RCC_CLOCKTYPE_PCLK1 | RCC_CLOCKTYPE_PCLK2; RCC_ClkInitStruct.SYSCLKSource RCC_SYSCLKSOURCE_PLLCLK; RCC_ClkInitStruct.AHBCLKDivider RCC_SYSCLK_DIV1; RCC_ClkInitStruct.APB1CLKDivider RCC_HCLK_DIV2; // APB1最高36MHz RCC_ClkInitStruct.APB2CLKDivider RCC_HCLK_DIV1; // APB2最高72MHz HAL_RCC_ClockConfig(RCC_ClkInitStruct, FLASH_LATENCY_2); }RCC_OscInitStruct 负责配置时钟源HSE_ON 表示启用外部晶振PLLMUL9 把 8MHz 倍频到 72MHz。RCC_ClkInitStruct 负责总线分频AHB 不分频APB1 分频 2 得到 36MHzAPB2 不分频保持 72MHz。这里有个特别容易踩的问题如果板子晶振不是 8MHz 而是 16MHzPLLMUL9 会把系统超频到 144MHz芯片可能直接死掉或者发热明显。改例程的第一件事永远是确认板子外部晶振频率再回来看 PLL 配置。FLASH_LATENCY_2 是 Flash 等待周期系统时钟超过 48MHz 必须设为 2否则 Flash 读取跟不上内核频率程序随机跑飞。这也是参考例程和自制板的第一个契合点时钟配置吃透后面所有外设的波特率、PWM 频率、ADC 采样时钟才有计算基准。3. 把参考例程跑起来编译、烧录与第一次断点调试的实际配置3.1 工具链选型MDK、STM32CubeIDE 与命令行 makefile 怎么选STM32F103C8T6 开发参考例程代码最常见的载体是 MDK 工程其次是 STM32CubeIDE 工程少部分给 makefile。选型标准很实际如果手头调试器是 CMSIS-DAP 类兼容设备MDK 和 CubeIDE 都能直接跑如果习惯命令行脚本做自动化编译或者想把编译过程集成到现有工具链里选 makefile 工程配 arm-none-eabi-gcc。工具链上手难度断点调试自动化集成适合场景MDK低好用一般存量工程最多中文资料多STM32CubeIDE低好用一般新开项目、免费、内置配置向导makefile GCC中需搭配调试器命令强批量编译、持续集成、模板复用我的建议是不要同时开三个工程。选定一套工具链后把例程从另外两种格式里提取出 Core 和 Drivers 目录重新建工程导入即可。例程代码本身跨编译器重点不在工程格式而在 main.c、外设初始化文件、启动文件三个要素是否配套。3.2 烧录配置里必须设对的几个关键参数无论用 MDK 还是 CubeIDE例程第一次烧录都有几个参数要检查否则会遇到目标芯片连接失败。在调试器设置里核心配置是这一组调试器类型按实际硬件选择CMSIS-DAP 或 ST-Link 兼容设备 接口SWD 连接速度1MHz ~ 4MHz Flash算法STM32F10x Med-density FlashSWD 只需要 PA13 和 PA14 两根线加上 GND。开发板上这两个引脚通常直连调试器接口但自制板要留意SWD 引脚旁边不要走高频信号线否则下载到一半报错率极高。连接速度是玄学重灾区4MHz 以下最稳面包板飞线时降到 1MHz失败率会明显下降。Flash 算法选错是另一个经典翻车点。C8T6 是 Med-density中密度64KB Flash选成 High-density 或 Low-density 都会出现下载失败或者烧完不运行。每次换例程工程我都先看这个配置项它比代码本身更容易让板子沉默。3.3 用 GPIO 翻转和调试器确认例程真的在跑很多例程自带的点灯代码能证明编译器没毛病但证明不了时钟配置和外设初始化正确。我常用的验证方式是加一个 1 秒周期的 GPIO 翻转把示波器探头放对应引脚上看真实频率// 在 main 的 while(1) 里替换原有 LED 操作 while (1) { HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_1); // PB1 翻转 HAL_Delay(500); // 500ms 延时 }如果系统时钟是 72MHz、HAL_Delay 工作正常PB1 上应该量到约 1Hz 方波占空比 50%。如果量到明显不对的频率比如接近 2Hz 或极慢基本可以断定 SystemClock_Config 里的 PLL 配置和实际晶振不匹配。没有示波器时直接用调试器下断点在 while 循环里断住全速运行再停下看 SysTick 计数值是不是每秒增长约 1000 次。这个方法不需要额外仪器确认时钟是否跑对非常快。3.4 例程下载后无反应时的排查起点代码能下载成功说明调试口正常、Flash 写入正常但不代表板子能跑。按下面顺序排查最省时间第一测 3.3V 和 GND 之间的纹波劣质 USB 转串口模块供电不足会让芯片频繁复位第二检查 BOOT0 和 BOOT1 引脚状态BOOT0 悬空时芯片可能进入系统存储器模式程序不执行第三看复位引脚 NRST 有没有上拉到 3.3V很多最小系统板复位脚悬空也能跑但周边有电机或继电器干扰时会随机复位的正是它。这三项检查完例程还不跑才需要怀疑启动文件或烧录算法。4. 例程里最该吃透的 3 类外设驱动串口、定时器与 ADC 的参数拆解4.1 串口例程从轮询方式升级到中断方式参考例程里串口通常先给轮询收发因为代码最短HAL_UART_Transmit(huart1, (uint8_t*)ready\r\n, 7, 100); // 阻塞发送超时100ms轮询方式在 while 循环里持续占用 CPU实际项目很快就会被中断方式替代。改成中断接收时关键改动是先在初始化末尾挂起接收// 串口初始化完成后开启单字节中断接收 HAL_UART_Receive_IT(huart1, rx_buf, 1); // 每收到一个字节HAL 库自动回调这个弱函数 void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART1) { rx_index (rx_index 1) % RX_BUF_SIZE; HAL_UART_Receive_IT(huart1, rx_buf[rx_index], 1); // 必须重新挂起 } }HAL_UART_Receive_IT 配置的不是等一条完整消息而是接收指定字节数后触发回调。上面例程每次只收 1 字节所以回调里必须再次调用 Receive_IT否则通信只进行一次就停摆。rx_buf 是环形缓冲区rx_index 取模避免越界这是串口例程最常见也最容易漏掉的维护点。波特率方面F103 的 USART1 挂载在 APB2 总线72MHz计算波特率时要注意分频系数。例程默认 115200、8-N-1 通常没问题但使用无源晶振时误差来自晶振本身便宜晶振误差几十 ppm高波特率下会偶发丢字节。真遇到串口乱码但代码看不出问题先量晶振频率别急着改代码。提示中断回调函数名是固定的弱函数多个外设共用回调函数时务必检查函数签名编译阶段重复定义不报错跑到运行时才异常。4.2 定时器例程PWM 频率与分辨率的冲突选型定时器例程里 PWM 应用最广。F103C8T6 的通用定时器 TIM2、TIM3、TIM4 都挂载在 APB1 总线APB1 预分频设为 2 时定时器时钟是 72MHz。PWM 频率和占空比分辨率由预分频 PSC 和自动重装载 ARR 共同决定void MX_TIM2_Init(void) { TIM_OC_InitTypeDef sConfigOC {0}; htim2.Instance TIM2; htim2.Init.Prescaler 72 - 1; // 72MHz / 72 1MHz 计数频率 htim2.Init.Period 1000 - 1; // 1MHz / 1000 1kHz PWM htim2.Init.CounterMode TIM_COUNTERMODE_UP; HAL_TIM_PWM_Init(htim2); sConfigOC.OCMode TIM_OCMODE_PWM1; sConfigOC.Pulse 500; // 占空比 500 / 1000 50% HAL_TIM_PWM_ConfigChannel(htim2, sConfigOC, TIM_CHANNEL_1); HAL_TIM_PWM_Start(htim2, TIM_CHANNEL_1); }参数说明PWM 频率 72MHz / (Prescaler1) / (Period1)。占空比分辨率由 Period1 决定周期越大分辨率越高但频率随之降低。做电机调速需要 10kHz 以上频率Period 只能取 7200 以内占空比精度约 0.014%做呼吸灯用 1kHz、Period1000 就足够。例程给的值通常偏向展示效果而不是应用需求复制到项目里务必重新计算这两个参数。定时器例程里连续更新中断的写法也值得留意。很多人初始化外设后忘记调用 HAL_TIM_Base_Start_IT中断标志永远不会置位这是定时器例程最常见的“代码对但行为不对”。4.3 ADC 例程多通道扫描与 DMA 搬数的配置顺序ADC 参考例程最容易被照抄出问题的场景是多通道采集。F103C8T6 的 ADC 是 12 位逐次逼近型采样时间、通道顺序、数据对齐都会影响结果。单通道采集的例程简单但做多路电压检测时要开扫描模式并配合 DMAvoid MX_ADC1_Init(void) { ADC_ChannelConfTypeDef sConfig {0}; hadc1.Instance ADC1; hadc1.Init.ScanConvMode ENABLE; // 多通道扫描模式 hadc1.Init.ContinuousConvMode ENABLE; // 连续转换DMA搬数必须开 hadc1.Init.NbrOfConversion 2; // 共扫描2个通道 HAL_ADC_Init(hadc1); sConfig.Channel ADC_CHANNEL_0; // PA0 sConfig.Rank ADC_REGULAR_RANK_1; // 第1个转换 HAL_ADC_ConfigChannel(hadc1, sConfig); sConfig.Channel ADC_CHANNEL_1; // PA1 sConfig.Rank ADC_REGULAR_RANK_2; // 第2个转换 HAL_ADC_ConfigChannel(hadc1, sConfig); HAL_ADC_Start_DMA(hadc1, dma_buf, 2); // 结果直接搬运到内存数组 }DMA 模式下 ADC 完成一次转换后自动把半字数据搬到 dma_bufCPU 不需要参与适合连续监测多路模拟量。ScanConvMode 决定是否逐通道扫描NbrOfConversion 必须与实际配置的通道数一致漏一个会导致数据错位。ContinuousConvMode 配合 DMA 循环模式可以达到“每个采样周期整批更新”的效果。要注意F103 的 ADC 最大输入时钟为 14MHz采样时间不足时内阻大的信号源会测出偏低电压。例程的采样周期参数在高阻信号源场景下要调大。ADC 结果的 12 位数据默认右对齐范围 0~4095。如果例程里看到结果除以 4095 再乘以 3.3这是标准换算。但做电流采样或电桥测量时零点偏移和增益误差不能只靠这个线性公式需要用标准源做两点校准参考例程不会替你算这一步。5. STM32F103C8T6 例程避坑指南6 个让板子沉默的典型问题这一章的经验来自我反复跑参考例程、改造成产品原型的过程。每条按现象、原因、解决三个步骤写方便直接对照排查。5.1 第一次能烧录第二次点击下载就提示连接失败现象新板子第一次下载例程成功跑了一会儿 LED 也亮再改代码下载时调试器报“Cannot access target”或连接错误。原因用户代码把 SWDIO 或 SWCLK 所在引脚PA13、PA14配置成了普通 GPIO 或复用功能。程序下载后立刻跑起来调试口被占用调试器自然连不上芯片。解决在调试器设置里打开 Connect under Reset 选项让调试器在复位期间连接芯片此时用户代码还没执行调试口处于默认状态。如果选项无效按住板子复位键的同时点击下载等进度条开始转动再松开。这是调试配置问题不是芯片坏了。5.2 把点灯例程的引脚从 PB1 改到 PA5 后灯就不亮了现象直接修改 main.c 里 HAL_GPIO_TogglePin 的参数或者在初始化文件里把引脚号改了重新编译下载LED 没反应。原因F103 的 GPIO 外设挂在 APB2 总线上使用前必须打开对应端口时钟。例程初始化函数里往往只开了原来那个端口的时钟改成 PA5 后没有调用开启 GPIOA 时钟的函数。解决在初始化函数里先调用__HAL_RCC_GPIOA_CLK_ENABLE()再配置 GPIOA 的引脚模式。另外确认引脚配置是GPIO_MODE_OUTPUT_PP推挽输出而不是GPIO_MODE_INPUT输入模式下读不到输出电平灯自然不亮。提示凡是例程里“复制过来就改个引脚”的操作先检查三件事——时钟开没开、模式是不是 OUTPUT_PP、引脚号和板子原理图对不对。5.3 串口助手收到的前几个字节是乱码再往后就正常现象每次上电串口输出的固定字符串前面多出几个随机字符之后的数据完全正常。原因芯片上电瞬间TXD 引脚电平不稳定或者主控和 USB 转串口模块冷启动时序不一致调试助手在双方都未稳定时就开始接收。另一个常见来源是 HAL_Init 到串口初始化完成之间有一段时间此时引脚状态未定。解决在 main 函数初始化串口前加HAL_Delay(50)等电源和复位稳定后再配置引脚。串口调试工具里不要勾选“随启动自动打开串口”先给板子上电再手动点打开。如果乱码出现在波特率切换之后优先怀疑晶振频率偏差。5.4 BOOT0 引脚悬空导致例程时跑时不跑现象代码烧录成功按复位键偶尔正常、偶尔完全没反应手碰到芯片附近引脚程序又正常了。原因F103C8T6 的 BOOT0 引脚内部没有可靠下拉。BOOT0 悬空时引脚电平受周边电场和手指影响跳到 1 时芯片从系统存储器启动跳过用户 Flash例程不执行。解决在 BOOT0 引脚接 10kΩ 下拉电阻到 GNDBOOT1 引脚同样接 10kΩ 下拉保持启动配置为从用户 Flash 启动。自制板最容易漏的就是这两个电阻例程能烧进去但板子不稳定时先查这里。5.5 在串口接收回调里调用 HAL_Delay 导致死机现象例程本身跑得好好的在 HAL_UART_RxCpltCallback 回调里加了一个 HAL_Delay 或阻塞发送结果程序卡死调试器停在 HardFault_Handler。原因SysTick 中断的优先级在 HAL 库中初始化为最低数值而串口全局中断优先级较高。串口中断正在执行回调时如果回调里调用 HAL_Delay 等待 SysTick 中断SysTick 此时无法抢占串口中断形成死锁代码卡死在等待标志位。解决不要在中断回调里调用 HAL_Delay、HAL_UART_Transmit 这类阻塞函数。回调里只做数据搬移和置标志位真正的延时和串口发送放到主循环。若必须高精度延时用独立定时器而不是 SysTick。5.6 代码编译零错误下载也显示成功但芯片没有任何反应现象例程工程编译 0 错误 0 警告下载进度条走完复位后 LED 不亮、串口无输出调试器能看到内核但程序停不下来。原因启动文件与芯片容量不匹配。F103C8T6 是中容量 64KB正确启动文件是startup_stm32f103xb.s。如果例程包保留了高容量芯片的启动文件向量表地址偏移出错复位后 PC 指针跳错位置程序直接跑飞。解决在工程设置里检查目标芯片型号是否选 STM32F103C8确认启动文件是startup_stm32f103xb.s并核对烧录算法是 STM32F10x Med-density。型号选错还会影响编译器对 Flash 容量的判断即使代码很小也可能报区域溢出。6. 把参考例程改造成个人固件模板验证方法与一个长期收益的好习惯例程跑通不是终点真正的收益来自把它沉淀成自己可复用的固件模板。我的做法是不直接复制例程文件夹到新项目而是维护一个自己的模板工程。每次从参考例程里拿到验证过的外设初始化代码用图形化配置工具重新生成一遍替换掉例程里手工写的部分。图形化工具生成的初始化函数带完整参数结构体和注释改了引脚或时钟后能再次生成比在例程里手工修改安全得多。每个外设模块在模板里都保留独立的 .c/.h 文件和一段自测代码串口模块用回环测试验证收发定时器模块用示波器确认 PWM 频率ADC 模块用精密稳压源对照采样值。验证记录直接写在源文件头部注释里记测试日期、实测数据和环境参数。这个习惯的收益在三个月后非常明显——当你需要把旧项目的外设配置迁移到新板子模板文件里的验证记录比参考手册还可靠。调试三板斧也固定下来先看寄存器值再确认外部电平最后才怀疑代码逻辑。我吃过最大的亏就是对着一个“能跑”的例程反复调 ADC 采样值最后发现是外部参考电压没接好。从那以后每个模板都先验证参考电压和 GND 的实测值再进入信号调试。这套方法看着琐碎却能让 STM32F103C8T6 例程到量产固件之间的距离缩短一大截希望帮到你。本文还有配套的精品资源点击获取
