1. 为什么一个STM32项目值得把代码、原理图和仿真全部开源很多做过STM32项目的人都有个习惯代码往GitHub一扔原理图躺在立创EDA的工程里仿真文件散落在本地某个新建文件夹里然后就没有然后了。别人拿到这个项目想复现却发现——代码编译不过因为不知道用的是哪个芯片包版本原理图打不开因为缺了自定义的元件库仿真跑不起来因为工程里引用的模型路径全是绝对路径。这种开源其实只开了三分之一剩下的三分之二全靠猜。我这次要聊的就是把一个STM32项目真正意义上完整开源出来——代码、原理图、仿真三件套齐全而且保证任何人拿到之后能在半小时内跑通。这个标准听起来简单但实际操作下来光是让三个部分互相对得上就花了我不少功夫。比如代码里PA6接的是超声波模块的Trig引脚那原理图上就必须标注清楚仿真里对应的信号源也要能产生匹配的激励三者之间任何一个环节对不上复现的人就会卡住。这篇文章适合几类人看正在准备基于STM32的毕业设计、需要提交完整工程材料的学生想把自己做的嵌入式开源项目整理规范、方便别人复现的开发者以及刚接触STM32、想通过一个完整案例理解代码-硬件-仿真三者关系的初学者。我会把整个项目的搭建思路、每个部分的关键细节、以及我在整理过程中踩过的坑全部摊开来讲不藏私。需要提前说明的是我用的主控是STM32F103C8T6这是最经典的入门型号芯片包安装方便资料也最全。整个项目的功能定位是多传感器数据采集与显示包含DHT11温湿度、超声波测距、OLED显示三个模块代码量不大但覆盖面广非常适合作为模板去扩展。2. 项目整体架构三个模块如何串成一条线2.1 功能拆解与模块划分先把这个项目到底要干什么说清楚。核心功能就三件事第一DHT11采集环境温湿度第二HC-SR04超声波模块测量距离第三SSD1306 OLED屏幕把这两组数据显示出来。三个模块通过STM32F103C8T6协调工作主循环里轮流读取传感器、刷新屏幕同时用定时器做一个软时钟来记录运行时间。为什么选这三个模块而不是别的因为它们在基于STM32的毕业设计里出现频率极高几乎每个做环境监测或智能小车方向的人都会用到。而且这三个模块的通信协议各不相同——DHT11是单总线、超声波是GPIO触发加输入捕获、OLED是I2C——正好覆盖了STM32最常用的几种外设操作方式。把这三个跑通基本上GPIO、定时器、I2C、中断这些核心外设就都练到了。模块划分上我按功能分成了四个文件组dht11.c/h负责温湿度读取hc_sr04.c/h负责测距oled.c/h负责显示驱动main.c负责调度。每个模块对外只暴露两三个函数内部实现细节全部封装起来。这样做的好处是如果你只想用其中的DHT11部分直接把对应的两个文件拷走就行不用管其他模块的依赖。2.2 硬件资源分配与引脚规划引脚分配这件事看起来简单实际上是最容易埋坑的地方。我见过太多项目因为引脚冲突导致调试半天找不到问题。这次我用的分配方案如下功能模块引脚外设资源备注DHT11数据线PA0GPIO输入/输出需要上拉电阻超声波TrigPA6GPIO输出推挽输出超声波EchoPA7TIM3_CH2输入捕获复用功能OLED SCLPB6I2C1_SCL复用开漏OLED SDAPB7I2C1_SDA复用开漏调试串口TXPA9USART1_TX复用推挽调试串口RXPA10USART1_RX浮空输入这里有几个关键决策需要解释。超声波Echo为什么用TIM3_CH2的输入捕获而不是外部中断加定时器因为输入捕获能直接记录上升沿和下降沿的时间戳精度到微秒级而且不需要在中断里手动读计数器代码更简洁。OLED为什么用硬件I2C而不是软件模拟因为STM32F103的硬件I2C虽然历史上有些坑但在标准100kHz速率下跑SSD1306完全没问题而且不占用CPU时间。DHT11为什么单独占一个引脚而不和其他模块复用因为单总线协议对时序要求严格复用引脚容易在切换方向时引入额外延迟。注意PA0作为DHT11数据线时外部必须接一个4.7kΩ到10kΩ的上拉电阻。我一开始偷懒用了内部上拉结果读取成功率只有六成左右换成外部上拉后稳定在99%以上。这个细节在原理图上一定要标出来。2.3 代码、原理图、仿真三者的对应关系这是整个开源项目最核心的部分——三者必须能互相验证。我的做法是原理图上每个网络标号都对应代码里的宏定义仿真里的激励信号又对应原理图上的实际波形。具体来说代码里我会这样定义引脚#define DHT11_GPIO_PORT GPIOA #define DHT11_GPIO_PIN GPIO_Pin_0 #define HC_SR04_TRIG_PORT GPIOA #define HC_SR04_TRIG_PIN GPIO_Pin_6 #define HC_SR04_ECHO_PORT GPIOA #define HC_SR04_ECHO_PIN GPIO_Pin_7原理图上PA0网络标号旁边标注DHT11_DATAPA6标TRIGPA7标ECHO。仿真工程里DHT11用一个单总线时序发生器模拟超声波Echo用一个可编程脉冲源模拟脉冲宽度对应不同距离。这样任何人拿到这三份文件都能清楚地看到代码里操作的是哪个引脚、原理图上这个引脚接了什么、仿真里这个引脚应该出现什么波形。我特意在原理图的空白处加了一个注释框把代码里用到的所有宏定义和对应的网络标号列成表格。这个做法后来被好几个朋友夸过说省了他们大量对照时间。仿真工程里也类似每个信号源旁边都标注了对应的代码函数名。3. 代码部分从芯片包安装到模块驱动跑通3.1 开发环境搭建中最容易被忽略的细节STM32芯片包安装这件事看起来就是点几下鼠标但实际上很多人卡在这一步。我用的是Keil MDK5芯片包是Keil.STM32F1xx_DFP.2.4.0.pack。这里有个坑如果你之前装过旧版本的F1芯片包直接装新版本可能会报错提示pack already installed。正确的做法是先在Pack Installer里把旧的卸载掉重启Keil再装新的。另一个常见问题是Keil5兼容C51和STM32安装。如果你电脑上同时装了C51和MDK有时候会出现编译器路径冲突导致STM32工程编译时报cannot open source input file之类的错误。解决办法是在Keil的安装目录下把C51和ARM两个文件夹分开管理然后在工程设置里手动指定ARM编译器路径。我现在的做法是干脆用两台电脑分开一台专门跑STM32一台跑51省得折腾。还有一点STM32无法识别USB设备这个问题在调试阶段特别常见。原因通常有三个一是ST-Link驱动没装好设备管理器里显示黄色感叹号二是USB线是充电线而不是数据线这个坑我踩过不止一次三是芯片的BOOT0引脚被拉高了导致芯片进入系统存储器启动模式而不是从Flash启动。排查顺序建议从换线开始然后检查驱动最后查BOOT引脚。3.2 DHT11单总线驱动的时序要点DHT11的驱动代码网上到处都是但真正能稳定运行的没几个。问题出在时序上。DHT11的通信过程是这样的主机拉低总线至少18ms作为起始信号然后释放总线DHT11响应时会先拉低80us再拉高80us之后开始传输40位数据每一位以50us低电平开始高电平的持续时间决定是0还是1——26到28us表示070us表示1。听起来简单但实际写代码时如果你用delay_us来做延时很容易因为中断打断导致时序偏差。我的做法是在读取数据位的时候关掉全局中断读完再打开。代码如下uint8_t DHT11_ReadByte(void) { uint8_t i, byte 0; for (i 0; i 8; i) { while (!DHT11_READ_PIN timeout); // 等待50us低电平结束 delay_us(40); // 延时40us后采样 byte 1; if (DHT11_READ_PIN) { byte | 1; while (DHT11_READ_PIN timeout); // 等待高电平结束 } } return byte; }这里的关键是延时40us后采样——因为0的高电平只有26到28us40us时已经变低了而1的高电平有70us40us时还是高的。这样就能准确区分0和1。另外timeout变量是防止死循环的如果传感器没接好程序不会卡死在while里。实操心得DHT11上电后需要等待1秒以上才能读取第一次读取的数据往往不准建议丢弃前两次读数。我在代码里加了一个DHT11_Init()函数里面先延时1.2秒然后连续读三次只取第三次的结果。3.3 超声波测距的输入捕获实现STM32测频法和输入捕获是同一个思路——利用定时器的捕获功能记录边沿时刻。HC-SR04的工作流程是Trig引脚给一个10us以上的高电平脉冲模块自动发出8个40kHz的超声波脉冲然后Echo引脚变高高电平持续时间就是超声波往返的时间。我用TIM3的通道2来做输入捕获配置为上升沿和下降沿都触发。第一次捕获到上升沿时记录CCR2的值第二次捕获到下降沿时再记录一次两次之差就是高电平时间。这里要注意的是如果距离超过一定范围Echo高电平时间会很长可能导致定时器溢出。我的处理方式是在捕获中断里判断溢出标志如果溢出了就手动加上溢出次数乘以计数周期。void TIM3_IRQHandler(void) { if (TIM_GetITStatus(TIM3, TIM_IT_CC2) ! RESET) { if (capture_edge 0) { capture_start TIM_GetCapture2(TIM3); capture_edge 1; TIM_OC2PolarityConfig(TIM3, TIM_ICPolarity_Falling); } else { capture_end TIM_GetCapture2(TIM3); capture_edge 0; TIM_OC2PolarityConfig(TIM3, TIM_ICPolarity_Rising); if (capture_end capture_start) { pulse_width capture_end - capture_start; } else { pulse_width (0xFFFF - capture_start) capture_end; } } TIM_ClearITPendingBit(TIM3, TIM_IT_CC2); } }距离计算公式是距离(cm) pulse_width(us) / 58。这个58是怎么来的声速在常温下约340m/s也就是34000cm/s换算成每微秒0.034cm。超声波往返一次所以实际距离是时间乘以0.034再除以2即时间乘以0.017取倒数就是58.8约等于58。3.4 OLED显示驱动的I2C通信优化SSD1306的驱动代码网上有很多版本我选了一个基于硬件I2C的轻量级实现整个驱动只有三个文件加起来不到500行。核心函数就两个OLED_WriteCmd()写命令OLED_WriteData()写数据。显示字符串的时候先用取模软件生成字模数组然后逐字节写入GDDRAM。这里有个优化点如果你要频繁刷新屏幕每次都全屏刷新会导致明显的闪烁。我的做法是只刷新变化的部分。比如温湿度值只有整数部分变了才更新对应的显示区域。具体实现是维护一个last_temp和last_humi变量每次读取新值后比较不同才调用OLED_ShowNum()。I2C的速率我设的是400kHz实测下来SSD1306完全能跟上。如果你发现屏幕偶尔花屏大概率是I2C速率太高或者上拉电阻太大。标准做法是SCL和SDA各接一个4.7kΩ上拉电阻到3.3V我试过用10kΩ的在400kHz下波形上升沿明显变缓降到100kHz才稳定。4. 原理图设计从嘉立创画图到接地处理4.1 用嘉立创EDA绘制STM32F103C8T6最小系统DHT11原理图嘉立创画图这个组合词最近搜索量挺高说明很多人开始用国产EDA工具了。我这次原理图就是用嘉立创EDA画的整体体验下来画STM32最小系统完全够用。元件库里有现成的STM32F103C8T6符号直接拖出来就行。最小系统包含几个必要部分主控芯片、8MHz晶振电路、复位电路、电源滤波电路、BOOT启动配置电路、SWD调试接口。晶振电路的两个负载电容我用的20pF这个值是根据晶振规格书来的一般8MHz晶振配20pF比较合适。复位电路是经典的10kΩ上拉加100nF电容复位按键并联在电容两端。电源部分要注意STM32F103的VDD和VDDA都要接3.3V每个电源引脚旁边放一个100nF的去耦电容。我见过有人只放一个电容给所有VDD引脚结果ADC采样噪声特别大。虽然这个项目没用到ADC但养成好习惯没坏处。VDDA和VSSA之间还要加一个1uF的钽电容这个在数据手册里有明确要求。4.2 EDA原理图绘制中的星型接地处理EDA原理图绘制星型接地是一个经常被忽视但很重要的细节。星型接地的核心思想是所有地线最终汇聚到一个点避免不同模块的电流在地线上产生压降互相干扰。在这个项目里我把地分成了三组数字地STM32的VSS、模拟地VSSA、功率地超声波模块的GND。三组地线在原理图上分别用不同的网络标号最后在PCB布局时通过一个0Ω电阻或者磁珠单点连接。虽然这个项目没有高精度模拟电路但超声波模块工作时瞬间电流较大如果和数字地混在一起可能会在DHT11读取时引入噪声。具体画法是在嘉立创EDA里给每个GND符号单独命名比如GND_D、GND_A、GND_P然后用一个0Ω电阻R0把GND_D和GND_A连起来再用另一个0Ω电阻把GND_D和GND_P连起来。这样在PCB上就能清楚地看到地线的汇聚点。4.3 原理图与代码的交叉验证方法画完原理图后我养成了一个习惯把代码里所有用到的引脚列出来然后逐个在原理图上找对应的网络标号确认没有遗漏或冲突。这个步骤花不了十分钟但能避免很多低级错误。比如代码里用了PA9和PA10做串口原理图上就要确认这两个引脚没有接其他东西。我这次画的时候一开始把PA9接到了一个LED上后来检查代码发现串口要用PA9赶紧改到PB0去了。如果没做这个交叉验证等PCB打样回来才发现就晚了。另外原理图上的元件标号最好和代码里的宏定义对应起来。比如DHT11在原理图上标号是U2代码里就可以写#define DHT11_U2虽然实际用不到但方便对照。这个做法在项目文件多的时候特别有用。5. 仿真部分没有硬件也能验证逻辑5.1 仿真平台选型与工程搭建Wokwi仿真平台是我最近用得比较多的一个在线仿真工具支持STM32F103系列而且可以直接在浏览器里跑不需要装任何软件。另一个选择是Proteus功能更强大但需要本地安装。我这次两个版本都做了Wokwi用于快速验证逻辑Proteus用于更精确的时序仿真。Wokwi上搭建这个项目很简单新建一个STM32工程从元件库里拖出DHT11、HC-SR04、SSD1306三个模块按照原理图的引脚连接好然后把Keil编译出来的hex文件上传点运行就能看到效果。Wokwi的DHT11和HC-SR04都是行为级模型不需要你手动模拟时序直接给个温度值和距离值就行。Proteus这边稍微麻烦一点需要自己加载STM32的模型库。我用的是Proteus 8.13版本自带STM32F103C8T6的模型。DHT11在Proteus里没有现成模型我用一个单总线温度传感器模型替代时序基本一致。超声波模块用两个信号发生器模拟一个产生Trig脉冲一个产生Echo回波。5.2 仿真中DHT11和超声波的行为级建模在Wokwi里DHT11的模型是这样的你可以在属性面板里设置温度和湿度值仿真运行时当代码发出起始信号后模型会自动按照DHT11的协议返回数据。这意味着你不需要关心时序细节只要代码逻辑正确就能读到数据。超声波模块类似设置一个距离值模型会根据距离计算出Echo高电平的持续时间。比如设置距离为50cmEcho高电平就是50乘以58等于2900us。这个模型的好处是你可以快速测试不同距离下代码的计算是否正确。Proteus这边就需要自己动手了。我用一个脉冲发生器接在Echo引脚上脉冲宽度手动设置为2900us然后观察代码计算出来的距离是不是50cm。这个方法虽然麻烦但能更真实地反映时序问题。比如我一开始用Wokwi测试时一切正常换到Proteus后发现距离总是偏大查了半天才发现是输入捕获的溢出处理没写好。5.3 仿真结果与实物测试的差异分析仿真跑通不代表实物就能跑通这两者之间有几个典型差异。第一仿真里的信号是理想的没有噪声和抖动实物上DHT11的数据线可能会有毛刺导致读取失败。第二仿真里的电源是稳定的3.3V实物上如果用USB供电电压可能在3.2V到3.4V之间波动影响超声波模块的测距精度。第三仿真里的I2C通信没有电容负载实物上OLED的排线会引入寄生电容导致通信速率下降。我的应对策略是仿真里把时序余量留大一点比如DHT11的采样延时从40us改成45us这样实物上即使有轻微抖动也能正确读取。超声波的距离计算加一个滑动平均滤波连续读五次去掉最大最小值再取平均。I2C速率从400kHz降到200kHz牺牲一点刷新速度换取稳定性。注意仿真工程里的hex文件要和代码工程保持同步。我习惯在Keil里编译完后手动把hex文件复制到仿真工程目录然后在仿真软件里重新加载。如果忘了这一步仿真跑的还是旧代码会浪费很多时间排查一个根本不存在的bug。6. 开源项目整理让别人能跑起来才算真正开源6.1 目录结构设计与README编写要点一个嵌入式开源项目能不能被别人用起来目录结构起了决定性作用。我的做法是按功能分文件夹每个文件夹里放对应的代码、原理图、仿真文件再加一个总的README。STM32_MultiSensor_Project/ ├── Code/ │ ├── Core/ │ │ ├── main.c │ │ ├── stm32f1xx_it.c │ │ └── ... │ ├── Drivers/ │ │ ├── DHT11/ │ │ ├── HC_SR04/ │ │ └── OLED/ │ └── Project.uvprojx ├── Schematic/ │ ├── STM32_MultiSensor.pdf │ └── STM32_MultiSensor.epro ├── Simulation/ │ ├── Wokwi/ │ └── Proteus/ └── README.mdREADME里必须包含几个关键信息开发环境版本Keil MDK5.38、STM32F1xx_DFP 2.4.0、硬件清单STM32F103C8T6最小系统板、DHT11、HC-SR04、SSD1306 OLED、接线表、编译步骤、仿真运行步骤。我还会在README里放一张实物连接的照片这样别人一看就知道该怎么接。6.2 代码注释与版本管理规范代码注释这件事我的原则是每个函数头部写清楚功能、参数、返回值每个关键变量写清楚用途每个不直观的操作写清楚原因。比如DHT11的40us延时我会注释延时40us后采样此时0的高电平已结束1的高电平仍在持续。版本管理我用Gitcommit信息遵循模块: 操作的格式比如dht11: 修复读取超时问题、oled: 优化刷新逻辑减少闪烁。每个版本打一个tag比如v1.0、v1.1。这样别人下载的时候可以选择稳定版本而不是直接拿最新的开发版。6.3 常见复现问题与排查清单根据我收到的反馈别人复现这个项目时最常遇到的问题有这么几个问题现象可能原因排查方法编译报错找不到头文件芯片包版本不对检查是否安装了STM32F1xx_DFPDHT11读取一直失败上拉电阻没接或阻值太大用万用表测数据线电压空闲时应为3.3V超声波测距值固定不变Echo引脚没接对或定时器没配置用示波器看Echo引脚有没有脉冲OLED不亮I2C地址不对或上拉电阻缺失用I2C扫描程序确认设备地址仿真跑不起来hex文件路径不对或模型库缺失检查仿真工程里的hex文件路径我把这个表格直接放进了README的常见问题章节后来反馈说这个表格帮了大忙很多人照着排查就解决了。7. 从能跑到好用几个提升项目质量的细节7.1 用定时器中断做软时钟替代delay项目里如果到处用delay_ms()CPU大部分时间都在空转效率很低。我的做法是用SysTick或者TIM2做一个1ms的软时钟主循环里用状态机来调度任务。比如每100ms读一次DHT11每50ms读一次超声波每200ms刷新一次OLED。这样CPU利用率从原来的不到10%提升到了60%以上而且响应更及时。具体实现是定义一个全局变量volatile uint32_t tick_ms在SysTick中断里自增。主循环里用if (tick_ms - last_dht11_tick 100)来判断是否该执行DHT11读取。这个模式在stm32项目里非常通用建议养成习惯。7.2 串口打印调试信息的正确姿势调试阶段串口打印是最直接的观察手段。但很多人用printf的时候忘了重定向fputc函数导致串口没输出。正确的做法是在代码里加上int fputc(int ch, FILE *f) { USART_SendData(USART1, (uint8_t)ch); while (USART_GetFlagStatus(USART1, USART_FLAG_TC) RESET); return ch; }然后在Keil的Target选项里勾选Use MicroLIB。这样printf就能正常输出了。我习惯在每读取一次传感器后打印一行数据格式是T:25.3 H:60.2 D:48.5方便用串口助手观察趋势。7.3 电源管理与低功耗的初步考虑虽然这个项目是USB供电不需要考虑低功耗但养成好习惯没坏处。我在代码里加了一个Enter_Sleep()函数主循环空闲时调用__WFI()指令让CPU进入睡眠模式等中断唤醒。实测下来工作电流从28mA降到了12mA左右。如果你后续想用电池供电这个改动是必须的。另外OLED屏幕在不需要显示的时候可以发送关闭显示命令DHT11和超声波模块也可以在不读取的时候断电。这些细节在基于STM32的毕业设计里往往是加分项评委看到你有低功耗意识印象分会高不少。8. 关于开源这件事的一些个人体会把代码、原理图、仿真三样东西整理好开源出去花的时间比写代码本身还多。但我觉得值得。因为我自己在学习STM32的时候最痛苦的就是找到一个项目代码能编译但原理图对不上或者原理图能看但仿真跑不起来。那种感觉就像拼图少了几块明明知道全貌就在眼前就是拼不出来。这次整理过程中我最大的收获是学会了站在复现者的角度思考。每写一行代码我都会想别人拿到这行代码知道它对应哪个引脚吗每画一根线我都会想别人看到这根线知道它连到代码里的哪个宏定义吗这种换位思考的习惯后来也影响了我做其他项目的方式。如果你也在准备开源自己的STM32项目我的建议是先别急着上传找一个没接触过这个项目的朋友让他按照你的README从头跑一遍。他卡住的每一个地方都是你需要补充说明的地方。这个过程可能来回好几次但最终出来的项目质量会比你自己闷头整理高出一大截。最后分享一个我常用的检查清单每次开源前过一遍代码能编译吗原理图能打开吗仿真能跑通吗三者引脚对应吗README写清楚了吗别人问的问题我能回答吗这六个问题都答是这个项目才算真正开源了。 STM32项目完整开源：代码、原理图与仿真三件套齐全
1. 为什么一个STM32项目值得把代码、原理图和仿真全部开源很多做过STM32项目的人都有个习惯代码往GitHub一扔原理图躺在立创EDA的工程里仿真文件散落在本地某个新建文件夹里然后就没有然后了。别人拿到这个项目想复现却发现——代码编译不过因为不知道用的是哪个芯片包版本原理图打不开因为缺了自定义的元件库仿真跑不起来因为工程里引用的模型路径全是绝对路径。这种开源其实只开了三分之一剩下的三分之二全靠猜。我这次要聊的就是把一个STM32项目真正意义上完整开源出来——代码、原理图、仿真三件套齐全而且保证任何人拿到之后能在半小时内跑通。这个标准听起来简单但实际操作下来光是让三个部分互相对得上就花了我不少功夫。比如代码里PA6接的是超声波模块的Trig引脚那原理图上就必须标注清楚仿真里对应的信号源也要能产生匹配的激励三者之间任何一个环节对不上复现的人就会卡住。这篇文章适合几类人看正在准备基于STM32的毕业设计、需要提交完整工程材料的学生想把自己做的嵌入式开源项目整理规范、方便别人复现的开发者以及刚接触STM32、想通过一个完整案例理解代码-硬件-仿真三者关系的初学者。我会把整个项目的搭建思路、每个部分的关键细节、以及我在整理过程中踩过的坑全部摊开来讲不藏私。需要提前说明的是我用的主控是STM32F103C8T6这是最经典的入门型号芯片包安装方便资料也最全。整个项目的功能定位是多传感器数据采集与显示包含DHT11温湿度、超声波测距、OLED显示三个模块代码量不大但覆盖面广非常适合作为模板去扩展。2. 项目整体架构三个模块如何串成一条线2.1 功能拆解与模块划分先把这个项目到底要干什么说清楚。核心功能就三件事第一DHT11采集环境温湿度第二HC-SR04超声波模块测量距离第三SSD1306 OLED屏幕把这两组数据显示出来。三个模块通过STM32F103C8T6协调工作主循环里轮流读取传感器、刷新屏幕同时用定时器做一个软时钟来记录运行时间。为什么选这三个模块而不是别的因为它们在基于STM32的毕业设计里出现频率极高几乎每个做环境监测或智能小车方向的人都会用到。而且这三个模块的通信协议各不相同——DHT11是单总线、超声波是GPIO触发加输入捕获、OLED是I2C——正好覆盖了STM32最常用的几种外设操作方式。把这三个跑通基本上GPIO、定时器、I2C、中断这些核心外设就都练到了。模块划分上我按功能分成了四个文件组dht11.c/h负责温湿度读取hc_sr04.c/h负责测距oled.c/h负责显示驱动main.c负责调度。每个模块对外只暴露两三个函数内部实现细节全部封装起来。这样做的好处是如果你只想用其中的DHT11部分直接把对应的两个文件拷走就行不用管其他模块的依赖。2.2 硬件资源分配与引脚规划引脚分配这件事看起来简单实际上是最容易埋坑的地方。我见过太多项目因为引脚冲突导致调试半天找不到问题。这次我用的分配方案如下功能模块引脚外设资源备注DHT11数据线PA0GPIO输入/输出需要上拉电阻超声波TrigPA6GPIO输出推挽输出超声波EchoPA7TIM3_CH2输入捕获复用功能OLED SCLPB6I2C1_SCL复用开漏OLED SDAPB7I2C1_SDA复用开漏调试串口TXPA9USART1_TX复用推挽调试串口RXPA10USART1_RX浮空输入这里有几个关键决策需要解释。超声波Echo为什么用TIM3_CH2的输入捕获而不是外部中断加定时器因为输入捕获能直接记录上升沿和下降沿的时间戳精度到微秒级而且不需要在中断里手动读计数器代码更简洁。OLED为什么用硬件I2C而不是软件模拟因为STM32F103的硬件I2C虽然历史上有些坑但在标准100kHz速率下跑SSD1306完全没问题而且不占用CPU时间。DHT11为什么单独占一个引脚而不和其他模块复用因为单总线协议对时序要求严格复用引脚容易在切换方向时引入额外延迟。注意PA0作为DHT11数据线时外部必须接一个4.7kΩ到10kΩ的上拉电阻。我一开始偷懒用了内部上拉结果读取成功率只有六成左右换成外部上拉后稳定在99%以上。这个细节在原理图上一定要标出来。2.3 代码、原理图、仿真三者的对应关系这是整个开源项目最核心的部分——三者必须能互相验证。我的做法是原理图上每个网络标号都对应代码里的宏定义仿真里的激励信号又对应原理图上的实际波形。具体来说代码里我会这样定义引脚#define DHT11_GPIO_PORT GPIOA #define DHT11_GPIO_PIN GPIO_Pin_0 #define HC_SR04_TRIG_PORT GPIOA #define HC_SR04_TRIG_PIN GPIO_Pin_6 #define HC_SR04_ECHO_PORT GPIOA #define HC_SR04_ECHO_PIN GPIO_Pin_7原理图上PA0网络标号旁边标注DHT11_DATAPA6标TRIGPA7标ECHO。仿真工程里DHT11用一个单总线时序发生器模拟超声波Echo用一个可编程脉冲源模拟脉冲宽度对应不同距离。这样任何人拿到这三份文件都能清楚地看到代码里操作的是哪个引脚、原理图上这个引脚接了什么、仿真里这个引脚应该出现什么波形。我特意在原理图的空白处加了一个注释框把代码里用到的所有宏定义和对应的网络标号列成表格。这个做法后来被好几个朋友夸过说省了他们大量对照时间。仿真工程里也类似每个信号源旁边都标注了对应的代码函数名。3. 代码部分从芯片包安装到模块驱动跑通3.1 开发环境搭建中最容易被忽略的细节STM32芯片包安装这件事看起来就是点几下鼠标但实际上很多人卡在这一步。我用的是Keil MDK5芯片包是Keil.STM32F1xx_DFP.2.4.0.pack。这里有个坑如果你之前装过旧版本的F1芯片包直接装新版本可能会报错提示pack already installed。正确的做法是先在Pack Installer里把旧的卸载掉重启Keil再装新的。另一个常见问题是Keil5兼容C51和STM32安装。如果你电脑上同时装了C51和MDK有时候会出现编译器路径冲突导致STM32工程编译时报cannot open source input file之类的错误。解决办法是在Keil的安装目录下把C51和ARM两个文件夹分开管理然后在工程设置里手动指定ARM编译器路径。我现在的做法是干脆用两台电脑分开一台专门跑STM32一台跑51省得折腾。还有一点STM32无法识别USB设备这个问题在调试阶段特别常见。原因通常有三个一是ST-Link驱动没装好设备管理器里显示黄色感叹号二是USB线是充电线而不是数据线这个坑我踩过不止一次三是芯片的BOOT0引脚被拉高了导致芯片进入系统存储器启动模式而不是从Flash启动。排查顺序建议从换线开始然后检查驱动最后查BOOT引脚。3.2 DHT11单总线驱动的时序要点DHT11的驱动代码网上到处都是但真正能稳定运行的没几个。问题出在时序上。DHT11的通信过程是这样的主机拉低总线至少18ms作为起始信号然后释放总线DHT11响应时会先拉低80us再拉高80us之后开始传输40位数据每一位以50us低电平开始高电平的持续时间决定是0还是1——26到28us表示070us表示1。听起来简单但实际写代码时如果你用delay_us来做延时很容易因为中断打断导致时序偏差。我的做法是在读取数据位的时候关掉全局中断读完再打开。代码如下uint8_t DHT11_ReadByte(void) { uint8_t i, byte 0; for (i 0; i 8; i) { while (!DHT11_READ_PIN timeout); // 等待50us低电平结束 delay_us(40); // 延时40us后采样 byte 1; if (DHT11_READ_PIN) { byte | 1; while (DHT11_READ_PIN timeout); // 等待高电平结束 } } return byte; }这里的关键是延时40us后采样——因为0的高电平只有26到28us40us时已经变低了而1的高电平有70us40us时还是高的。这样就能准确区分0和1。另外timeout变量是防止死循环的如果传感器没接好程序不会卡死在while里。实操心得DHT11上电后需要等待1秒以上才能读取第一次读取的数据往往不准建议丢弃前两次读数。我在代码里加了一个DHT11_Init()函数里面先延时1.2秒然后连续读三次只取第三次的结果。3.3 超声波测距的输入捕获实现STM32测频法和输入捕获是同一个思路——利用定时器的捕获功能记录边沿时刻。HC-SR04的工作流程是Trig引脚给一个10us以上的高电平脉冲模块自动发出8个40kHz的超声波脉冲然后Echo引脚变高高电平持续时间就是超声波往返的时间。我用TIM3的通道2来做输入捕获配置为上升沿和下降沿都触发。第一次捕获到上升沿时记录CCR2的值第二次捕获到下降沿时再记录一次两次之差就是高电平时间。这里要注意的是如果距离超过一定范围Echo高电平时间会很长可能导致定时器溢出。我的处理方式是在捕获中断里判断溢出标志如果溢出了就手动加上溢出次数乘以计数周期。void TIM3_IRQHandler(void) { if (TIM_GetITStatus(TIM3, TIM_IT_CC2) ! RESET) { if (capture_edge 0) { capture_start TIM_GetCapture2(TIM3); capture_edge 1; TIM_OC2PolarityConfig(TIM3, TIM_ICPolarity_Falling); } else { capture_end TIM_GetCapture2(TIM3); capture_edge 0; TIM_OC2PolarityConfig(TIM3, TIM_ICPolarity_Rising); if (capture_end capture_start) { pulse_width capture_end - capture_start; } else { pulse_width (0xFFFF - capture_start) capture_end; } } TIM_ClearITPendingBit(TIM3, TIM_IT_CC2); } }距离计算公式是距离(cm) pulse_width(us) / 58。这个58是怎么来的声速在常温下约340m/s也就是34000cm/s换算成每微秒0.034cm。超声波往返一次所以实际距离是时间乘以0.034再除以2即时间乘以0.017取倒数就是58.8约等于58。3.4 OLED显示驱动的I2C通信优化SSD1306的驱动代码网上有很多版本我选了一个基于硬件I2C的轻量级实现整个驱动只有三个文件加起来不到500行。核心函数就两个OLED_WriteCmd()写命令OLED_WriteData()写数据。显示字符串的时候先用取模软件生成字模数组然后逐字节写入GDDRAM。这里有个优化点如果你要频繁刷新屏幕每次都全屏刷新会导致明显的闪烁。我的做法是只刷新变化的部分。比如温湿度值只有整数部分变了才更新对应的显示区域。具体实现是维护一个last_temp和last_humi变量每次读取新值后比较不同才调用OLED_ShowNum()。I2C的速率我设的是400kHz实测下来SSD1306完全能跟上。如果你发现屏幕偶尔花屏大概率是I2C速率太高或者上拉电阻太大。标准做法是SCL和SDA各接一个4.7kΩ上拉电阻到3.3V我试过用10kΩ的在400kHz下波形上升沿明显变缓降到100kHz才稳定。4. 原理图设计从嘉立创画图到接地处理4.1 用嘉立创EDA绘制STM32F103C8T6最小系统DHT11原理图嘉立创画图这个组合词最近搜索量挺高说明很多人开始用国产EDA工具了。我这次原理图就是用嘉立创EDA画的整体体验下来画STM32最小系统完全够用。元件库里有现成的STM32F103C8T6符号直接拖出来就行。最小系统包含几个必要部分主控芯片、8MHz晶振电路、复位电路、电源滤波电路、BOOT启动配置电路、SWD调试接口。晶振电路的两个负载电容我用的20pF这个值是根据晶振规格书来的一般8MHz晶振配20pF比较合适。复位电路是经典的10kΩ上拉加100nF电容复位按键并联在电容两端。电源部分要注意STM32F103的VDD和VDDA都要接3.3V每个电源引脚旁边放一个100nF的去耦电容。我见过有人只放一个电容给所有VDD引脚结果ADC采样噪声特别大。虽然这个项目没用到ADC但养成好习惯没坏处。VDDA和VSSA之间还要加一个1uF的钽电容这个在数据手册里有明确要求。4.2 EDA原理图绘制中的星型接地处理EDA原理图绘制星型接地是一个经常被忽视但很重要的细节。星型接地的核心思想是所有地线最终汇聚到一个点避免不同模块的电流在地线上产生压降互相干扰。在这个项目里我把地分成了三组数字地STM32的VSS、模拟地VSSA、功率地超声波模块的GND。三组地线在原理图上分别用不同的网络标号最后在PCB布局时通过一个0Ω电阻或者磁珠单点连接。虽然这个项目没有高精度模拟电路但超声波模块工作时瞬间电流较大如果和数字地混在一起可能会在DHT11读取时引入噪声。具体画法是在嘉立创EDA里给每个GND符号单独命名比如GND_D、GND_A、GND_P然后用一个0Ω电阻R0把GND_D和GND_A连起来再用另一个0Ω电阻把GND_D和GND_P连起来。这样在PCB上就能清楚地看到地线的汇聚点。4.3 原理图与代码的交叉验证方法画完原理图后我养成了一个习惯把代码里所有用到的引脚列出来然后逐个在原理图上找对应的网络标号确认没有遗漏或冲突。这个步骤花不了十分钟但能避免很多低级错误。比如代码里用了PA9和PA10做串口原理图上就要确认这两个引脚没有接其他东西。我这次画的时候一开始把PA9接到了一个LED上后来检查代码发现串口要用PA9赶紧改到PB0去了。如果没做这个交叉验证等PCB打样回来才发现就晚了。另外原理图上的元件标号最好和代码里的宏定义对应起来。比如DHT11在原理图上标号是U2代码里就可以写#define DHT11_U2虽然实际用不到但方便对照。这个做法在项目文件多的时候特别有用。5. 仿真部分没有硬件也能验证逻辑5.1 仿真平台选型与工程搭建Wokwi仿真平台是我最近用得比较多的一个在线仿真工具支持STM32F103系列而且可以直接在浏览器里跑不需要装任何软件。另一个选择是Proteus功能更强大但需要本地安装。我这次两个版本都做了Wokwi用于快速验证逻辑Proteus用于更精确的时序仿真。Wokwi上搭建这个项目很简单新建一个STM32工程从元件库里拖出DHT11、HC-SR04、SSD1306三个模块按照原理图的引脚连接好然后把Keil编译出来的hex文件上传点运行就能看到效果。Wokwi的DHT11和HC-SR04都是行为级模型不需要你手动模拟时序直接给个温度值和距离值就行。Proteus这边稍微麻烦一点需要自己加载STM32的模型库。我用的是Proteus 8.13版本自带STM32F103C8T6的模型。DHT11在Proteus里没有现成模型我用一个单总线温度传感器模型替代时序基本一致。超声波模块用两个信号发生器模拟一个产生Trig脉冲一个产生Echo回波。5.2 仿真中DHT11和超声波的行为级建模在Wokwi里DHT11的模型是这样的你可以在属性面板里设置温度和湿度值仿真运行时当代码发出起始信号后模型会自动按照DHT11的协议返回数据。这意味着你不需要关心时序细节只要代码逻辑正确就能读到数据。超声波模块类似设置一个距离值模型会根据距离计算出Echo高电平的持续时间。比如设置距离为50cmEcho高电平就是50乘以58等于2900us。这个模型的好处是你可以快速测试不同距离下代码的计算是否正确。Proteus这边就需要自己动手了。我用一个脉冲发生器接在Echo引脚上脉冲宽度手动设置为2900us然后观察代码计算出来的距离是不是50cm。这个方法虽然麻烦但能更真实地反映时序问题。比如我一开始用Wokwi测试时一切正常换到Proteus后发现距离总是偏大查了半天才发现是输入捕获的溢出处理没写好。5.3 仿真结果与实物测试的差异分析仿真跑通不代表实物就能跑通这两者之间有几个典型差异。第一仿真里的信号是理想的没有噪声和抖动实物上DHT11的数据线可能会有毛刺导致读取失败。第二仿真里的电源是稳定的3.3V实物上如果用USB供电电压可能在3.2V到3.4V之间波动影响超声波模块的测距精度。第三仿真里的I2C通信没有电容负载实物上OLED的排线会引入寄生电容导致通信速率下降。我的应对策略是仿真里把时序余量留大一点比如DHT11的采样延时从40us改成45us这样实物上即使有轻微抖动也能正确读取。超声波的距离计算加一个滑动平均滤波连续读五次去掉最大最小值再取平均。I2C速率从400kHz降到200kHz牺牲一点刷新速度换取稳定性。注意仿真工程里的hex文件要和代码工程保持同步。我习惯在Keil里编译完后手动把hex文件复制到仿真工程目录然后在仿真软件里重新加载。如果忘了这一步仿真跑的还是旧代码会浪费很多时间排查一个根本不存在的bug。6. 开源项目整理让别人能跑起来才算真正开源6.1 目录结构设计与README编写要点一个嵌入式开源项目能不能被别人用起来目录结构起了决定性作用。我的做法是按功能分文件夹每个文件夹里放对应的代码、原理图、仿真文件再加一个总的README。STM32_MultiSensor_Project/ ├── Code/ │ ├── Core/ │ │ ├── main.c │ │ ├── stm32f1xx_it.c │ │ └── ... │ ├── Drivers/ │ │ ├── DHT11/ │ │ ├── HC_SR04/ │ │ └── OLED/ │ └── Project.uvprojx ├── Schematic/ │ ├── STM32_MultiSensor.pdf │ └── STM32_MultiSensor.epro ├── Simulation/ │ ├── Wokwi/ │ └── Proteus/ └── README.mdREADME里必须包含几个关键信息开发环境版本Keil MDK5.38、STM32F1xx_DFP 2.4.0、硬件清单STM32F103C8T6最小系统板、DHT11、HC-SR04、SSD1306 OLED、接线表、编译步骤、仿真运行步骤。我还会在README里放一张实物连接的照片这样别人一看就知道该怎么接。6.2 代码注释与版本管理规范代码注释这件事我的原则是每个函数头部写清楚功能、参数、返回值每个关键变量写清楚用途每个不直观的操作写清楚原因。比如DHT11的40us延时我会注释延时40us后采样此时0的高电平已结束1的高电平仍在持续。版本管理我用Gitcommit信息遵循模块: 操作的格式比如dht11: 修复读取超时问题、oled: 优化刷新逻辑减少闪烁。每个版本打一个tag比如v1.0、v1.1。这样别人下载的时候可以选择稳定版本而不是直接拿最新的开发版。6.3 常见复现问题与排查清单根据我收到的反馈别人复现这个项目时最常遇到的问题有这么几个问题现象可能原因排查方法编译报错找不到头文件芯片包版本不对检查是否安装了STM32F1xx_DFPDHT11读取一直失败上拉电阻没接或阻值太大用万用表测数据线电压空闲时应为3.3V超声波测距值固定不变Echo引脚没接对或定时器没配置用示波器看Echo引脚有没有脉冲OLED不亮I2C地址不对或上拉电阻缺失用I2C扫描程序确认设备地址仿真跑不起来hex文件路径不对或模型库缺失检查仿真工程里的hex文件路径我把这个表格直接放进了README的常见问题章节后来反馈说这个表格帮了大忙很多人照着排查就解决了。7. 从能跑到好用几个提升项目质量的细节7.1 用定时器中断做软时钟替代delay项目里如果到处用delay_ms()CPU大部分时间都在空转效率很低。我的做法是用SysTick或者TIM2做一个1ms的软时钟主循环里用状态机来调度任务。比如每100ms读一次DHT11每50ms读一次超声波每200ms刷新一次OLED。这样CPU利用率从原来的不到10%提升到了60%以上而且响应更及时。具体实现是定义一个全局变量volatile uint32_t tick_ms在SysTick中断里自增。主循环里用if (tick_ms - last_dht11_tick 100)来判断是否该执行DHT11读取。这个模式在stm32项目里非常通用建议养成习惯。7.2 串口打印调试信息的正确姿势调试阶段串口打印是最直接的观察手段。但很多人用printf的时候忘了重定向fputc函数导致串口没输出。正确的做法是在代码里加上int fputc(int ch, FILE *f) { USART_SendData(USART1, (uint8_t)ch); while (USART_GetFlagStatus(USART1, USART_FLAG_TC) RESET); return ch; }然后在Keil的Target选项里勾选Use MicroLIB。这样printf就能正常输出了。我习惯在每读取一次传感器后打印一行数据格式是T:25.3 H:60.2 D:48.5方便用串口助手观察趋势。7.3 电源管理与低功耗的初步考虑虽然这个项目是USB供电不需要考虑低功耗但养成好习惯没坏处。我在代码里加了一个Enter_Sleep()函数主循环空闲时调用__WFI()指令让CPU进入睡眠模式等中断唤醒。实测下来工作电流从28mA降到了12mA左右。如果你后续想用电池供电这个改动是必须的。另外OLED屏幕在不需要显示的时候可以发送关闭显示命令DHT11和超声波模块也可以在不读取的时候断电。这些细节在基于STM32的毕业设计里往往是加分项评委看到你有低功耗意识印象分会高不少。8. 关于开源这件事的一些个人体会把代码、原理图、仿真三样东西整理好开源出去花的时间比写代码本身还多。但我觉得值得。因为我自己在学习STM32的时候最痛苦的就是找到一个项目代码能编译但原理图对不上或者原理图能看但仿真跑不起来。那种感觉就像拼图少了几块明明知道全貌就在眼前就是拼不出来。这次整理过程中我最大的收获是学会了站在复现者的角度思考。每写一行代码我都会想别人拿到这行代码知道它对应哪个引脚吗每画一根线我都会想别人看到这根线知道它连到代码里的哪个宏定义吗这种换位思考的习惯后来也影响了我做其他项目的方式。如果你也在准备开源自己的STM32项目我的建议是先别急着上传找一个没接触过这个项目的朋友让他按照你的README从头跑一遍。他卡住的每一个地方都是你需要补充说明的地方。这个过程可能来回好几次但最终出来的项目质量会比你自己闷头整理高出一大截。最后分享一个我常用的检查清单每次开源前过一遍代码能编译吗原理图能打开吗仿真能跑通吗三者引脚对应吗README写清楚了吗别人问的问题我能回答吗这六个问题都答是这个项目才算真正开源了。