简介一套基于STM32的室内环境监测系统完整程序源码包面向单片机学习者、课程设计及毕业设计开发者覆盖温湿度采集、阈值报警与自动化控制等课题需求。系统以STM32F103C8T6最小系统为主控实现DHT11温湿度传感器数据读取、LED灯阈值报警、数码管显示等模块并配套Keil工程源码和Altium Designer原理图设计思路代码涉及定时器、ADC、I2C、USART等外设驱动。压缩包共156个文件以C源码、H头文件、Keil工程配置及编译输出为主另有hex烧录文件与map、axf等调试文件整体约2.71MB目录清晰便于按模块查阅与直接烧录验证。目前已有1313人学习下载适合作为课程设计、电子竞赛或毕业设计参考案例可借鉴其模块化代码组织、外设初始化流程和软硬件联调方法快速修改温湿度阈值与引脚配置搭建自己的环境监测原型。1. 室内环境捡测系统的 STM32 软硬件骨架室内环境监测系统的本质是把温湿度、空气质量、光照这类模拟量或数字量传感器信号统一采集、校准、汇总后送至上位机或云端展示。基于 STM32 的方案之所以多是因为这类系统对主控的要求集中在低功耗、中的外设资源、稳定的 I2C/SPI 通信能力上而这刚好是 STM32 的舒适区。一个典型的完整程序源码通常包含传感器驱动、数据滤波与标定、任务调度、通信协议栈如 Modbus 或自定协议、以及配合上位机的帧格式解析这几个部分。对五年以上从业者来说这个话题的信息量在于环境监测系统的源码虽然不复杂但“读完”和“能运行”之间隔着一整套外设配置和内存规划。而常见的问题——I2C 总线挂死、DHT11 读取时序异常、ADC 采集值跳动大、FreeRTOS 任务栈溢出——每一个都指向某个具体的代码位置或 CubeMX 参数。这篇内容会以一套可移植的源码架构为主线把传感器接入、数据校准、通信协议和调试手段一层层拆开让读者拿到源码后能按自己的传感器型号和通信方式改出可用的固件。硬件选型上以 STM32F103C8T6 为基准因为它的资源在环境监测场景里够用且覆盖率最高需要说明的是同样的代码结构可以直接迁移到 STM32L4 或 G4 系列只需要在 CubeMX 里重映射引脚和处理低功耗时钟即可。2. STM32 环境监测系统的硬件架构与外设选型2.1 监测系统的 Sensor 选型与接口匹配环境监测系统的传感器接口大致分三类模拟量输出如 MQ 系列气体传感器、光敏电阻、单总线数字量如 DHT11/DHT22、I2C 数字量如 SHT30、BMP280、CCS811。选型时如果只盯着精度往往会忽略一个关键问题传感器的工作电压和 STM32 的 ADC 参考电压是否一致比如 MQ-135 模块输出电压范围接近 3.3V 至 5V直接接入 STM32 的 PA0 引脚会超出 ADC 量程而多数空气质量传感器的 I2C 地址可能冲突需要额外的地址选择引脚。从整体架构的角度看室内环境监测系统的传感器接入应遵循“模块化驱动 统一数据接口”的原则。每个传感器驱动独立编译通过一个结构体向上层注册typedef struct { uint8_t sensor_id; uint8_t (*init)(void); uint8_t (*read)(sensor_data_t *data); uint16_t poll_interval_ms; } sensor_device_t;这种设计让程序源码的可读性更好新增传感器时不需要改动任务调度代码只需要在传感器注册表中增加一项。常见的做法是先在 CubeMX 中把 I2C1 和 ADC1 的引脚分配好然后生成基础工程传感器驱动则作为独立模块加入与主循环解耦。2.2 CubeMX 工程中的关键参数时钟树、I2C 频率与 ADC 采样时间STM32 环境监测工程在 CubeMX 中的配置看似简单却有几个参数直接决定系统稳定性。首先是时钟树室温湿度传感器通过 I2C 通信而 I2C 的 SCL 频率由 APB1 总线的时钟分频而来。如果 APB1 时钟设置过高而 I2C 分频系数未调整SCL 实际频率会超出传感器手册规定的 400kHz 上限导致通信偶发失败。参数上建议按以下基准配置一对一的对照表外设关键参数推荐值说明RCCHSE8MHz 晶振配合 PLL 倍频至 72MHz 系统主频I2C1Clock Speed100kHz 或 400kHz优先 100kHz兼容性优先ADC1Sampling Time55.5 Cycles 以上避免高阻抗传感器输入导致采样不准确USART1Baud Rate9600 或 115200上下位机通信的波特率需一致数据量小时 9600 更稳FreeRTOSMinimal Stack Size128 words任务栈过小会导致 HardFault要注意的是STM32 的 ADC 时钟最高不超过 14MHz。当系统主频为 72MHz 时ADC 预分频器必须至少设为 6即 ADC 时钟为 12MHz。很多环境监测源码在运行时出现采集值周期性跳变根源就在 ADC 时钟配置超过了规格。CubeMX 生成的代码会自动配置分频系数但如果手工改过 RCC 配置需回到 ADC 配置页检查时钟一栏是否变红。2.3 传感器供电与去耦设计对程序稳定性的影响程序源码本身可以精确控制采集逻辑但如果硬件供电设计不合理代码再好也测不出准确数据。实际开发中的一个典型问题SHT30 和 STM32 共用一组 LDO当继电器或风扇启动瞬间电压跌落超过 100mVSHT30 的 I2C 通信便被中断程序陷入忙等循环。而监控系统的任务栈又不大忙等时间过长会触发看门狗复位。工程上的常见解决手段是传感器单独用一个小电流 LDO如 ME6211供电并在传感器电源引脚附近放置 100nF 去耦电容。电源部分的处理记录在源码的硬件配置文件board_config.h中这是一个较好的参考习惯#define SENSOR_POWER_CONTROL_GPIO_Port GPIOB #define SENSOR_POWER_PIN GPIO_PIN_12 #define SENSOR_POWER_ON() HAL_GPIO_WritePin(SENSOR_POWER_CONTROL_GPIO_Port, \ SENSOR_POWER_PIN, GPIO_PIN_SET) #define SENSOR_POWER_OFF() HAL_GPIO_WritePin(SENSOR_POWER_CONTROL_GPIO_Port, \ SENSOR_POWER_PIN, GPIO_PIN_RESET)这样在任务调度中如果连续多次读取传感器失败可以先关闭传感器电源延时 100ms 再上电完成一次硬复位。这比在 I2C 总线上发软件复位指令更可靠因为某些廉价传感器模块的复位逻辑并未实现。这个部分常被忽略——但恰恰是源码在客户环境中能否长期稳定运行的分水岭。3. 核心驱动代码的编写与数据校准方案3.1 I2C 传感器驱动中的错误处理与总线恢复室内环境监测系统的程序源码里最影响稳定性的模块依赖关系是“主控与传感器之间的 I2C 通信是否健壮”。和串口不同I2C 总线上的异常通常是协议级的传感器内部 MCU 死机导致 SCL 被拉低、总线电平冲突、或者地址应答超时。使用 HAL 库时一个关键细节是 HAL_I2C_Mem_Read 返回值非 HAL_OK 后不能简单地重试应该先调用 HAL_I2C_DeInit 释放总线再重新初始化。以下是一套常用且可靠的重试流程代码uint8_t sht30_read_register(uint8_t reg, uint8_t *buf, uint16_t len) { uint8_t retry 3; HAL_StatusTypeDef status; while (retry--) { status HAL_I2C_Mem_Read(hi2c1, SHT30_ADDR 1, reg, I2C_MEMADD_SIZE_8BIT, buf, len, 100); if (status HAL_OK) { return 0; } /* 复位 I2C 外设并重新初始化避免总线锁死 */ HAL_I2C_DeInit(hi2c1); HAL_Delay(2); HAL_I2C_Init(hi2c1); HAL_Delay(10); } return 1; }这段代码的逻辑是先尝试读操作返回失败后对整个 I2C 外设做一次释放和重建。重试次数不宜超过 3 次因为每次 DeInit/Init 的耗时接近 10ms若传感器真的离线过多重试会拖慢主循环影响其他任务。参数中 100ms 是 HAL 库的超时时间选择这个值是因为 SHT30 在正常工作时一次内存读操作不会超过 10ms100ms 已经覆盖了总线仲裁和时钟同步的异常情况。3.2 模拟量采集ADC 多通道扫描与均值滤波环境监测系统如果不接空气质量和光照传感器ADC 部分可能只需采集一个光敏电阻的分压值。但现实场景通常是一个 ADC 引脚接多个传感器这就需要使用 ADC 的多通道扫描模式。使用 CubeMX 生成代码时注意将 ADC 设置为 Scan Mode 和 Continuous Conversion Mode。连续转换模式配合 DMA 可将数据搬运到内存减少 CPU 中断负担。下面是一段用于四通道污染物浓度采集的配置逻辑使用 DMA 循环模式#define ADC_CHANNEL_COUNT 4 uint16_t adc_raw[ADC_CHANNEL_COUNT]; void adc_continuous_init(void) { HAL_ADC_Start_DMA(hadc1, (uint32_t *)adc_raw, ADC_CHANNEL_COUNT); } void adc_process_values(void) { static uint16_t filter_buf[ADC_CHANNEL_COUNT][8] {0}; for (int ch 0; ch ADC_CHANNEL_COUNT; ch) { /* 环形缓冲区覆盖最旧数据 */ filter_buf[ch][sample_index] adc_raw[ch]; uint32_t sum 0; for (int i 0; i 8; i) sum filter_buf[ch][i]; sensor_voltage[ch] (sum 3) * 3.3f / 4095.0f; } sample_index (sample_index 1) % 8; }采用“取平均”而非“去掉最大最小值再平均”的原因在于环境监测的 ADC 输入信号变化相对缓慢尖峰噪声出现的概率低但偶发的电磁干扰会导致个别采样点异常偏高。如果在平均值计算中加入冒泡排序去极值在 4 通道时成本可控但当通道增加到 8 个时排序耗时按非线性增长已不适合放在任务循环中执行。将滤波窗口设为 8 次采样是一个兼顾响应时间和噪声抑制的折中选择。参数上需要注意的是3.3f这个参考电压值并不精确。如果系统对光照或气体浓度的绝对数值有要求应当用万用表实测 VREF 引脚上的实际电压或者使用 STM32 的内部参考电压通道VREFINT进行校准。3.3 DHT 单总线时序驱动的实现要点DHT11 和 DHT22 在环境监测项目中依旧常见原因不是精度高而是成本足够低。单总线协议的难点在于时序起始信号、响应信号、每一位的 50us 低电平后接 26us~28us表示 0或 70us表示 1的高电平。程序源码在 C 语言层面上最直接的问题是延时函数不准确。HAL_Delay 基于 SysTick 中断最小粒度是 1ms清清楚楚无法用于微秒级时序所以 DHT 驱动一般使用循环等待或 DWT 计数器。推荐的方案是使用 DWT 的 CYCCNT 寄存器它的精度是系统主频时钟周期72MHz 主频下每个周期约为 13.9ns。代码如下static void delay_us_dwt(uint32_t us) { uint32_t start DWT-CYCCNT; uint32_t ticks us * (SystemCoreClock / 1000000); while ((DWT-CYCCNT - start) ticks); } uint8_t dht11_read_data(uint8_t *humidity, uint8_t *temperature) { // 主机拉低至少 18ms 作为起始信号 GPIO_WriteBit(DHT_GPIO, DHT_PIN, 0); delay_us_dwt(20000); GPIO_WriteBit(DHT_GPIO, DHT_PIN, 1); delay_us_dwt(30); // 检查响应信号 ... }在 STM32F103 上使用这个延时函数要确保 DWT 外设已使能。标准做法是 CoreDebug-DEMCR 的位 0 置 1然后 DWT-CTRL 的位 0 置 1。c CoreDebug-DEMCR | CoreDebug_DEMCR_TRCENA_Msk; DWT-CTRL | DWT_CTRL_CYCCNTENA_Msk;需要留意的坑是当编译器开启 -O2 优化时while ((DWT-CYCCNT - start) ticks); 这段代码不会因变量未改动而被优化掉因为 CYCCNT 是 volatile 寄存器。但延时计算中的乘法运算会出现在循环外若 us 参数太大导致乘法溢出函数会立即返回读到的数据就会是错乱的。 ## 4. 多数据源融合链路FreeRTOS 任务调度与上位机通信实现 ### 4.1 任务划分与信号量机制的合理设计 环境监测系统的程序源码如果只用一个 while 大循环当前看起来也可以工作但会有几个问题不同传感器的轮询周期不同温湿度可以 2 秒一次空气质量最好 500ms 一次如果串口通信阻塞了 50ms传感器的采样周期就会被拉偏加上 LED 刷新和按键扫描耦合度一高系统行为就难以预测。在 STM32 环境监测项目中引入 FreeRTOS 是标准做法任务划分方式如下 | 任务名 | 优先级 | 周期/触发方式 | 栈大小 | 职责 | |---|---|---|---|---| | sensor_task | 正常 | 500ms | 256 words | 轮询传感器更新共享数据区 | | comm_task | 正常 | 信号量触发 | 512 words | 解析上位机命令发送响应帧 | | led_task | 低 | 200ms | 128 words | 状态指示不做业务逻辑 | | watchdog_task | 高 | 1s | 128 words | 检测数据新鲜度喂独立看门狗 | 有一个细节值得强调环境监测系统协议栈处理方式与工业设备的协议逻辑不同后者要求实时响应控制指令而环境监测大多只是定期上报数据。因此 comm_task 不适合做成周期任务而应该挂在一个二值信号量上由串口接收中断释放信号量。示例如下 c void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART1) { BaseType_t higher pdFALSE; rx_frame_ready 1; osSemaphoreRelease(comm_sem_handle); HAL_UART_Receive_IT(huart, rx_byte, 1); } }中断回调函数只做“收一个字节 发信号量”两件事帧的解析逻辑全部放回 comm_task 上下文。这样在任务中可以使用阻塞式解析如等待完整帧再处理而不会因为中断中执行复杂逻辑导致其他中断响应延迟。4.2 自定义报警门限与 Modbus RTU 协议的取舍环境监测系统的上位机通信通常有两种选择选用标准 Modbus RTU 协议或者设计自定义帧格式。不建议在初期通信中就引入大而全的协议。实际场景里用户需要从多个传感器读取数据并设置温湿度报警阈值若使用 Modbus RTU代码量更大但兼容性更好可直接接入组态软件若使用自定义协议报文更精简但要自己实现校验和重发机制。对于基于 STM32 的室内环境监测系统来说如果目标是快速交付并保证稳定推荐自定义协议因为上位机是自己开发的 C# 或 Python 程序不涉及第三方组态软件兼容。一个实用的帧格式定义是帧头(0xAA 0x55) 地址(1Byte) 功能码(1Byte) 数据长度(2Byte) 数据体(N Byte) CRC16(2Byte)功能码可以定义为0x01 表示读取全部传感器数据0x02 表示设置阈值0x03 表示校准操作。CRC16 校验常选择的算法是 MODBUS 的 CRC-16在数据体和帧头之间所有字节均参与计算确保串口传输中的偶发错误能够被发现。下面是 CRC16 的实现部分uint16_t crc16_modbus(uint8_t *data, uint16_t len) { uint16_t crc 0xFFFF; for (uint16_t i 0; i len; i) { crc ^ data[i]; for (uint8_t j 0; j 8; j) { if (crc 0x0001) { crc (crc 1) ^ 0xA001; } else { crc 1; } } } return crc; }4.3 上位机解析源码与 STM32 端的数据拟合在收到了 STM32 传上来的温湿度数据后上位机还需要处理两类问题一是帧同步二是数据业务逻辑。帧同步方面使用轮询状态机的思路在接收缓冲区中寻找帧头业务逻辑方面例如温度在 18~26 度、湿度在 40%~60% 时显示为绿色否则为红色。上位机源码的意义并不在这里——而在于它对 STM32 上报数据的重组。要注意的是上位机程序源码如 C# WinForms 或 Qt与 STM32 的源码要一并适配后才能正常工作。例如 STM32 端定义温度上报为有符号数单位 0.01 摄氏度int16 类型但上位机如果不做处理直接按无符号数显示负温度就会变成 65535 之类的大数。这类问题在联调时非常高发排查效率也低因为总线上的字节往往是正常的问题只出在两端数据的表示层面。5. 系统级调试从 Git 开源项目中快速定位程序源码问题的建议路径5.1 使用 Ozone 或 ST-LINK Utility 排查 HardFault 与任务栈溢出环境监测系统在长期运行后出现死机第一嫌疑永远不是传感器而是 RAM 使用量超出芯片容量或任务栈溢出。FreeRTOS 提供uxTaskGetStackHighWaterMark()API在任务中调用可显示历史最低剩余栈容量。建议在每轮通信完成后将水印值打印到串口void comm_task(void *argument) { for (;;) { osSemaphoreAcquire(comm_sem_handle, osWaitForever); process_uart_frame(); UART_Printf(COMM STACK: %u\r\n, uxTaskGetStackHighWaterMark(NULL)); } }水印值如果长期小于 50 words说明该任务需要增加栈。也可以在任务中故意进行深度函数调用观察 HardFault 是否出现。还有一种常见调试手段是使用 ST-LINK Utility 读取 PC 指针寄存器。 如果发现 HardFault 在 HAL_Delay 附近反复重现一般为 SysTick 优先级或中断配置问题。5.2 基于 RTT 日志的远程调试和数据回放环境监测系统开机运行在用户现场无法每次故障都连 ST-LINK。此时用 RTT 机制打印调试信息比串口打印更可靠RTT 不占用 UART 外设而通过调试器读写内存速度可以到 1MB/s 以上。SEGGER RTT 在连接到 J-Link 时工作在线调试时通过 RTT Viewer 查看变量正常运行时也可将日志导向 RAM 循环缓冲区再通过额外任务定期上报。程序源码中常加入的诊断变量包括各传感器最后读取状态、I2C 重试次数、通信帧错误计数、以及任务切换的上下文。通过周期性地将这些值发送到串口配合上位机绘制曲线可以在故障发生前观测到传感器数据劣化趋势。此方案在循环风机联动控温和电池供电场景均适用。至此这套从硬件选型、CubeMX 配置、传感器驱动、任务调度到调试手段的完整流程已经覆盖了 STM32 环境监测源码的各个关键部分。本文还有配套的精品资源点击获取