1. 为什么STM32F1至今仍是入门嵌入式的首选

如果你在电子论坛或者技术群里问一句"新手学单片机选什么"，十个人里至少有六个会告诉你从STM32F1系列开始。这个答案从十年前延续到今天，热度依然没有消退。STM32F1是意法半导体基于ARM Cortex-M3内核推出的32位微控制器家族，最经典的型号如STM32F103C8T6，也就是大家常说的"蓝板"或"最小系统板"，几十块钱就能买到一块，配套的教程、例程、开源项目铺天盖地。它解决的核心问题是：让没有太多电子基础的人，也能用相对低的成本、相对短的时间，跑通从点灯到传感器采集再到通信控制的完整链路。

我接触STM32F1是从一块STM32F103C8T6最小系统板开始的，当时手头只有一个DHT11温湿度传感器和几根杜邦线。目标很简单：把温湿度数据读出来，显示在串口助手上。听起来不难，但真正动手之后才发现，光是时钟配置、GPIO模式选择、DHT11的单总线时序这几件事，就足够让一个新手折腾好几天。也正因为如此，我后来把踩过的坑、验证过的代码、以及那些教程里往往一笔带过的细节整理下来，形成了这篇内容。

这篇文章适合三类人：第一类是刚学完C语言、想找一个能真正动手的32位平台练手的在校学生；第二类是做硬件产品原型、需要快速验证传感器方案的工程师；第三类是从51单片机转过来、想搞清楚STM32到底比8位机强在哪里的爱好者。我会围绕STM32F1这个平台，结合DHT11温湿度采集这个具体场景，把选型逻辑、开发环境搭建、GPIO与时钟原理、单总线时序实现、串口调试、常见故障排查这些内容讲透。读完之后，你应该能独立完成一个"STM32F1+DHT11+串口输出"的完整小项目，并且理解每一步背后的原因，而不是照抄代码。

2. STM32F1的家族谱系与选型逻辑

2.1 从F103到F107：型号后缀到底代表什么

STM32F1系列并不是一个单一型号，而是一个包含多个子系列的产品线。常见的子系列有STM32F100、STM32F101、STM32F102、STM32F103、STM32F105/107等。它们的内核都是Cortex-M3，但主频、外设资源、存储容量、封装引脚数差别很大。以最热门的STM32F103为例，它的主频是72MHz，内置Flash从16KB到1MB不等，SRAM从6KB到96KB，封装从LQFP48到LQFP144都有。型号命名规则里，STM32F103C8T6这串字符其实包含了大量信息：F103是子系列，C代表48引脚，8代表64KB Flash，T代表LQFP封装，6代表工业级温度范围-40到85摄氏度。

为什么新手普遍推荐C8T6这个型号？原因很实际。第一，48引脚足够引出常用的GPIO、USART、I2C、SPI、ADC，做小项目完全够用；第二，64KB Flash和20KB SRAM对于跑裸机程序、驱动几个传感器来说绰绰有余；第三，它的价格极低，国产替代品也很多，烧了也不心疼；第四，社区资源最丰富，你遇到的几乎任何问题，网上都能搜到基于C8T6的讨论。相比之下，F107带有以太网和USB OTG，适合做网络通信类项目，但对新手来说外设复杂度高，调试成本也高，不建议一上来就碰。

选型的时候有一个容易被忽略的点：Flash容量和SRAM容量要留出余量。很多人觉得64KB写不了多少代码，但实际上如果你用了HAL库、加了printf重定向、再挂一个文件系统，Flash占用会迅速逼近上限。我的经验是，裸机项目至少留30%的Flash余量，RTOS项目至少留50%。如果预算允许，直接上C8T6的升级版RBT6（128KB Flash、20KB SRAM）会更从容。

2.2 最小系统板上那些容易被忽视的电路

拿到一块STM32F103C8T6最小系统板，大多数人第一眼看到的是那颗芯片、一个Micro USB口、一个复位按键、一个BOOT跳线帽，还有几排排针。但真正决定这块板子能不能稳定工作的，是几个不起眼的电路细节。首先是供电，STM32F1的VDD范围是2.0V到3.6V，典型值3.3V。最小系统板通常通过USB的5V经过一个LDO稳压到3.3V，这个LDO的压差和电流能力很关键。如果你外接的传感器或者显示屏功耗较大，LDO发热会导致电压跌落，芯片就会莫名其妙复位。

其次是BOOT引脚。STM32F1的BOOT0和BOOT1决定了芯片上电后从哪里启动。BOOT0接低电平、BOOT1任意，是从主Flash启动，这是正常运行模式；BOOT0接高电平、BOOT1接低，是从系统存储器启动，也就是串口下载模式。很多新手烧录失败，就是因为BOOT跳线帽没有拨到正确位置。我的习惯是，下载程序时把BOOT0拨到1，按一下复位，下载完成后再拨回0，再按复位。虽然有些下载器支持自动控制BOOT引脚，但手动操作最稳妥。

还有一个细节是晶振。最小系统板通常板载一个8MHz的外部高速晶振（HSE），配合内部PLL倍频到72MHz。如果晶振旁边的负载电容不匹配，或者晶振质量差，系统时钟就起不来，程序会卡在时钟初始化里。判断方法很简单：用示波器测晶振引脚，看有没有8MHz的正弦波。没有示波器的话，可以写一个最简单的GPIO翻转程序，如果LED闪烁频率明显不对，或者根本不闪，就要怀疑时钟配置。我遇到过一块板子，晶振虚焊，程序一直跑在内部8MHz RC振荡器上，导致串口波特率偏差巨大，收上来的全是乱码。

2.3 开发工具链的选择：Keil、IAR还是STM32CubeIDE

工具链的选择直接决定了你后续开发的效率。目前主流的STM32F1开发环境有三类：Keil MDK、IAR EWARM、STM32CubeIDE。Keil MDK在国内用户最多，教程最全，编译器优化做得不错，但它是商业软件，代码超过32KB就需要授权。IAR的编译效率很高，调试功能强，但界面相对复杂，授权费用也高。STM32CubeIDE是ST官方推出的免费工具，基于Eclipse和GCC，集成了CubeMX配置工具，可以直接生成初始化代码，对新手非常友好。

我个人的建议是：如果你在学校或者公司已经有Keil的授权，继续用Keil没问题，生态成熟，遇到问题好搜答案。如果你是个人学习、不想花钱，直接上STM32CubeIDE，它把引脚配置、时钟树、外设初始化都图形化了，能帮你省掉大量查手册的时间。不过要注意，CubeIDE生成的HAL库代码体积偏大，对于Flash只有64KB的C8T6来说，有时候会显得紧张。这时候可以改用LL库（Low Layer），它更接近寄存器操作，代码效率高，但需要你对底层有一定了解。

还有一个绕不开的话题是下载器。ST-Link是官方调试器，支持SWD接口，能下载能调试，价格也不贵，是首选。J-Link性能更强，但正版价格高，盗版固件容易掉。串口下载（通过BOOT0进入系统存储器）是最省钱的方案，只需要一个USB转TTL模块，但只能下载不能调试，而且每次都要手动拨BOOT跳线，效率低。我的建议是，既然要学STM32，ST-Link是值得投资的，几十块钱能让你少折腾很多。

3. 用DHT11打通第一个传感器采集链路

3.1 DHT11的单总线协议为什么容易读失败

DHT11是一款廉价的温湿度传感器，测量范围温度0到50摄氏度、湿度20%到90%RH，精度分别是正负2摄氏度和正负5%RH。它的通信方式是单总线，也就是一根数据线同时负责发送和接收。这种设计省引脚，但对时序要求极其严格。DHT11的通信过程是：主机拉低总线至少18毫秒作为起始信号，然后释放总线，DHT11响应后依次发送40位数据，包括湿度整数、湿度小数、温度整数、温度小数和校验和。

问题就出在这个时序上。DHT11的每一位数据用高电平的持续时间来区分0和1：高电平持续26到28微秒表示0，持续70微秒表示1。如果你的延时函数不准确，或者中途被中断打断，读出来的数据就会错位。我最初用HAL_Delay做微秒级延时，结果完全读不到数据，因为HAL_Delay的最小分辨率是毫秒，根本没法产生26微秒的精确延时。后来改用定时器计数或者简单的循环延时，才把时序对上。

另一个坑是DHT11的响应速度。它上电后需要1秒左右的稳定时间，两次采集之间至少间隔1秒，否则数据会漂移。很多人写代码时在while循环里连续读，结果第二次开始全是0或者校验失败。正确的做法是采集一次后延时至少1秒再采集下一次。还有，DHT11对电源噪声比较敏感，如果和电机、继电器共用电源，读数会跳变。我一般会在DHT11的VCC和GND之间并一个100nF的电容，效果立竿见影。

3.2 GPIO模式配置：开漏输出与浮空输入的切换时机

STM32F1的GPIO有八种模式：输入浮空、输入上拉、输入下拉、模拟输入、开漏输出、推挽输出、开漏复用、推挽复用。在DHT11的单总线通信中，主机需要在输出和输入之间切换。起始信号阶段，主机要拉低总线，这时候GPIO配置为推挽输出，输出低电平。释放总线后，主机要读取DHT11的响应，这时候GPIO必须切换为输入模式，否则主机的输出驱动器会干扰总线电平。

这里有一个细节：切换模式时要不要重新配置上拉电阻？DHT11的数据线通常需要外接一个4.7k到10k的上拉电阻到3.3V。如果外部已经有上拉电阻，GPIO配置为浮空输入即可；如果没有外部上拉，就要配置为输入上拉。我见过有人既接了外部上拉，又在代码里开了内部上拉，结果总线被拉得太强，DHT11拉不低，通信失败。所以配置之前一定要确认硬件上有没有上拉电阻。

切换模式的代码顺序也很重要。正确的做法是：先把GPIO配置为输出，拉低至少18毫秒，然后拉高，紧接着把GPIO配置为输入，再开始检测DHT11的响应。如果先配置为输入再拉高，中间会有一个短暂的高阻态，总线电平不确定，DHT11可能误判。这个顺序问题在教程里往往被一笔带过，但实际调试时就是它导致读不到数据。

3.3 微秒级延时的三种实现方式与精度对比

DHT11的时序要求微秒级精度，而STM32F1的SysTick默认配置是1毫秒中断，HAL_Delay只能提供毫秒延时。要产生微秒延时，常见有三种方法。第一种是空循环延时，用for或者while循环消耗CPU周期。这种方法的精度取决于编译器优化等级和主频，优点是简单，缺点是不精确、不可移植。比如在72MHz下，一个简单的for循环延时1微秒可能需要循环几次，但开了-O2优化后循环可能被优化掉，延时完全失效。

第二种是用SysTick的当前计数值做忙等待。SysTick是一个24位递减计数器，配置为1微秒计数一次的话，可以通过读取当前值来计算经过的时间。这种方法的精度比空循环高，而且不受编译器优化影响。具体做法是：记录进入时的计数值，然后循环读取当前值，直到差值达到目标微秒数。注意要处理计数器回绕的情况。

第三种是用通用定时器（如TIM2）做微秒计数。把定时器预分频到1MHz，也就是每微秒计数一次，然后读取计数器的值。这种方法最精确，也不占用CPU的SysTick资源，适合对时序要求严格的项目。缺点是占用一个定时器。我在DHT11项目里用的是第二种方法，因为不需要额外占用定时器，精度也够用。实测下来，用SysTick忙等待产生的26微秒延时，误差在1微秒以内，DHT11能稳定识别。

3.4 数据校验与异常重试机制的设计

DHT11发送的40位数据里，最后8位是校验和，等于前32位相加取低8位。如果校验失败，说明传输过程中出现了位错误。新手常见的做法是校验失败就丢弃，等下一次采集。但这样会导致数据更新率下降，尤其在湿度变化快的环境里，可能十几秒都拿不到一个有效值。更好的做法是加入重试机制：一次采集失败后，立即重新发起一次通信，最多重试三次。如果三次都失败，再放弃并记录错误。

重试的时候要注意，两次通信之间必须间隔至少1秒，否则DHT11还没准备好，重试也是白搭。所以重试逻辑不能写成紧密循环，而应该用状态机或者定时器来调度。我在实际项目里是这样处理的：主循环每2秒触发一次采集，采集函数内部最多重试3次，每次重试之间用软件延时等待1秒。这样即使第一次失败，最多3秒后也能拿到数据，对大多数温湿度监控场景来说完全够用。

还有一个异常情况是DHT11完全没有响应。这时候总线会一直保持高电平，代码如果一直等待低电平，就会死循环。所以读取函数里必须加超时判断：等待响应低电平超过100微秒就退出，等待响应高电平超过100微秒也退出。超时时间可以根据实际测试调整，但一定要有，否则程序会卡死。我一般会在超时后返回一个特定的错误码，方便上层判断是传感器没接好还是时序问题。

4. 串口调试：让数据真正被看见

4.1 USART的波特率计算与时钟源选择

STM32F1的USART波特率由外设时钟和USART_BRR寄存器决定。以USART1为例，它挂在APB2总线上，时钟频率通常是72MHz。波特率计算公式是：USARTDIV = fCK / (16 × 波特率)。比如要设置115200波特率，USARTDIV = 72000000 / (16 × 115200) = 39.0625。BRR寄存器的整数部分是39，小数部分是0.0625 × 16 = 1，所以BRR的值是0x271。如果时钟配置错了，比如APB2实际是36MHz，那算出来的BRR就不对，串口收到的就是乱码。

很多人用CubeMX配置串口，直接选115200，生成的代码看起来没问题，但实际通信就是乱码。排查的时候第一件事就是确认系统时钟树。CubeMX里有一个Clock Configuration页面，能看到各个总线的实际频率。如果HSE没起振，系统可能跑在内部8MHz RC上，这时候APB2只有8MHz，波特率偏差巨大。我遇到过好几次，都是因为晶振没焊好或者负载电容不对，导致时钟源切换失败，程序自动回退到内部RC。

另一个容易忽略的点是过采样。STM32F1的USART支持16倍和8倍过采样。16倍过采样对波特率误差的容忍度更高，适合大多数场景。8倍过采样可以让波特率更高，但对时钟精度要求更严。除非你要跑很高的波特率（比如1M以上），否则保持默认的16倍过采样就行。

4.2 printf重定向的两种写法与潜在陷阱

在单片机开发里，用printf打印调试信息是最方便的方式。但STM32的printf默认输出到标准输出，需要重定向到串口。常见有两种写法。第一种是重写fputc函数，这是Keil MDK和IAR都支持的方式。代码很简单：在fputc里调用HAL_UART_Transmit发送一个字节，然后返回这个字节。第二种是重写_write函数，这是GCC（STM32CubeIDE）的方式。两种写法的原理一样，只是函数名不同。

这里有一个陷阱：如果你在中断服务函数里调用printf，而printf底层是阻塞发送，就会导致中断响应时间变长，甚至引发其他中断丢失。比如你在定时器中断里打印调试信息，串口发送一个字符串需要几百微秒到几毫秒，这期间其他中断都被延迟了。正确的做法是，中断里只置标志位，主循环里判断标志位再打印。或者用DMA发送，把数据丢给DMA后立即返回，不占用CPU时间。

还有一个坑是printf的缓冲区。标准库的printf默认使用行缓冲，遇到换行符才真正输出。如果你打印的字符串没有换行，可能一直留在缓冲区里看不到。解决办法是在每次printf后手动调用fflush，或者在字符串末尾加\n。我习惯在调试信息末尾统一加\r\n，既刷新缓冲区，又让串口助手的显示更整齐。

4.3 用串口助手观察DHT11数据的正确姿势

串口助手是调试传感器最直接的工具。但很多人用串口助手只看数据，忽略了时间戳和波形。我推荐用带时间戳功能的串口助手，比如SSCOM或者XCOM，这样你能看到每次数据到达的精确时间。如果DHT11每2秒采集一次，串口助手上应该每2秒出现一行数据。如果时间间隔忽长忽短，说明你的延时或者调度有问题。

观察数据的时候，不要只看数值，还要看变化趋势。比如用手握住DHT11，温度应该缓慢上升，湿度也会变化。如果数值突然跳到0或者99，说明通信出错了。这时候可以打开串口助手的十六进制显示，看看原始字节是什么。DHT11的正常数据是5个字节：湿度整数、湿度小数、温度整数、温度小数、校验和。如果收到的字节数不对，或者校验和不匹配，就能快速定位问题。

我还习惯在串口输出里加上错误码。比如采集成功打印"OK: T=25C H=60%"，采集失败打印"ERR: timeout"或者"ERR: checksum"。这样一眼就能看出是硬件没接好还是时序有问题。调试阶段信息越详细越好，等稳定运行后再精简输出，减少串口带宽占用。

5. 那些教程不会告诉你的调试经验

5.1 程序下载后不运行的五个排查方向

程序下载成功但板子没反应，这是新手最常遇到的问题。我总结下来有五个排查方向。第一，检查BOOT引脚。如果BOOT0还是高电平，芯片上电后进入系统存储器，不会运行你下载的程序。把BOOT0拨回低电平，按复位。第二，检查复位电路。有些最小系统板的复位按键接触不良，或者复位电容太大导致复位时间过长。用万用表测复位引脚，正常应该是3.3V，按下按键降到0V。第三，检查时钟配置。如果程序里配置了HSE，但板子上没有晶振或者晶振坏了，程序会卡在等待HSE就绪的循环里。可以在时钟初始化后翻转一个GPIO，用示波器或者LED判断程序有没有跑过时钟配置。

第四，检查堆栈大小。STM32F1的启动文件里定义了堆栈大小，默认可能是1KB。如果你的程序用了较大的局部数组或者递归，堆栈溢出会导致程序跑飞。可以在启动文件里把堆栈改大，比如2KB或者4KB。第五，检查中断向量表。如果你用了IAP或者自定义了向量表偏移，但忘记设置SCB->VTOR，中断就会跳到错误的位置。这个坑在带Bootloader的项目里特别常见。

5.2 DHT11读数跳变的硬件与软件双重排查

DHT11读数偶尔跳变，比如温度突然从25跳到0再跳回来，这种问题往往不是单一原因。硬件方面，先检查电源。DHT11的工作电流虽然不大，但瞬间拉低总线时会有电流尖峰。如果电源走线太细或者滤波电容不够，电压会跌落。我在DHT11的VCC和GND之间并了一个100nF和一个10uF的电容，跳变明显减少。数据线也要尽量短，超过20厘米就容易受干扰，最好用屏蔽线或者双绞线。

软件方面，检查你的读取函数有没有关中断。DHT11的时序要求微秒级，如果读取过程中被其他中断打断，比如SysTick中断或者串口中断，就会错过电平变化。我的做法是在读取DHT11的整个过程中关闭全局中断，读完再打开。关中断的时间大约几毫秒，对大多数应用来说可以接受。如果系统对中断实时性要求高，可以用定时器输入捕获来测量高电平持续时间，这样不需要关中断，但实现起来复杂一些。

还有一个软件层面的问题是变量类型。DHT11返回的湿度整数是8位无符号数，温度整数也是8位，但温度可能是负数（DHT11不支持负温，但DHT22支持）。如果你用char类型接收，负数会变成大正数。我一般用uint8_t接收原始字节，然后在应用层判断符号位。校验和计算时也要注意，所有字节按无符号数相加，取低8位。

5.3 从裸机到RTOS：什么时候该引入任务调度

裸机程序用while(1)大循环加延时，做一两个传感器的采集没问题。但当你要同时处理串口命令、按键扫描、显示屏刷新、多个传感器采集时，大循环就会变得臃肿，每个任务的实时性都难以保证。这时候就该考虑引入RTOS，比如FreeRTOS。FreeRTOS在STM32F1上跑很轻松，内核占用几KB Flash和1KB左右的RAM，C8T6完全带得动。

引入RTOS之后，DHT11采集可以单独放在一个任务里，任务里用vTaskDelay实现1秒间隔，不会阻塞其他任务。串口命令解析放在另一个任务，优先级可以设高一点，保证响应及时。任务之间通过队列传递数据，比如DHT11任务把温湿度数据打包成结构体，发送到队列，显示任务从队列里取数据刷新屏幕。这样各任务解耦，代码更好维护。

不过RTOS也带来了新的坑。第一，中断里不能调用带阻塞的API，比如vTaskDelay，必须用FromISR版本。第二，任务堆栈要分配够，DHT11任务里如果用了printf，堆栈至少256字。第三，优先级反转问题，如果低优先级任务持有互斥锁，高优先级任务等待，中等优先级任务又在跑，就会导致高优先级任务被延迟。FreeRTOS的互斥锁支持优先级继承，可以缓解这个问题，但设计时还是要尽量避免长时间持有锁。

6. 从DHT11项目延伸出的学习路径

DHT11加STM32F1这个组合，看起来简单，但它覆盖了嵌入式开发的核心技能：GPIO操作、时钟配置、微秒延时、单总线协议、串口通信、数据校验、异常处理。把这套流程走通之后，你其实已经具备了驱动大多数数字传感器的能力。接下来可以尝试把DHT11换成DHT22，它的时序类似但精度更高，数据格式是16位，能测负温。或者换成I2C接口的SHT30，学习I2C总线的时序和STM32的I2C外设配置。

再往后，可以加一块OLED显示屏，把温湿度数据显示在本地，不用每次都开电脑看串口。OLED通常是I2C或SPI接口，正好练习另一种总线。然后可以加一个ESP8266或者ESP32模块，把数据上传到云平台，学习AT指令和JSON格式。如果对低功耗有要求，可以研究STM32F1的睡眠模式和停止模式，用RTC定时唤醒采集，用电池供电运行几个月。

我自己的学习路径就是这样一步步走过来的。每加一个模块，都会遇到新的问题，但底层的东西是相通的。STM32F1虽然老，但它的手册详细、社区活跃、价格便宜，作为学习平台再合适不过。等你把F1玩透了，再换F4或者G0、L4系列，会发现大部分概念都能直接迁移，只是外设更复杂、性能更强而已。关键不是用多新的芯片，而是把一套完整的开发流程和调试方法真正掌握在手里。