企业官网建设流程全解析

简介：本资源是面向嵌入式初学者与STM32开发者的DHT11温湿度传感器实战项目，聚焦于STM32F103VE平台的软硬件协同仿真与调试，解决环境参数采集、串口通信及OLED可视化显示等典型物联网感知层开发问题。压缩包共398个文件，涵盖112个头文件（h，定义外设驱动与数据结构）、73个C源文件（c，含DHT11单总线协议解析、HAL库初始化、OLED驱动及串口打印逻辑）、56个依赖文件（d）与目标文件（o），以及工程配置（uvprojx、uvoptx）、链接脚本（sct）、可执行镜像（hex、axf）等完整构建产物，整体大小为21.24MB。已有221人下载学习，资源结构清晰，包含标准HAL库工程框架、模块化传感器驱动、多级调试输出（串口+OLED双路数据显示），并附带可直接编译运行的完整Keil MDK工程，便于快速验证时序逻辑、排查单总线通信异常，是掌握STM32基础外设驱动与传感器集成的高实用性参考方案。

1. 为什么要先做仿真，再碰开发板

不少刚接触STM32的朋友，手里板子还没捂热，就急着接传感器、写驱动。结果往往是杜邦线松了、引脚复用配错了、时序对着示波器看半天也对不上，最后怀疑自己代码写错了，其实硬件上早就有接触不良的问题。这种时候，你很难判断到底是代码问题、接线问题还是芯片本身的问题。

我的建议很直接：先用仿真把驱动逻辑跑通，再做真实硬件。仿真环境虽然不能替代真实电气特性，但对于DHT11这种单总线协议芯片来说，仿真能做到时序可见、逻辑可断、错误可查，这对理解协议本身的价值远远大于“点个灯”。

这篇内容就是围绕“STM32 + DHT11 + 仿真”这条线展开的。我会从软件选型讲到工程配置，再讲到DHT11时序驱动的完整实现，最后把仿真阶段常见的坑也一并列出来。这套流程我前后跑过不少遍，结论是：如果你能把Proteus里的DHT11跑出稳定的温度湿度，那真实硬件上大概率也差不到哪去——前提是你代码别乱写。

这文章适合这些人看：

• 刚学STM32，想搞明白单总线协议到底是怎么一回事的
• 手头有开发板但没传感器，或者不想频繁插拔硬件的
• 准备用江科大风格或HAL库风格写DHT11驱动，但不太确定时序怎么处理的
• 想用Wokwi这类在线平台快速验证代码逻辑的

仿真方案市面上主流有两种：一是Proteus + Keil/STM32CubeIDE，二是Wokwi在线仿真。两种我都用，前者更适合精细调时序，后者胜在零配置、打开浏览器就能写。这篇文章以Proteus为主，Wokwi的部分会单独抽出一个小节讲，因为最近用Wokwi做DHT11仿真的人确实越来越多了。

2. 方案选型：为什么是Proteus，为什么还要配合CubeMX

2.1 Proteus仿真DHT11的前置条件

Proteus是一款能跑MCU仿真的电路设计软件，常见版本是8.x。它能从元件库拉一个STM32F103C8出来，再拉一个DHT11，直接连线仿真。它最方便的地方在于：不需要你买任何硬件，不需要焊接，甚至连开发环境都可以只用Keil编译出hex文件丢进去跑。

但需要注意，Proteus对STM32仿真的支持依赖于内置的芯片模型。F103C8是仿真模型最稳定、资料最多的型号，网上搜得到的问题基本都是围绕这颗芯片展开的。如果你在Proteus里搜不到型号，优先确认软件版本，我早期用7.x版本查STM32型号就很吃力，后面换到Proteus 8.9才顺畅。

Proteus的DHT11模型，是一个已经内置了传感器逻辑的虚拟器件。你不需要真的在仿真图里写传感器内部逻辑，它会根据你主机发送的起始信号，自动返回40位温湿度数据。这跟真实DHT11行为基本一致。所以你在仿真里调的，主要是主机端的时序和数据处理逻辑。

2.2 用STM32CubeMX做初始化，少写一半代码

这里必须提STM32CubeMX。很多STL库风格的老教程会带着你手动配置时钟树、GPIO模式。虽然能练基本功，但我个人建议初始化全交给CubeMX，把精力集中在DHT11的时序协议和数据处理上，这才是这个项目的核心难点。

CubeMX选芯片型号STM32F103C8，时钟配置为72MHz主频（8MHz外部晶振，PLL 9倍频），GPIO方面把PC13设置成GPIO_Output（如果可以接一个虚拟LED做指示），DHT11数据引脚选PA0或PB8这类普通IO，模式设为GPIO_Output/Input均可，因为DHT11驱动要求主机代码里动态切换IO方向。

串口方面建议打开USART1，异步模式，波特率115200，这样仿真时可以把温湿度数据直接打印到虚拟终端上。如果你打算用OLED显示数据，Proteus也有OLED模型，但初次上手建议先用串口打印，代码路径短，排查起来更快。

CubeMX生成代码之后，再在main.c里添加DHT11驱动逻辑。Proteus工程里只需要放一个DHT11、一个STM32F103C8、一个虚拟终端和一个上拉电阻（DHT11数据线需要4.7kΩ到10kΩ的上拉），连线干净利落。

2.3 两种仿真平台的核心差异对照

为了减少大家选择困难，我把Proteus和Wokwi的差异整理在下面：

我的使用习惯是：如果我要给别人讲清楚“单总线时序是什么”，我用Proteus；如果我只是想快速验证一段DHT11驱动能不能跑，我用Wokwi。两个方案并行不冲突，代码也几乎不用改——HAL库的GPIO操作接口是统一的。

3. DHT11协议解析：仿真前必须吃透的底层逻辑

3.1 DHT11的单总线通信机制

DHT11温湿度传感器用的通信方式叫“单总线”（1-Wire），意思是一根数据线既当输入又当输出，通信双方靠时序区分当前是谁在说话。主机发指令、传感器回数据，全部在这根线上完成。

这和I2C、SPI这类有独立时钟线的协议完全不同。没有时钟线意味着“时序”就是一切。什么时候拉低、拉高多久、什么时候释放总线让传感器接管，这些都需要微秒级的控制精度。理解了这一点，你就明白为什么DHT11驱动里最核心的不是算法，而是延时函数的准确性。

DHT11完整通信流程如下：

1. 主机拉低数据线，至少保持18ms以上，作为起始信号
2. 主机释放总线（拉高），等待20~40us
3. DHT11检测到起始信号后，先拉低约80us响应，再拉高约80us
4. 随后DHT11连续发送40位数据，每一位都以50us低电平开头
5. 数据位0的高电平持续26~28us，数据位1的高电平持续70us左右
6. 40位数据全部传输完毕后，DHT11释放总线

数据格式上，这40位是：湿度整数部分（8bit）+ 湿度小数部分（8bit）+ 温度整数部分（8bit）+ 温度小数部分（8bit）+ 校验和（8bit）。校验和等于前四个字节相加的低8位，如果对不上，说明这次读取无效，应当丢弃。

3.2 为什么DHT11的时序必须用微秒级延时

STM32主频72MHz意味着一个时钟周期大约13.9ns。DHT11时序最敏感的地方，是高电平持续时间的判断：26~28us代表0，70us代表1。如果延时误差超过±10us，就有极大概率误判。

这里就引出一个很多新手都会踩的坑：HAL库里默认的HAL_Delay()只能做到毫秒级延时，微秒级它不管。如果你直接在代码里调用HAL_Delay(20)，实际延时可能是20ms而不是20us，整个时序直接乱套。

解决办法有几种：

• 自己写一个微秒级延时函数，基于SysTick或DWT实现
• 直接使用定时器的单脉冲模式做精确延时
• 在Proteus仿真里，用普通延时循环（空循环等待）也能凑合，因为仿真没有真实晶振的抖动问题，但代码移植到真硬件时误差会暴露

我个人推荐用DWT（Data Watchpoint and Trace）实现微秒延时，原因在于：不占用额外定时器资源，代码量少，精度高。后面会给出可直接用的代码。

3.3 DHT11温湿度数据格式详解

用表格把40位数据拆开来看会更清晰：

DHT11本身精度不高：湿度精度±5%RH，温度精度±2℃，采样周期要求不低于1秒一次。所以你写驱动时，读传感器频率不要超过1Hz，读得太频繁，传感器可能不响应。

校验和的判断很重要，因为DHT11是单总线通信，信号在长线上衰减或受干扰，很容易出现个别位跳变。校验和一旦对不上，这次数据直接丢弃，不参与显示，这是驱动健壮性的基本要求。

4. 搭建仿真工程：CubeMX配置与Proteus连线

4.1 STM32CubeMX侧配置步骤

我这里以STM32F103C8为例，把步骤列一遍，跟着做就能出初始化工程。

第一步，新建工程，选芯片：打开STM32CubeMX，点击“New Project”，在MCU Selector里输入STM32F103C8，选择LQFP48封装的那颗。确认后进入Pinout视图。

第二步，配置时钟树：在“Clock Configuration”标签页，设置HSE为Crystal/Ceramic Resonator，PLL Source选择HSE，系统时钟SYSCLK设为72MHz。CubeMX会自动推导各总线时钟，确认APB1为36MHz、APB2为72MHz即可。

第三步，配置GPIO：在Pinout视图中找到PA0（或PB8），点击它并选择GPIO_Output。然后点击左侧“System Core > GPIO”，在GPIO配置界面把PA0的GPIO output level设为High，因为DHT11空闲状态总线应保持高电平。

第四步，配置USART1：点击PA9（USART1_TX）和PA10（USART1_RX），选择USART1异步模式。波特率设115200，数据位8，停止位1，无校验。这样后续可以用串口打印调试信息。

第五步，生成代码：Project Manager里设置工程名和保存路径，IDE选择MDK-ARM（如果你用Keil）或STM32CubeIDE。生成后建议选“Open Project”直接打开。

检查点：生成的main.c里，HAL_Init()和SystemClock_Config()会默认存在，GPIO初始化在MX_GPIO_Init()里，USART初始化在MX_USART1_UART_Init()里。所有初始化在main()里依次调用，确认无误再进行下一步。

4.2 Proteus电路搭建详细步骤

Proteus里新建工程，选择“Schematic Capture”。

第一步，放置MCU：在元件搜索栏输入STM32F103C8，双击添加到原理图。注意芯片封装选择带引脚号的型号，不要选成不带引脚的抽象模型。

第二步，放置传感器：搜索DHT11，同样双击添加。Proteus的DHT11模型长得像一个三脚器件，实际上DHT11有4个引脚但只有3个有效（VCC、DATA、GND）。

第三步，放置虚拟终端：搜索“VIRTUAL TERMINAL”，添加。这是Proteus的调试利器，可以模拟串口调试助手显示数据。把RXD接到STM32的PA9（TX），TXD接到PA10（RX）。虚拟终端还需要设置波特率：双击进入属性，把Baud Rate设为115200，与代码一致。

第四步，放置上拉电阻：搜索RES，阻值设为10kΩ。一端接DHT11的DATA引脚，另一端接3.3V电源。上拉电阻在单总线里是必须的，它保证总线空闲时处于高电平。

第五步，放置电源和地：点击左侧端子模式的“POWER”“GROUND”，分别接到各器件的VCC和GND。DHT11的VCC接3.3V，GND接系统地。POWER端子默认电压5V，需要双击改成3.3V，否则白接。

第六步，连线：PA0连到DHT11的DATA脚，VCC和GND分别接好。需要特别留意：ST-Link、板载LED这些可以不画，仿真只看最小系统加传感器就行。

所有连线完成后，双击电源端子确认电压值都正确，然后可以进入下一步写固件。

4.3 Keil工程配置与hex文件生成

CubeMX生成的工程，如果用MDK-ARM打开，还需要在魔术棒（Options for Target）里做两个关键设置。

第一，Debug选项卡里选择“Use Simulator”或“Use”指定的调试器——这个取决于你是打算在Keil里直接仿真还是烧录hex给Proteus。如果走Proteus路线，你只需要生成hex文件，不需要在Keil里跑在线调试。

第二，Output选项卡勾选“Create HEX File”。这样编译之后会在工程目录的Objects文件夹下生成hex文件，Proteus直接加载这个文件运行。

另外建议在C/C++选项卡中把优化等级设置为-O0，至少在第一个DHT11驱动版本时这么干。因为优化器可能会把你写的空循环延时优化掉——原本想循环等待50us，结果编译器认为“循环体没有副作用”，直接跳过，时序完全崩掉。这在仿真阶段非常容易出现，但很多人没往编译器上想。

5. DHT11驱动核心代码实现

5.1 微秒延时实现：DWT方案

DWT是Cortex-M3内核自带的一个调试单元，其中有一个CYCCNT寄存器，用来记录CPU时钟周期数，精度很高，而且不占用额外的定时器外设。

以下是基于DWT的微秒延时函数，用HAL库编译环境实测通过：

#include "stm32f1xx_hal.h" static volatile uint32_t uwTick_dwt; void DWT_Delay_Init(void) { CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk; DWT->CYCCNT = 0; DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk; } void DWT_Delay_us(uint32_t us) { uint32_t startTick = DWT->CYCCNT; uint32_t delayTicks = us * (SystemCoreClock / 1000000U); while ((DWT->CYCCNT - startTick) < delayTicks); }

使用之前先调用一次DWT_Delay_Init()，然后就可以随意调用DWT_Delay_us()做微秒延时了。在72MHz主频下，延时1us约等于72个时钟周期，计算粒度足够满足DHT11的时序要求。

还有一个常见替代方案是SysTick。但SysTick在HAL库中已经被用于HAL_Delay()的毫秒时钟基准，你自己再用可能会导致冲突。DWT的好处就是彻底独立。如果是基于标准外设库或LL库，也可以用类似的方式实现。

5.2 位操作宏：GPIO方向切换与电平控制

DHT11通信过程中，GPIO要反复在输出模式和输入模式之间切换。使用HAL库时，可以通过这样的方式封装：

#define DHT11_PORT GPIOA #define DHT11_PIN GPIO_PIN_0 void DHT11_Pin_Output(void) { GPIO_InitTypeDef GPIO_InitStruct = {0}; GPIO_InitStruct.Pin = DHT11_PIN; GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP; GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(DHT11_PORT, &GPIO_InitStruct); } void DHT11_Pin_Input(void) { GPIO_InitTypeDef GPIO_InitStruct = {0}; GPIO_InitStruct.Pin = DHT11_PIN; GPIO_InitStruct.Mode = GPIO_MODE_INPUT; GPIO_InitStruct.Pull = GPIO_PULLUP; HAL_GPIO_Init(DHT11_PORT, &GPIO_InitStruct); } #define DHT11_HIGH() HAL_GPIO_WritePin(DHT11_PORT, DHT11_PIN, GPIO_PIN_SET) #define DHT11_LOW() HAL_GPIO_WritePin(DHT11_PORT, DHT11_PIN, GPIO_PIN_RESET) #define DHT11_READ() HAL_GPIO_ReadPin(DHT11_PORT, DHT11_PIN)

每次切换IO模式时，HAL_GPIO_Init内部会重新配置寄存器，会多花一些时间。好在DHT11时序允许的裕量足够，这个时间不会造成误判。如果你追求极致性能，可以用寄存器直接操作CRL寄存器切方向，但代码可读性会下降，我建议保持HAL风格。

5.3 DHT11起始信号与响应检测实现

主机发起通信的代码逻辑如下：

uint8_t DHT11_Start(void) { uint8_t retry = 0; // 主机拉低至少18ms DHT11_Pin_Output(); DHT11_LOW(); DWT_Delay_us(20000); // 20ms，宁长勿短 // 释放总线，上拉电阻将总线拉高 DHT11_HIGH(); DWT_Delay_us(30); // 等待20~40us // 切换为输入模式，等待传感器响应 DHT11_Pin_Input(); // 等待总线被DHT11拉低（从高到低跳变） while (DHT11_READ() == GPIO_PIN_SET) { if (++retry > 100) return 1; // 超时 DWT_Delay_us(1); } // 等待响应低电平结束（约80us） retry = 0; while (DHT11_READ() == GPIO_PIN_RESET) { if (++retry > 200) return 1; DWT_Delay_us(1); } // 等待响应高电平结束（约80us） retry = 0; while (DHT11_READ() == GPIO_PIN_SET) { if (++retry > 200) return 1; DWT_Delay_us(1); } return 0; }

这里有个细节：起始信号的拉低时间，DHT11数据手册要求最短18ms，实际我调20ms，留出裕量。太短的话传感器可能检测不到起始信号，太长也没什么大问题，只是总线占用时间变长。仿真阶段建议用20ms，因为仿真器在时间上的表现与实际晶振略有偏差。

响应检测里的两个“等待跳变”循环，本质上是同步握手的过程——只有确认了传感器的80us低电平和80us高电平，才能确保后续数据位的读取节奏是对的。很多DHT11驱动写不好，就是因为少等了一个高电平响应，导致后续采样点错位。

5.4 8位数据读取与40位数据组包

读一位的核心代码：

uint8_t DHT11_ReadBit(void) { uint8_t retry = 0; // 等待低电平结束（50us低电平是每一位的前导） while (DHT11_READ() == GPIO_PIN_RESET) { if (++retry > 200) return 0xFF; DWT_Delay_us(1); } // 高电平持续时间长短决定0/1 DWT_Delay_us(40); if (DHT11_READ() == GPIO_PIN_SET) return 1; else return 0; } uint8_t DHT11_ReadByte(void) { uint8_t data = 0; for (int i = 0; i < 8; i++) { uint8_t bit = DHT11_ReadBit(); if (bit == 0xFF) return 0xFF; data = (data << 1) | bit; } return data; }

读一位的原理是：每一位数据都以50us低电平开头。当检测到低电平跳变为高电平后，延时40us再读总线状态。如果此刻总线仍为高，说明这是“长高电平”，即数据位1；如果已经变回低电平，说明是“短高电平”，即数据位0。40us这个采样点，就是在0和1的持续时间中间取一个安全判定点。

为什么不是直接读完高电平宽度再判断？因为单总线没有时钟线，主机无法精确同步每一位的边界。所以业界通用做法就是用延时采样，只要延时点落在安全区间内，就能正确区分0和1。DHT11的0高电平持续26~28us，1高电平持续70us，40us这个点明显偏向1，但不会超过0的持续时间，也不会错过1的结束时间，是个非常稳妥的采样点。原型验证时也可以用逻辑分析仪抓一遍这个点的实际波形，确认无误。

5.5 温湿度数据解析与校验

主函数里的调用逻辑如下：

typedef struct { uint8_t humi_int; uint8_t humi_dec; uint8_t temp_int; uint8_t temp_dec; uint8_t checksum; } DHT11_Data; uint8_t DHT11_Read(DHT11_Data *data) { if (DHT11_Start() != 0) return 1; uint8_t buf[5] = {0}; for (int i = 0; i < 5; i++) { buf[i] = DHT11_ReadByte(); if (buf[i] == 0xFF) return 1; } uint8_t sum = buf[0] + buf[1] + buf[2] + buf[3]; if (sum != buf[4]) return 1; >#include <stdio.h> int fputc(int ch, FILE *f) { HAL_UART_Transmit(&huart1, (uint8_t *)&ch, 1, 0xFFFF); return ch; } // 然后在main循环里直接printf printf("Temp: %d.%d C, Humi: %d.%d %%\r\n", dht11_data.temp_int, dht11_data.temp_dec, dht11_data.humi_int, dht11_data.humi_dec);

如果在Proteus的虚拟终端里看到这样的输出，说明DHT11驱动已经完整跑通了：

Temp: 28.0 C, Humi: 50.0 % Temp: 28.0 C, Humi: 50.0 %

Proteus内置DHT11模型的默认温湿度值就是28℃/50%，仿真阶段数据显示稳定、数据不跳变即可认为成功。

6. Proteus仿真联调：从编译到出结果的全过程

6.1 生成hex文件并加载到Proteus

Keil中编译工程，确认无error无warning。然后回到Proteus，双击STM32F103C8芯片，在Program File一栏选择刚刚生成的hex文件，Clock Frequency保持默认即可。

点击Proteus左下角的运行按钮，仿真开始运行。如果一切正常，虚拟终端会开始打印温湿度数据。如果虚拟终端没有输出，先检查USART的波特率设置是否与代码一致；再检查PA9/PA10是否连接正确；还有一点容易被忽略——虚拟终端的RX必须接STM32的TX，TX接RX，交叉连接，接反了什么也收不到。

6.2 波形观察与灰常细致的断点调试

Proteus有一个非常大的优势：可以直接看数据引脚的实时波形。在DHT11的数据线上右键，选择“Digital Trace”，就能看到ADC/DIO波形，这比任何串口日志都直观。

你可以把DHT11引脚拖进波形窗口，然后观察起始信号的低电平宽度、响应波形的80us脉冲、以及每一位的50us+高电平持续时间。对照前面讲的时序参数，你就知道到底哪一步出了偏差。

如果波形显示起始信号只有几毫秒而代码写的是20ms，大概率是DWT_Delay_Init没调用，或者CPU时钟频率配置不对，导致延时计算参数错误。如果数据位的高电平持续时间全是同样宽度，说明传感器的响应你可能根本没读到——检查上拉电阻是否接上，因为数据线高电平状态依赖上拉电阻，总线悬空时电平不稳定，读出来的位很可能全是0xFF。

6.3 在Wokwi上快速验证DHT11驱动代码

如果你不想装Proteus这么大体积的软件，Wokwi是个很好的轻量替代方案。打开wokwi.com，新建一个STM32F103C8项目，在diagram.json里加入DHT11器件：

{ "version": 1, "author": "yourname", "editor": "wokwi", "parts": [ { "type": "wokwi-mcu-stm32f103c8", "id": "mcu" }, { "type": "wokwi-dht11", "id": "dht1", "attrs": { "temperature": "28", "humidity": "50" } } ], "connections": [ [ "mcu:PA0", "dht1:DATA", "orange", [ "a0", "d0" ] ], [ "mcu:3V3", "dht1:VCC", "red", [ "a0" ] ], [ "mcu:GND", "dht1:GND", "black", [ "a0" ] ] ] }

支持直接在浏览器里写代码、编译、运行，还能用串口监视器看printf输出。不过Wokwi的DHT11模型没有数据线波形图，只能确认逻辑正确性，不适合进一步分析时序细节。

7. 常见问题排查：仿真DHT11最容易踩的坑

7.1 温度湿度一直显示0或FF

这个现象很典型。可能的原因顺序排查：

1. 微秒延时函数没有正常工作——先打印一下DWT的初始化是否被调用
2. 上拉电阻没接或阻值太大——确认10kΩ接到了3.3V
3. 起始信号拉低时间不够长——检查DWT_Delay_us(20000)是否真的延时了20ms，可以在延时前后翻转一个LED引脚观察时间差
4. 数据读取超时循环退出后就当作读取失败——补一下超时打印，看看卡在Start阶段还是ReadByte阶段

如果你是直接抄的网上代码，优先怀疑是延时参数不匹配。不同主频下的延时数值差异巨大，72MHz下能跑通的延时参数，你不一定匹配。先确认SystemCoreClock的值再调试。

7.2 校验和经常错误

校验和错误说明个别bit读取有误。产生原因通常是采样点太靠近边界，比如你在高电平开始后延时50us再判断，在数据位0（持续26~28us）里，到50us时总线早已拉低，这一位会被识别为0——但如果这一位实际上是1，你等到50us时高电平刚好还没结束，又可能误判为1。把采样点改到40us是通用安全的做法。

另一个原因是模式切换太频繁导致GPIO配置时间叠加。每次DHT11_Pin_Input()和DHT11_Pin_Output()切换都会引入微秒级延迟，如果在ReadBit里也频繁切换，就会积累误差。建议的做法是：整个数据读取阶段全程保持输入模式，进出函数时只切换一次方向。只有在发起起始信号时才需要切到输出模式。

7.3 Proteus仿真速度很慢怎么办

Proteus的MCU仿真是指令级仿真，跑起来比真实芯片慢很多。遇到这种情况，可以把Proteus的仿真帧率调到更高：在菜单栏选择System > Animation Speed，调成帧率优先；另外把DHT11的读取周期从每秒2次改成每2秒1次，减少仿真负载，不影响验证结果。

7.4 代码用了HAL库但Proteus不跑

很可能是CubeMX配置生成的初始化代码里包含了看门狗。Proteus的STM32模型虽然支持IWDG，但仿真时触发看门狗复位的时机不太稳定，经常导致程序反复复位，看起来就像“程序没跑起来”。解决办法：在CubeMX里关闭IWDG，并确认RTC唤醒等也保持禁用，让工程从最简单状态起步。

7.5 参考了网上代码但读取不到数据

网上的DHT11代码质量参差不齐，特别是标准库和HAL库混在一起的情况很常见。先确认你的GPIO时钟有没有使能——CubeMX生成代码默认会打开AHB/APB时钟，但如果手动写了GPIO操作却忘了对应时钟，读到的引脚状态永远不对。把HAL_GPIO_ReadPin的结果打印出来，看看是不是恒定高或恒定低，再顺着时钟、模式、上拉顺序排查。

8. 一个细节：Proteus里DHT11无法修改温湿度怎么办

很多人会问，仿真里DHT11的温度一直显示28℃，湿度一直50%，能不能改？Proteus的DHT11模型本身是静态的，改不了环境参数。如果你需要验证不同温湿度下的数据处理逻辑（比如高温报警、低温报警），可以改用Wokwi——它的DHT11模型可以设置初始温度和湿度，也能在仿真过程中通过滑块实时调整，用来验证上位逻辑非常方便。

如果你坚持用Proteus，也有一个取巧的方案：直接用代码把传感器的返回值改成你想要的测试值，比如读完之后人为加上一个偏移量，验证你的阈值逻辑。这不算造假，测试本就该与传感器实际值解耦。

9. 实操心得：仿真成功之后，上板迁移必做的三件事

仿真跑通了，只是第一步。把这套代码迁移到真实STM32开发板时，我的建议是先做三件事再上传感器。

第一件事，关掉编译器优化。转到-O0编译，确认真实硬件上的表现与仿真一致。有些代码在-O2优化下行为会变，尤其是循环延时和寄存器操作。等代码稳定了再逐步打开优化测试。

第二件事，实测延时函数。在板子上临时写个跑马灯，翻转一个GPIO引脚，用示波器量高电平持续时间和期望值是否一致。DWT_Delay_us(1000)应该实测1ms，误差应在几微秒内。如果偏差太大，检查SystemCoreClock是否真的等于72000000。

第三件事，检查上拉电阻。手头如果没有4.7kΩ~10kΩ的电阻，千万别直接拿杜邦线把数据引脚接3.3V，那等于硬灌电流，可能会损伤引脚。DHT11模块大多数自带上拉电阻，但如果用的是裸传感器，一定自己接一个。在仿真里漏了上拉还有模型兜底，真硬件上漏了基本读不到数据。

这三件事做完，再把DHT11接上，你的成功率会高很多。

10. 最后的经验小结

我个人在带新手做STM32项目时，几乎都会拿DHT11当入门传感器。原因是它足够简单，但又不像LED灯那样“简单到没营养”。单总线协议、微秒级时序、校验和数据解析，这些概念在DHT11身上都能练到，而且练完可以直接推广到DS18B20、DHT22等其他单总线传感器上，通用性非常强。

仿真这件事，初学者常常低估它的价值，觉得“仿真跑通了也说明不了什么”。但当你后面遇到真硬件问题、无法区分是代码还是电路问题时，就会后悔当初没有多在仿真阶段把逻辑验证扎实。Proteus虽然用起来有一些小毛病，但在DHT11这类慢速传感器项目里，它的仿真结果和真实硬件行为几乎是对应的。

最后再分享一个小技巧：仿真成功之后，别急着删工程。把带注释的时序代码、验证过的延时函数、Proteus仿真图都留好。做下一个传感器项目时，直接复用这套驱动框架，改改引脚和协议细节，往往几个小时就能搞定。很多看起来复杂的项目，拆开看无非就是DHT11这种基础模块的堆叠和组合。

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