STM32F103C8T6入门实战：最小系统、外设与DHT11驱动开发

1. STM32F1系列为何至今仍是入门首选

1.1 一个“老掉牙”芯片的现代价值

如果你刚开始接触嵌入式开发，大概率会被各种名字绕晕：STM32F103、STM32F407、ESP32、GD32……新平台层出不穷，宣传一个比一个猛。但我要说的是，如果在2024年还有人问我“新手第一块单片机选什么”，我的答案依然不变——STM32F103C8T6，也就是STM32F1系列里最经典的型号。

这不是情怀，是实打实的产业现状。STM32F1系列基于ARM Cortex-M3内核，主频最高72MHz，Flash从16KB到512KB不等，早在2007年就发布了。到今天它确实算不上先进，但问题是，它依然在大量量产产品里服役：仪表盘、温控器、传感器网关、电机驱动板、智能家居面板……只要是不需要跑复杂算法、不追求极致功耗的场景，F1系列的性能完全够用，而且供应链成熟、价格稳定、资料多到爆炸。

我给一个真实对比：某国产开发板上一颗F103C8T6的采购价在2024年大约6到9元人民币，而一颗同级别的Cortex-M4芯片普遍在15元以上。如果你的产品方案是要做一万台，光芯片成本就差出大几万块。这就是F1系列到今天还没被淘汰的根本原因——性能恰好够用，成本低到离谱，生态庞大到省时间。

对于学习者来说，F1系列还有另一层价值：它的寄存器手册、库函数、HAL库、RTOS移植例程、各种传感器驱动代码，在网上几乎要多少有多少。遇到问题，一搜就有答案。同样是写一个DHT11温湿度传感器驱动，用F1你一天能跑通，换一个冷门芯片可能要折腾三天还找不到人问。学习阶段最贵的是时间，F1能帮你把时间花在真正重要的地方。

1.2 F1系列型号怎么选：C8T6、RCT6、ZET6的区别

很多新手拿到开发板，只知道板上印着一串“STM32F103C8T6”，但不知道这串字符到底在说什么。看懂型号命名规则，你才知道自己手里的芯片有多少资源，也才知道去查阅哪份数据手册。

以STM32F103C8T6为例，拆开来看：

• STM32：品牌系列名。
• F1：代表这是F1系列，也就是基于Cortex-M3内核的基础型产品线。
• 03：代表具体子系列，F103是增强型，比F101（基本型）多了更多定时器和通信接口。
• C：引脚数，C代表48脚，R代表64脚，V代表100脚，Z代表144脚。
• 8：Flash容量等级，8代表64KB，B代表128KB，C代表256KB，E代表512KB。
• T：封装类型，T是LQFP封装（贴片），H是BGA，U是UFQFN。
• 6：工作温度范围，6代表-40℃到85℃的工业级。

所以C8T6的意思就是：48脚、64KB Flash、LQFP贴片封装、工业级温度范围。同理，RCT6就是64脚、256KB Flash，ZET6就是144脚、512KB Flash。

选型时核心看三点：引脚数量够不够用、Flash装不装得下代码、RAM够不够跑中间变量。我列个实际对照表：

型号	引脚数	Flash	SRAM	适合场景
C8T6	48	64KB	20KB	小型传感器采集、简单控制、入门学习
RCT6	64	256KB	48KB	带显示界面、多外设接入的中型项目
ZET6	144	512KB	64KB	复杂多外设系统、需要外扩总线的项目

入门阶段选C8T6完全够了，DHT11温湿度采集、OLED显示、按键、串口通信这些经典实验全都能跑。等你做的东西复杂度起来了，再换RCT6，代码基本可以直接移植，因为F1系列整个系列的寄存器映射和库函数接口高度一致。

2. 环境搭建与最小系统设计

2.1 开发工具选型：标准库还是HAL库

新手问得最多的问题之一：“学STM32F1到底学标准外设库还是HAL库？”我的回答是：先把标准库跑熟，再切HAL库理解封装思想，但如果你只打算学一个，现阶段我建议HAL库。

为什么？因为整个行业的天平已经倒向HAL库。官方早在多年前就停止维护标准外设库，新出的CubeMX工具只生成HAL库代码。你在招聘网站上随便翻嵌入式岗位要求，写的基本都是“熟悉HAL库”而非“熟悉标准库”。现在学标准库，相当于练毛笔字之前先学刻甲骨文，虽然能加深理解，但效率太低。

不过这并不意味着标准库没有价值。F1系列的绝大多数老教程、老例程用的都是标准库，而且寄存器级的原理是相通的。我的建议是：用CubeMX + HAL库做开发，遇到不懂的底层机制再去看标准库或寄存器手册，三层交叉验证，理解最扎实。

开发工具链安装顺序，我直接给你：

1. 安装Keil MDK（或IAR，但国内Keil生态更成熟），注意版本要选支持F1系列器件包的。
2. 安装STM32CubeMX，这是图形化配置工具，用来初始化时钟、引脚、外设。
3. 在CubeMX里安装F1系列固件包，它会自动下载对应版本的HAL库。
4. 安装ST-Link驱动，这是烧录调试器的驱动，绝大多数开发板板载的就是ST-Link。

有个细节很多人忽略：CubeMX和Keil的安装路径尽量别带中文和空格，否则后面编译可能出现莫名其妙的路径报错。我踩过这个坑，项目路径带了一个“新”字，结果头文件死活找不到，排查了一下午才发现是路径编码问题。

2.2 最小系统板：从原理图看懂F1的启动条件

不管是买现成的开发板还是自己画板子，F1芯片要跑起来，硬件上必须满足几个条件。看懂这些条件，比你背一百个引脚定义都管用。

电源：F103的工作电压是2.0V到3.6V，典型值3.3V。电源要稳，纹波要小。开发板上一般会用AMS1117-3.3把USB的5V降到3.3V，自己画板的话记得在电源引脚附近放几个100nF去耦电容，每个VDD脚一个，别省。

复位电路：NRST引脚接一个10kΩ上拉电阻到3.3V，同时并联一个100nF电容到地，形成上电复位延时。这是标准接法，STM32手册里明确要求，照着画就行。

时钟源：F1需要外部晶振才能跑出72MHz主频。典型接法是8MHz晶振加两个20pF负载电容，从OSC_IN和OSC_OUT接入。有些精简板子不焊晶振，芯片也能跑，但靠的是内部HSI时钟，精度差、频率不准，做串口通信容易乱码。所以只要不是极端省成本，8MHz外部晶振一定要装。

启动模式：BOOT0和BOOT1引脚决定芯片从哪启动。BOOT0拉低（接GND）就是从用户Flash启动，这是正常模式。BOOT0拉高、BOOT1拉低是从系统存储器启动，这是ISP下载模式。新手只要记住一点：正常跑程序时BOOT0必须接低。

自己画板的话还有一个细节：VCAP引脚（F103的2脚）要接一个2.2μF电容到地，这是内核稳压器的输出，不接的话芯片直接不工作。这类“脚位坑”在数据手册的引脚描述表里都标了，立项前务必对着原理图逐脚核对。

2.3 CubeMX配置一个空工程的关键步骤

用CubeMX新建工程时，很多新手对着界面一头雾水。我拆成几步说：

1. 打开CubeMX，选择芯片型号。可以按型号搜，也可以直接勾选“F103C8T6”的框选条件。
2. 配置时钟树（Clock Configuration页签）。F1的最高主频是72MHz，外部晶振8MHz，要让PLL最终输出72MHz。典型配置：HSE选Crystal/Ceramic Resonator，PLL源选HSE，PLL倍频系数选9（8MHz × 9 = 72MHz），最后把SYSCLK选成PLLCLK。这里有个常踩的坑：如果外部晶振没焊，选HSE后时钟配置会报错，因为芯片检测不到外部时钟——这就是为什么上面强调晶振必须装。
3. 配置引脚。左侧列表选PB0、PB1等引脚，右侧图形化界面会直接高亮显示。你可以直接在图里点击引脚，弹出菜单选功能（GPIO_Output、USART1_TX等）。
4. 配置调试接口。如果不选，默认SWD可能被禁用，会导致烧录器连不上芯片。在SYS页签里Debug选项选Serial Wire。
5. 生成工程。先选Toolchain/IDE为MDK-ARM，然后设置工程名和路径，勾选“Generate peripheral initialization as a pair of .c/.h files per peripheral”，生成后打开Keil工程就能编译了。

这个过程生成的代码虽然只是空模板，但时钟初始化、GPIO初始化、串口初始化这些底层代码全给你写好了。你只需要在用户代码区（USER CODE BEGIN和USER CODE END之间）加自己的逻辑，这是HAL库开发的核心模式——框架自动生成，逻辑手动填充。

3. 核心外设的实际应用：从点灯到串口通信

3.1 GPIO的八种工作模式，别只会推挽输出

F1的GPIO端口可以配置成八种模式，但大部分教程只讲了推挽输出和上拉输入，这其实是很大的误区。理解这八种模式，是你日后排查硬件问题的基本功。

我把这八种模式分成三组：

输入类（四种）：

• 浮空输入：引脚不接上下拉，电平由外部电路决定，适合按键接法（外部已接电阻）。
• 上拉输入：内部上拉电阻接通，默认高电平，按下按键接地后变低。
• 下拉输入：内部下拉电阻接通，默认低电平，按键接VCC后变高。
• 模拟输入：引脚直接进ADC采样电路，不走数字输入缓冲器。

输出类（三种）：

• 推挽输出：可以输出强高电平和强低电平，驱动能力最强，点LED、驱动蜂鸣器都用它。
• 开漏输出：只能输出低电平，高电平要靠外部上拉。这种模式适合多个设备共享一根总线（比如I2C），也适合做电平转换——用3.3V单片机输出开漏，外部上拉到5V，就能兼容5V器件。
• 推挽复用/开漏复用：复用功能指的是定时器PWM、串口TX这类由外设模块控制的输出，模式选择跟普通推挽/开漏一样，只是输出源不同。

一句话总结配置思路：按键输入选上拉输入或下拉输入（看外部电路），LED输出选推挽输出，I2C引脚选开漏输出，ADC引脚选模拟输入。

实操中我建议所有输出引脚初始状态下先搞清楚“默认电平是什么”。点LED实验经常出现一个现象：程序明明写的是先灭灯，结果一上电LED亮了。原因就是复位后GPIO默认是浮空输入，引脚电平不定，外部电路恰好让LED导通了。解决办法是初始化时立刻把引脚配置成推挽输出并拉高或拉低，别给浮空期机会。

3.2 定时器：不仅仅是延时

F1系列内置最多7个定时器，新手最常用的是TIM2、TIM3、TIM4这样的通用定时器。很多人觉得定时器的用途就是“延时”，其实它的核心价值在于不占用CPU的精确计时。

用HAL库生成PWM波的配置过程是配置定时器的典型场景：

1. 在CubeMX里选一个定时器，比如TIM3。
2. Clock Source选Internal Clock。
3. 在Parameter Settings里设Prescaler（预分频值）和Counter Period（重装载值）。这两个参数决定了PWM频率：PWM频率 = 定时器时钟 / (预分频值+1) / (重装载值+1)。比如定时器时钟72MHz，想输出1kHz的PWM，可以设预分频71、重装载999，这样就是72MHz / 72 / 1000 = 1kHz，占空比在Pulse参数里设，比如500就是50%。
4. PWM Generation CHx选择Enable，然后在代码里调用HAL_TIM_PWM_Start启动。

这个配置过程关键在于理解“预分频分的是源时钟频率，重装载值决定的是计数周期”。拿秒表打比方：预分频相当于把1秒切成100份，重装载值相当于设定“数到多少下算一轮”。

实际项目里，我用PWM做过LED呼吸灯、蜂鸣器音乐、电机调速，本质上都是调整占空比。F103最多能同时输出多路独立PWM，做双电机差速驱动、RGB全彩灯这种场景非常顺手。

3.3 串口通信：printf重定向的经典写法

串口是嵌入式开发最重要的调试手段，通过串口把芯片里的数据打印到电脑上，比用仿真器盯着寄存器直观得多。F1的USART1挂在APB2总线上，时钟频率就是72MHz，其他USART挂在APB1上，时钟频率36MHz——这个差异在计算波特率误差时会用到。

CubeMX里配置USART1为异步模式，波特率设115200，数据位8、停止位1、无校验。生成代码后，HAL_UART_Transmit是阻塞发送，HAL_UART_Receive_IT是中断接收。但直接用这两个函数打印调试信息很啰嗦，所以大家都会做printf重定向：

/* 在 usart.c 里添加 */ #include <stdio.h> int fputc(int ch, FILE *f) { HAL_UART_Transmit(&huart1, (uint8_t *)&ch, 1, 0xFFFF); return ch; }

然后在Keil里勾选“Use MicroLIB”，printf就能直接往串口输出。开启MicroLIB是因为它裁剪了大量标准库的底层实现，节省Flash开销，重新定向也简单。

但要注意，阻塞式发送有个问题：如果对端没接、串口线断了，HAL_UART_Transmit会一直等到超时，把CPU卡住。所以我调试时的习惯是：正式版代码里所有发送函数的超时时间都设成短值（比如100ms），宁可偶尔丢一条日志，也别让系统卡死。串口接收则建议用中断方式，配合环形缓冲区做数据缓存。

4. DHT11温湿度传感器实战：协议解析与驱动开发

4.1 为什么选DHT11做第一个传感器项目

DHT11是一款数字温湿度传感器，单总线协议，一条数据线既能发送又能接收。它的测温范围0到50℃，湿度20%到90%RH，精度分别是±2℃和±5%RH。从参数看，它在传感器家族里只能算“能用”，但它的教学价值极高：一个器件封装了时序控制、位解析、校验算法、GPIO方向切换这四大嵌入式核心技能。而且它的价格很便宜，单颗大约两三块钱，适合学生批量练习。

和同类的DHT22/AM2302相比，DHT11精度低、采样周期长（最少1秒读一次），但胜在协议简单、容错强、文档丰富。学习单总线协议，从DHT11入手是最平滑的路径。

4.2 单总线时序：读懂波形才算入门

DHT11的通信协议是严格的时序协议，主机（STM32）主动发起一次读操作，传感器返回40位数据，包含湿度整数、湿度小数、温度整数、温度小数、校验和。

完整时序拆解：

1. 主机发起起始信号：主机先把数据线拉低，至少保持18ms（典型值20ms）。这是为了让DHT11内部完成初始化。拉低期间，DHT11处于待命状态。
2. 主机释放总线：拉低结束后主机把引脚切换为上拉输入（或者输入浮空），释放总线。此时DHT11会在几十微秒后把总线拉低作为响应信号，然后拉高再拉低，表示进入数据发送状态。
3. 读取40位数据：每位数据由一个低电平和一个高电平组成。低电平的时间基本固定（约50μs），高电平的宽度决定数据值——高电平约26到28μs表示“0”，约70μs表示“1”。
4. 校验：前4个字节是数据，第5个字节是校验。校验值为前4个字节之和的低8位，如果对不上，这次数据就丢弃。

整个过程用逻辑分析仪或者示波器看最直观。没有示波器的话，也可以在STM32代码里记录引脚跳变的时间点，然后推算出每个位的宽度。我最初调试时就是靠串口打印电平跳变间隔，一点一点摸清了时序。

4.3 代码实现：从延时函数到精确微秒级控制

DHT11驱动最核心的难点在于微秒级延时的精确性。HAL库的HAL_Delay最小粒度是1ms，根本不够用，所以我们要自己实现一个US级延时。

老项目里最常见的写法是用SysTick做us延时：

void delay_us(uint32_t nus) { uint32_t temp; SysTick->LOAD = nus * 72; /* 72MHz主频，1us需要72个时钟周期 */ SysTick->VAL = 0; SysTick->CTRL = 0x01; /* 使能SysTick，使用HCLK作为时钟源 */ while(!(SysTick->CTRL & (1 << 16))); /* 等待COUNTFLAG置位 */ SysTick->CTRL = 0; }

这里有个大坑：SysTick是Cortex-M3内核里专门做延时的定时器，但HAL库启动后，HAL_Delay已经占用了SysTick的中断。如果你同时用SysTick做us延时，会发现HAL_Delay失效或者延时时间完全不对。解决办法是：

• 方案一：用TIM定时器做us延时（一个TIM专门做延时，不参与其他功能）。
• 方案二：关掉SysTick中断，裸操作SysTick做延时，但这样HAL_Delay就不能用了。
• 方案三：直接用ARM内核提供的DWT（Data Watchpoint and Trace）模块做高精度延时，不依赖SysTick。

我实际项目里推荐方案三，DWT是CoreSight调试组件的组成部分，只要使能了DWT的周期计数功能，就能获取CPU周期数，精度极高，而且不影响SysTick：

static void DWT_Init(void) { CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk; DWT->CYCCNT = 0; DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk; } void delay_us(uint32_t us) { uint32_t start = DWT->CYCCNT; uint32_t ticks = us * 72; /* 72MHz */ while ((DWT->CYCCNT - start) < ticks); }

DHT11的完整读流程伪代码如下：

uint8_t DHT11_ReadData(uint8_t *temp, uint8_t *humi) { uint8_t data[5] = {0}; /* 1. 主机拉低起始信号，20ms */ DHT11_Pin_Output(); HAL_GPIO_WritePin(DHT11_GPIO_Port, DHT11_Pin, GPIO_PIN_RESET); delay_ms(20); /* 2. 释放总线，切换输入模式 */ HAL_GPIO_WritePin(DHT11_GPIO_Port, DHT11_Pin, GPIO_PIN_SET); DHT11_Pin_Input(); delay_us(40); /* 等待DHT11响应 */ /* 3. 检查响应：先低后高 */ if (HAL_GPIO_ReadPin(DHT11_Port, DHT11_Pin) == GPIO_PIN_SET) { /* 没收到响应，返回错误 */ return 1; } while (HAL_GPIO_ReadPin(DHT11_Port, DHT11_Pin) == GPIO_PIN_RESET); /* 等待低电平结束 */ while (HAL_GPIO_ReadPin(DHT11_Port, DHT11_Pin) == GPIO_PIN_SET); /* 等待高电平结束 */ /* 4. 读取40位数据 */ for (int i = 0; i < 40; i++) { while (HAL_GPIO_ReadPin(DHT11_Port, DHT11_Pin) == GPIO_PIN_RESET); /* 跳过起始低电平 */ delay_us(40); /* 延时到高电平中段 */ if (HAL_GPIO_ReadPin(DHT11_Port, DHT11_Pin) == GPIO_PIN_SET) { data[i/8] = (data[i/8] << 1) | 1; /* 高电平宽，判定为1 */ } else { data[i/8] = (data[i/8] << 1) | 0; /* 高电平窄，判定为0 */ } while (HAL_GPIO_ReadPin(DHT11_Port, DHT11_Pin) == GPIO_PIN_SET); /* 等待高电平结束 */ } /* 5. 校验 */ if ((data[0] + data[1] + data[2] + data[3]) == data[4]) { *humi = data[0]; *temp = data[2]; return 0; } return 1; }

读取“1”和“0”的核心技巧是：利用固定延时采样。每位数据的高电平持续26到70μs不等，我在高电平起点延迟40μs再采样：如果此时引脚还是高，说明是高电平宽的那种，数据位为1；如果已经变低了，说明高电平早早就结束了，数据位为0。这就是单总线协议里最经典的“延时采样法”。

4.4 驱动优化与常见设计问题

DHT11读一次至少要花20ms起始信号加几十微秒数据读取，整个过程是阻塞式的。在实际工程里，如果你的主循环还有其他实时任务（比如PWM控制、按键扫描），每秒钟都阻塞几十毫秒是不可接受的。

我的优化思路是把驱动拆成状态机：主循环里只做状态迁移，DHT11的起始信号、响应等待、数据读取拆成多个步骤，每个步骤利用定时器轮询或外部中断触发。这样CPU不会被长时间占用，系统响应更流畅。

另外要注意，DHT11的官方资料要求两次读取间隔至少1秒。这是因为DHT11内部的采集周期是1到2秒，读太频繁拿到的还是上一次缓存的数据，而且会给传感器造成额外压力。

还有一个容易踩的硬件坑：DHT11的数据线需要接一个上拉电阻（典型值4.7kΩ到10kΩ）到VCC。传感器数据手册里的单总线协议要求空闲状态为高电平，没有上拉电阻，引脚容易受干扰，读取会偶尔出错。很多开发板板上集成了这个电阻，但自己插面包板时经常漏掉。

5. 常见问题与排查技巧实录

5.1 烧录失败：核心板连不上芯片

我见过太多新手卡在这一步：点了Keil的下载按钮，弹窗提示“Cannot access target”，或者“No target connected”。芯片没烧录前，排查顺序很重要：

• 查驱动：设备管理器里看ST-Link有没有被识别，没识别就装驱动。绿色感叹号说明驱动有问题。
• 查连接：确认SWDIO、SWCLK、GND三根线接对了没有。ST-Link排线的线序各家可能有差异，别凭颜色猜。
• 查BOOT0：如果BOOT0被拉高，芯片处于ISP模式，SWD调试口是访问不到用户Flash的。把BOOT0跳线帽接到GND再试。
• 查复位：如果开发板上复位按键卡死了，芯片一直处于复位状态，SWD也是连不上的。把复位引脚外接的电容问题也纳入排查范围。

还有一个高阶情况：你在CubeMX配置工程时没勾选Serial Wire，生成代码跑起来之后，SWD引脚被复用成了普通GPIO。这时候芯片里已经跑起新程序了，调试口自然就失效了。解决办法是按住复位键，点下载，在松开的瞬间让下载器抢到控制权——这个“按住复位连烧录”的手法，遇到调试口被占用时非常管用。

5.2 串口乱码：时钟才是真凶

串口输出乱码是出现频率第二高的问题。多数人第一反应是“波特率不对”，其实大部分乱码的根源在于串口波特率和实际时钟不匹配。

比如你配置CubeMX时选了8MHz外部晶振，但板子上实际焊的是12MHz的晶振，或者根本没焊晶振、跑的是内部HSI的8MHz，都会导致串口波特率偏差。HSI的精度本身只有±1%左右，通讯一长就丢字节。

排查方法很简单：用示波器或逻辑分析仪看TX引脚的波形，数一下1秒内有多少个起始位，就能反推实际频率。没有示波器的话，也可以换几个波特率试，如果每个波特率都乱码，基本可以锁定时钟配置有问题。

另外要提醒一点：CubeMX的Clock Configuration页签里，如果你输入的晶振值和实际不符，生成的时钟树代码会自动计算PLL分频系数，但HSI和HSE选错，主频就差之千里。养成好习惯：项目开始时先把晶振频率标到CubeMX里，然后用HAL_GetTick频率间接验证主频——比如用HAL_Delay(1000)实测1秒，如果实际跑了2秒，主频就慢了整整一倍。

5.3 DHT11读数固定不变或全为0

读数固定不变，或者一直是0%，这种问题很典型。我按可能性从大到小排序：

• 接线错误：数据线接到了ADC引脚或没配置成GPIO输出/输入模式。检查CubeMX里的引脚模式。
• 上拉电阻缺失：数据线对VCC没有上拉，传感器输出的高电平不够，读回来全是0。
• 供电不足：DHT11供电电压要求3.3V到5.5V，但传感器数据线电平要和MCU一致。如果传感器供电5V，数据线直接连3.3V单片机引脚，逻辑电平可能不兼容。
• 延时不准：us延时函数在主频不是72MHz的板上（比如你改了时钟），所有延时成比例偏移，时序就乱了。

DHT11是一个“能跑就好好跑，跑不了就一脸懵”的器件。我自己的调试顺序是：先拿USB转TTL模块接电脑，用一个串口助手配合别人的上位机软件直接读DHT11数据，如果独立于单片机时传感器工作正常，那就把问题锁定在STM32侧，把注意力放在时序和引脚配置上。

5.4 问题速查表汇总

现象	可能原因	排查方向
烧录报No target	SWD引脚被复用、驱动缺失、接线错误	按住复位烧录、重装驱动、核对SWD线序
串口全部乱码	主频和CubeMX配置不一致、晶振没焊	检查时钟树配置、用示波器看波形
程序不运行	启动模式不对、电源不稳、VCAP电容缺失	检查BOOT0电平、万用表测3.3V、补2.2μF电容
LED完全不亮	引脚配置错误、LED极性接反	改推挽输出、确认限流电阻和正负极
DHT11无响应	起始信号太短、上拉缺失、引脚模式错误	延长低电平时间到20ms、加上拉电阻
PWM没波形	TIM时钟未使能、PWM通道未启动	检查CubeMX里PWM Generation是否选中、代码里是否调用Start函数
中断不进	NVIC优先级没配置、中断标志没清除	检查CubeMX里NVIC Settings、代码里清中断标志

6. 调试工具与方法进阶

6.1 用好调试器：断点、变量监视与Call Stack

很多新手写完代码直接烧录，然后靠串口打印数据来“猜”问题。但有些逻辑问题，尤其是指针越界、数组溢出、任务卡死，靠printf是定位不出来的。这时候必须用调试器。

Keil里点Debug按钮进入仿真模式，你会发现代码停在main函数开头。按F5全速运行，程序就跑起来了。在三行代码左侧点击可以打断点，运行到断点处暂停。全速运行中按停止键，程序会停在当前执行位置，你可以看一眼调用栈（Call Stack）——如果函数调用层级里出现了HardFaultHandler，说明要么访问了非法地址，要么执行了非法指令。

看变量值是最实用的功能。在Watch窗口里添加变量名，就能实时看到它的值变了没。尤其调试DHT11时序，把引脚读到的每个电平、计数的中间变量加进去，跑一圈下来就知道哪里不对了。配合Edit菜单下Memory窗口，可以查看指定地址的原始内存内容，排查数组越界非常高效。

有几次我遇到程序莫名跳到HardFault，直接在调试器的Peripherals菜单里打开Fault Reports，里面会把出错时的寄存器状态列出来，SCB->HFSR、SCB->CFSR这些寄存器的具体信息能直接告诉你是总线错误还是用法错误，省去一晚上瞎猜的时间。

6.2 逻辑分析仪：嵌入式调试的第二双眼睛

USB逻辑分析仪如今很便宜，百元级别就能买到一个16通道、采样率100MHz左右的设备，对F1开发来说完全够用。

调试DHT11这个项目，逻辑分析仪的价值是决定性的。把DHT11的数据线接到逻辑分析仪上，在软件里配置好协议解析（如果支持DHT11协议解码，直接就能看到温湿度数值；不支持的话，用普通方波模式也能看清每位的高电平宽度），一眼就能看出时序哪里不对。

比如我第一次调试时发现数据全是乱的，用逻辑分析仪一看，才发现起始信号的拉低时间只有2ms而不是20ms，DHT11根本没被唤醒。这种肉眼在代码里永远找不出问题的bug，用仪器几秒钟就水落石出。

我还习惯用逻辑分析仪验证PWM波形和串口波特率。串口乱码问题，接上分析仪一看TX波形，数一下一位高电平的持续时间，就知道波特率偏差多少。如果你做DHT11这类要求严格时序的项目，逻辑分析仪基本是标配。

6.3 从裸机到带操作系统的平稳过渡

跑通F1裸机开发后，下一个台阶往往是引入RTOS（实时操作系统）。STM32F1系列对FreeRTOS支持非常成熟，官方甚至提供了适配好的例程。

为什么要上RTOS？一个简单的例子：系统里同时有DHT11采集（阻塞20ms）、OLED刷新（阻塞几十毫秒）、按键扫描、串口上报，用裸机轮询全体现在代码里就是一团乱麻。上了FreeRTOS后，为每个任务分配一个独立的代码空间和栈空间，代码结构瞬间清晰，维护起来也容易。

在CubeMX里启用FreeRTOS很简单，配置完成后会自动生成任务创建代码。但要注意两件事：

• 栈大小分配：每个任务都要单独分配栈空间。DHT11任务如果用了完整的printf（带浮点），栈很可能需要512字（Word），否则会栈溢出。栈溢出在F103上往往表现成“随机死机”，极难排查。
• 临界区与优先级：DHT11时序读取需要关中断保护，但在FreeRTOS里关中断可能导致系统调度的tick丢失，影响其他任务。更稳的做法是给DHT11任务一个较高优先级，让它在调度周期内独立完成时序读取。

我个人的路径建议是：先裸机把外设都玩一遍，写DHT11时踩一遍时序坑，然后再上FreeRTOS，把所有传感器任务模块化拆分。这样你对系统的理解才是立体的，出了问题也从根上拎得清。

7. 写在最后的几点实战心得

7.1 新手最容易忽视的“硬件思维”

做嵌入式开发，很容易陷入“代码决定一切”的思维误区。但F1系列的开发经历告诉我，一半以上的诡异问题出在硬件。电源纹波大导致ADC采样跳变、杜邦线接触不良导致I2C偶尔通信失败、晶振负载电容不匹配导致时钟频率偏高——这些都不是写代码能修好的。

我给新手的建议是，实验桌上必备三样东西：数字万用表、逻辑分析仪、常用规格的电阻电容物料盒。花几十块钱，能帮你省下几百个小时的排查时间。尤其是F1这种“老”芯片，它的配套教程和资料虽然多，但很多资料年代久远，当年作者用的板子和你的可能不一样，引脚定义、晶振频率、甚至Flash大小都可能对不上，这时候靠仪器实测比靠文档猜靠谱得多。

7.2 学习F1系列的高效路径

梳理一下我认为效率最高的学习顺序：

• 第一步：C语言基础过关，指针和结构体会用，数组溢出这种低级错误能主动避免。
• 第二步：点灯、按键、中断、定时器、串口这五个基础实验都亲手跑一遍，不要只看教程视频。
• 第三步：用一个综合项目贯穿所学，DHT11温湿度采集加OLED显示加串口上报就非常合适。
• 第四步：把项目代码重构，引入状态机设计模式，让逻辑更清晰。
• 第五步：引入FreeRTOS，把裸机项目移植成多任务结构。
• 第六步：如果后面要做物联网方向，把ESP8266或ESP32作为Wi-Fi模块挂到F1上，走MQTT协议上报数据。

这六步走下来，F1从入门到熟练大约需要两到三个月。过程中你一定要自己画一次PCB，哪怕只是做一个最小系统板加LED，画板、打样、焊接、调试这套完整流程走一遍，收获远大于纯用现成开发板。

7.3 为什么我会一直推荐F1作为第一颗MCU

最近几年总有人问我，既然ARM新的Cortex-M0+芯片更便宜，为什么入门还推荐F1？我的看法是：F1不是性能最好的，但它是资料密度、社区成熟度和成本之间平衡最好的那个点。它的资料体系是所有MCU里最完整的，它的坑几乎全部被前人踩平了，它的库函数设计直接影响后续F4、H7等其他系列的学习路径。

我现在做项目，高算力的活交给高性能芯片，简单控制任务依然交给F1。它不是那种在参数表上闪闪发光的芯片，但就像工具箱里的那把最常用的螺丝刀，平时想不起它的存在，真要用时顺手又踏实。这颗芯片教给我的，不只是寄存器和外设怎么用，更是一套“从芯片手册读取信息、用仪器验证猜想、靠逻辑拆解问题”的底层方法论。这套东西，换到任何MCU平台都通用。