STM32F103驱动DHT22与BH1750三合一环境采集实战

简介：本资源是一套基于STM32F103单片机的多传感器环境监测完整工程，面向嵌入式初学者与课程设计实践者，解决温湿度及光照强度数据采集、解析与可视化显示的核心问题。项目涵盖DHT22（单总线协议）与BH1750（I²C协议）双传感器驱动开发，集成TFTLCD（ILI9341驱动，SPI接口）实时数据显示，完整呈现从底层外设配置（RCC、GPIO、TIM、I²C）、传感器通信时序实现、数据校验转换到图形界面输出的全链路代码实践。压缩包含150个文件，以37个.h头文件和35个.c源文件为主体，辅以编译中间文件（.o/.d/.crf）及Keil工程配置（.uvprojx/.uvoptx/.sct），总大小3.08MB，结构规范，便于理解模块划分与工程组织逻辑。已有8875人学习下载，提供可直接编译运行的完整源码、清晰接线说明及典型传感器驱动范例，是掌握STM32外设驱动、协议解析与嵌入式人机交互开发的优质实操素材。

1. STM32F103驱动DHT22与BH1750：温湿度+光照三合一采集，为什么不用Arduino而选它？

某高校嵌入式课程设计里，学生常卡在“传感器数据飘、时序一错全崩、串口打印全是0xFF”这三连击上。我带过几届实训，发现80%的翻车不是硬件接错，而是对STM32F103这类Cortex-M3芯片的时序敏感性和外设资源调度逻辑缺乏实感——DHT22靠单总线协议“挤”出40位数据，要求微秒级精度；BH1750走I²C但默认地址易冲突、模式切换不规范就锁死总线。Arduino库帮你藏了这些黑匣子，而STM32F103裸机开发逼你直面：GPIO翻转延迟、SysTick中断抖动、I²C时钟拉伸响应、甚至Keil编译器优化等级对__nop()插入效果的影响。这份资源不是“又一个例程”，它是某实验室调试三个月沉淀下来的可复现工程包：含完整MDK-ARM工程（含startup、RCC配置、GPIO初始化）、DHT22单总线精准时序实现（非延时函数，用SysTick+状态机）、BH1750标准/连续模式双路径读取、以及关键的传感器协同供电策略——DHT22启动电流峰值达2.5mA，若与BH1750共用LDO且未加退耦电容，光照读数会随温湿度采集周期规律跳变。适合想把“能亮灯”升级为“能稳采”的STM32初学者，也适合需要快速集成环境参数到工业节点的工程师。

2. DHT22单总线通信：从时序图到状态机，为什么延时函数是玄学起点

DHT22的通信本质是“主从握手+数据流同步”，但它的时序窗口极窄：起始信号低电平需≥800μs，高电平需≥80μs；数据位中，“0”为50μs低+27μs高，“1”为50μs低+70μs高。在STM32F103上，若用for(i=0;i<100;i++) __nop();这种粗放延时，实际耗时受编译器优化（-O0/-O2生成指令数不同）、Flash等待周期、甚至代码在内存中的对齐位置影响，误差常超±15%。我们放弃“调延时参数凑波形”的血泪经验，改用SysTick+状态机精确控时。

2.1 DHT22通信状态机设计原理

状态机将整个交互拆解为6个原子状态：IDLE（空闲）→START_LOW（主机拉低800μs）→START_HIGH（释放总线，等待DHT22响应）→RESPONSE（检测DHT22拉低80μs应答）→DATA_READ（循环读取40位）→CHECKSUM（校验）。每个状态由SysTick中断触发跳转，避免阻塞主循环。关键点在于：所有时间基准统一映射到SysTick计数值（假设系统时钟72MHz，SysTick重装载值9999，即1ms中断），例如800μs = 72个SysTick滴答（72MHz ÷ 1000 = 72000Hz → 1μs = 0.072滴答？不对！正确换算：1ms = 1000μs对应10000滴答 → 1μs = 10滴答 → 800μs = 8000滴答）。但实际工程中，我们直接用SysTick->VAL寄存器做微秒级倒计时，更可靠。

2.2 核心驱动代码：SysTick精准时序控制

// DHT22.h 中定义状态枚举与结构体 typedef enum { DHT22_IDLE, DHT22_START_LOW, DHT22_START_HIGH, DHT22_RESPONSE, DHT22_DATA_READ, DHT22_CHECKSUM } DHT22_StateTypeDef; typedef struct { DHT22_StateTypeDef state; uint8_t data[5]; // 存储40位数据（5字节） uint8_t bit_index; // 当前读取位索引（0~39） uint16_t timeout_cnt; // 超时计数器（防死锁） } DHT22_HandleTypeDef; extern DHT22_HandleTypeDef dht22_handle; // DHT22.c 中关键函数 void DHT22_Init(void) { RCC->APB2ENR |= RCC_APB2ENR_IOPAEN; // 使能GPIOA时钟 GPIOA->CRH &= ~(0xF << 0); // PA0配置为推挽输出 GPIOA->CRH |= (0x2 << 0); // 输出最大速度2MHz（降低噪声） GPIOA->BSRR = GPIO_BSRR_BS0; // 初始高电平 dht22_handle.state = DHT22_IDLE; } // SysTick中断服务函数中调用此函数（每10μs触发一次） void DHT22_Process(void) { static uint16_t us_counter = 0; switch(dht22_handle.state) { case DHT22_IDLE: if (dht22_trigger_flag) { // 外部触发采集 GPIOA->BSRR = GPIO_BSRR_BR0; // 拉低PA0 us_counter = 0; dht22_handle.state = DHT22_START_LOW; } break; case DHT22_START_LOW: if (us_counter >= 800) { // 精确800μs GPIOA->BSRR = GPIO_BSRR_BS0; // 释放总线 us_counter = 0; dht22_handle.state = DHT22_START_HIGH; } break; case DHT22_START_HIGH: if (us_counter >= 80) { // 等待DHT22响应（80μs） // 此时DHT22应拉低总线80μs作为应答 if ((GPIOA->IDR & GPIO_IDR_IDR0) == 0) { // 检测低电平 us_counter = 0; dht22_handle.state = DHT22_RESPONSE; } else if (us_counter > 100) { // 超时未响应 dht22_handle.state = DHT22_IDLE; dht22_error_flag = 1; } } break; case DHT22_RESPONSE: // DHT22拉低80μs后，再拉高80μs，然后开始发40位数据 // 此处省略详细状态跳转，重点看数据位解析逻辑 if (us_counter >= 80) { // 进入数据位采样窗口：在低电平后50μs处读取电平 if (us_counter == 50) { uint8_t level = (GPIOA->IDR & GPIO_IDR_IDR0) ? 1 : 0; // 根据level设置data[bit_index/8]对应bit if (level) { dht22_handle.data[bit_index/8] |= (1 << (7 - bit_index%8)); } else { dht22_handle.data[bit_index/8] &= ~(1 << (7 - bit_index%8)); } bit_index++; if (bit_index >= 40) { dht22_handle.state = DHT22_CHECKSUM; } } } break; } us_counter++; }

提示：SysTick配置必须与主频严格匹配
在SystemInit()后添加：

SysTick_Config(SystemCoreClock / 100000); // 10μs中断一次（100kHz）

若主频非72MHz，需重新计算分频值。此处10μs粒度足够覆盖DHT22最窄的27μs高电平窗口（误差<10%）。

2.3 为什么状态机比延时函数更鲁棒？

• 抗干扰：当主循环执行printf()或ADC采样等耗时操作时，SysTick中断仍准时触发，状态流转不受影响；
• 可调试：每个状态可加LED指示（如PA1亮表示RESPONSE态），用示波器抓波形验证；
• 易扩展：后续增加DHT22重试机制（失败后自动重发起始信号）只需在DHT22_IDLE态加计数器，无需重构延时逻辑。

3. BH1750光照传感器：I²C地址陷阱与连续模式避坑指南

BH1750通过I²C通信，看似比DHT22“友好”，实则暗藏三处高频翻车点：地址冲突、模式误设、时钟拉伸处理不当。某公司量产时曾因BH1750地址未硬编码，导致同一批PCB上部分模块无法识别——因为BH1750的ADDR引脚悬空时默认为0x23，但若PCB布线耦合到噪声，可能被误判为0x5C（ADDR接VCC）。更致命的是，若在ONE_TIME_HIRES_MODE下未及时读取数据，传感器会进入休眠，下次通信需重新发送启动命令，而很多例程忽略此流程。

3.1 I²C硬件连接与地址确认

BH1750支持两种I²C地址：

• ADDR接地 → 0x23（7位地址）
• ADDR接VCC → 0x5C（7位地址）
  必须物理确认ADDR引脚电平！用万用表测BH1750模块上ADDR焊盘对GND电压：若<0.8V视为接地，否则检查是否虚焊或上拉电阻失效。在代码中强制指定地址，而非依赖“自动探测”：

#define BH1750_ADDR_0X23 0x46 // 0x23 << 1 = 0x46（8位写地址） #define BH1750_ADDR_0X5C 0xB8 // 0x5C << 1 = 0xB8 // 初始化时明确选择 uint8_t bh1750_addr = BH1750_ADDR_0X23; // 根据硬件焊接决定

3.2 两种工作模式的本质区别

注意：连续模式下，若I²C总线被其他设备占用超时，BH1750可能丢失数据更新。我们采用“读取前先发软复位命令0x07”的保险策略，确保状态机归零。

3.3 完整I²C读取函数（基于标准外设库）

// 使用STM32F103标准库的I2C驱动 #include "stm32f10x_i2c.h" uint16_t BH1750_ReadLight(void) { uint8_t data[2]; // 步骤1：发送软复位（清除可能的挂起状态） I2C_GenerateSTART(I2C1, ENABLE); while(!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT)); I2C_Send7bitAddress(I2C1, bh1750_addr, I2C_Direction_Transmitter); while(!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED)); I2C_SendData(I2C1, 0x07); // 软复位命令 while(!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_TRANSMITTED)); I2C_GenerateSTOP(I2C1, ENABLE); // 步骤2：发送测量命令（以连续模式为例） I2C_GenerateSTART(I2C1, ENABLE); while(!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT)); I2C_Send7bitAddress(I2C1, bh1750_addr, I2C_Direction_Transmitter); while(!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED)); I2C_SendData(I2C1, 0x10); // CONTINUOUS_HIGH_RES_MODE while(!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_TRANSMITTED)); I2C_GenerateSTOP(I2C1, ENABLE); // 步骤3：延时等待测量完成（连续模式需≥120ms） Delay_ms(130); // 保守取130ms // 步骤4：读取2字节数据 I2C_GenerateSTART(I2C1, ENABLE); while(!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT)); I2C_Send7bitAddress(I2C1, bh1750_addr, I2C_Direction_Receiver); while(!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_RECEIVER_MODE_SELECTED)); // 读取MSB while(!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_RECEIVED)); data[0] = I2C_ReceiveData(I2C1); // 读取LSB while(!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_RECEIVED)); data[1] = I2C_ReceiveData(I2C1); I2C_GenerateSTOP(I2C1, ENABLE); return (data[0] << 8) | data[1]; // 合成16位数据 }

关键参数说明：

• Delay_ms(130)不可省略！BH1750手册明确要求连续模式下两次读取间隔≥120ms，否则返回旧数据；
• I2C_CheckEvent()必须逐字节校验，不能只查I2C_EVENT_MASTER_BYTE_TRANSMITTED，否则地址错误时会死等；
• 若使用HAL库，需禁用HAL_I2C_Master_Transmit_IT()的自动重试，因其可能掩盖地址错误。

4. 多传感器协同供电与时序调度：为什么温湿度和光照数据会相互污染？

当DHT22与BH1750共用同一组电源（如AMS1117-3.3V LDO）时，常见现象是：每次DHT22采集后，BH1750读数突降10%~15%，且该偏差随DHT22采集频率升高而加剧。根源在于DHT22的瞬态电流冲击——其内部电容充电阶段峰值电流达2.5mA，导致LDO输出电压瞬间跌落（实测压降约80mV），而BH1750的I²C接口对VDD波动极其敏感，VDD下降会改变其内部ADC参考电压，造成光照值系统性偏低。这不是软件Bug，而是硬件-软件耦合问题。

4.1 供电隔离方案对比

我们采用**方案3（软件错峰）+ 方案1（硬件加固）**组合：在DHT22采集前10ms，主动给BH1750发0x07复位命令，使其在DHT22电流冲击期间处于高阻态，同时在LDO输入端并联22μF钽电容（非电解电容，ESR更低）。

4.2 主循环时序调度框架

// 主循环伪代码（基于FreeRTOS或裸机） uint32_t last_dht_time = 0; uint32_t last_bh1750_time = 0; const uint32_t DHT_INTERVAL = 2000; // DHT22每2秒采集一次 const uint32_t BH1750_INTERVAL = 1000; // BH1750每1秒采集一次 while(1) { uint32_t now = GetTickCount(); // 获取毫秒级系统时间 // 先读BH1750（因其更新快，且需避开DHT22冲击） if (now - last_bh1750_time >= BH1750_INTERVAL) { light_value = BH1750_ReadLight(); last_bh1750_time = now; // 关键：在BH1750读取后150ms，再触发DHT22（错开电流峰值期） if (now - last_bh1750_time >= 150) { dht22_trigger_flag = 1; // 触发DHT22状态机 } } // DHT22采集（仅在BH1750读取后150ms以上才允许） if (dht22_trigger_flag && (now - last_bh1750_time >= 150)) { if (DHT22_Read(&temp, &humi) == SUCCESS) { last_dht_time = now; dht22_trigger_flag = 0; } } // 其他任务... Delay_ms(10); // 10ms基础调度粒度 }

4.3 传感器数据融合验证方法

单纯看单次读数无意义，需验证长期稳定性：

• 将设备置于恒温恒光环境（如遮光箱+恒温水浴），连续记录24小时数据；
• 计算DHT22温湿度标准差：正常应<0.3℃/2%RH；
• 计算BH1750光照值方差：若DHT22采集时方差突增>5%，说明供电隔离不足；
• 用串口输出CSV格式：timestamp,temperature,humidity,light_lux，导入Excel画趋势图，观察是否存在周期性耦合纹波。

提示：DHT22的校准不可绕过
出厂DHT22存在±0.5℃温漂，建议用高精度温度计（如Fluke 1507）在25℃/50%RH环境下标定，记录偏差值，在软件中补偿：
compensated_temp = raw_temp + 0.3; // 示例补偿值

5. 避坑：DHT22与BH1750集成的五个血泪现场

实际部署中，90%的问题源于“以为接对了线，其实没接对”。以下是某实验室调试过程中记录的真实踩坑案例，按现象→原因→解决三步法整理，每条都经示波器验证。

5.1 现象：DHT22始终返回0xFF，示波器显示起始信号高电平仅40μs

原因：GPIO配置为开漏输出（Open-Drain），未外接上拉电阻，导致总线释放后无法拉高至3.3V，DHT22误判为通信异常。
解决：将PA0配置改为推挽输出（GPIO_Mode_Out_PP），或在外围电路中添加4.7kΩ上拉电阻至3.3V。

5.2 现象：BH1750读数固定为0x0000，I²C扫描工具显示地址0x23存在但无法通信

原因：BH1750模块的SCL/SDA线上串联了4.7kΩ限流电阻（部分廉价模块为防静电添加），导致上升沿过缓（>3μs），超出STM32F103 I²C标准模式（100kHz）要求的≤1μs。
解决：剪断模块上的限流电阻，或在软件中降低I²C时钟频率至50kHz（修改I2C_CCR寄存器）。

5.3 现象：DHT22与BH1750单独工作正常，合在一起时DHT22采集失败率＞30%

原因：DHT22采集期间，SysTick中断被BH1750的I²C中断抢占，导致状态机计时偏移。I²C中断优先级（NVIC）默认高于SysTick，造成时序错乱。
解决：在NVIC_Init()中显式设置：

NVIC_InitStructure.NVIC_IRQChannel = SysTick_IRQn; NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0; // 最高抢占优先级 NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0; NVIC_Init(&NVIC_InitStructure);

5.4 现象：BH1750在连续模式下，首次读数正确，后续全为0x0000

原因：未在每次读取前发送0x07软复位命令，BH1750内部状态机因上次通信异常（如NACK）卡死。
解决：将软复位逻辑固化进BH1750_ReadLight()函数开头，无论模式均执行。

5.5 现象：设备运行2小时后，DHT22开始间歇性失联，重启后恢复

原因：DHT22传感器引脚氧化（尤其潮湿环境），接触电阻增大，导致主机拉低总线时电压未达阈值（<0.8V），DHT22拒绝响应。
解决：用无水酒精棉签清洁DHT22引脚，或更换为镀金引脚模块；在代码中增加重试机制（最多3次，每次间隔1s）。

6. 进阶技巧：用串口指令动态切换传感器模式与校准参数

在真实项目中，不可能每次改参数都重新烧录固件。我们设计了一套轻量级串口AT指令集，让设备支持运行时配置，无需J-Link。核心思想是：用环形缓冲区接收指令，状态机解析，参数存入备份SRAM（Backup SRAM），即使掉电也不丢失。

6.1 指令集设计原则

• 所有指令以AT+开头，以\r\n结尾（兼容串口调试助手）；
• 关键参数（如DHT22温漂补偿值）存入备份SRAM（STM32F103有4KB Backup SRAM，需先使能）；
• 指令执行后返回OK或ERROR，便于上位机判断。

6.2 关键代码实现

// 使能Backup SRAM（需先解除写保护） void BackupSRAM_Enable(void) { PWR->CR |= PWR_CR_DBP; // 使能访问备份域 RCC->APB1ENR |= RCC_APB1ENR_PWREN; // 使能PWR时钟 RCC->APB1ENR |= RCC_APB1ENR_BKPEN; // 使能BKP时钟 BKP->CR |= BKP_CR_TPE; // 使能备份SRAM } // 定义备份SRAM中的参数结构体 #pragma location = "BKPSRAM" __no_init typedef struct { float temp_offset; // DHT22温度补偿值 uint8_t bh1750_mode; // 0=连续模式, 1=单次模式 } SensorConfig_TypeDef; SensorConfig_TypeDef *config = (SensorConfig_TypeDef*)0x40000000; // 备份SRAM起始地址 // 串口接收中断中解析AT指令 void USART1_IRQHandler(void) { uint8_t ch; if (USART_GetITStatus(USART1, USART_IT_RXNE) != RESET) { ch = USART_ReceiveData(USART1); if (ch == '\r' || ch == '\n') { // 结束接收，解析指令 ParseATCommand(rx_buffer); memset(rx_buffer, 0, sizeof(rx_buffer)); rx_index = 0; } else { rx_buffer[rx_index++] = ch; } } } void ParseATCommand(uint8_t *cmd) { if (strncmp((char*)cmd, "AT+TEMP_OFFSET=", 15) == 0) { // 解析浮点数，如 AT+TEMP_OFFSET=0.3 char *p = (char*)cmd + 15; config->temp_offset = atof(p); USART_SendString(USART1, "OK\r\n"); } else if (strncmp((char*)cmd, "AT+BH1750_MODE=", 16) == 0) { config->bh1750_mode = cmd[16] - '0'; USART_SendString(USART1, "OK\r\n"); } else if (strncmp((char*)cmd, "AT+READ_ALL", 11) == 0) { // 一次性读取所有传感器 float t, h; uint16_t l; DHT22_Read(&t, &h); l = BH1750_ReadLight(); char buf[64]; sprintf(buf, "TEMP:%.1f,HUMI:%.1f,LIGHT:%d\r\n", t + config->temp_offset, h, l); USART_SendString(USART1, buf); } else { USART_SendString(USART1, "ERROR\r\n"); } }

重要细节：

• atof()函数需链接libc.a，Keil中勾选Use MicroLIB；
• 备份SRAM地址0x40000000在STM32F103C8T6上有效，但若使用更大Flash型号（如CB/CT），需确认备份SRAM映射区域；
• 为防指令误触发，可在ParseATCommand开头加校验：if (strncmp((char*)cmd, "AT+", 3) != 0) return;

6.3 实际调试场景还原

某次野外测试中，设备在-5℃环境下DHT22温漂达-1.2℃，现场无法烧录。工程师用手机USB转串口线连接设备，发送：

AT+TEMP_OFFSET=-1.2 OK AT+READ_ALL TEMP:-4.8,HUMI:72.3,LIGHT:1250

10秒内完成校准，避免返厂。从此我养成了一个习惯：任何传感器驱动，只要涉及物理量，必预留至少1个浮点型校准参数入口，并强制存入非易失存储——哪怕只是备份SRAM。因为真实世界没有理想环境，而客户不会等你回实验室调完再发货。

希望帮到你。

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