企业官网建设流程全解析

在硬件圈混久了会发现一个现象：网上一搜“STM32环境监测”，出来的教程十有八九是教你怎么点亮一块OLED屏、把温湿度数据显示上去，跑通一套Demo就宣布“大功告成”。但真正把一个智能环境监测系统从原型做到稳定运行，难点根本不在“读出数据”，而在“数据准不准、功耗高不高、交互顺不顺”这些细节里。去年我亲手做了这么一套系统，围绕它踩了不少坑，也总结出一些教程和课本里很难看到的经验。这篇内容会从需求拆解、传感器选型聊到驱动代码、数据滤波、人机交互和功耗调优，适合准备做课程设计、毕业设计或者个人DIY的嵌入式入门读者，也值得想把手头小项目做得更扎实的人参考。

1. 需求拆解与系统架构：想清楚“智能”到底落在哪里

1.1 先列需求表，再谈芯片和传感器

我在做这套系统前，先把自己的需求写在一张表里，而不是直接打开购物软件搜传感器。这张表看着不起眼，但它是后面所有选型和代码设计的地基，你只有把“智能环境监测”这个大词收敛成可执行的具体指标，方案才不会反复推翻。

为什么上来先做这张表？因为环境监测系统里一个看似很简单的功能，比如“测一下温湿度”，一旦落实到电路和代码，就会牵扯到传感器供电、采样频率、数据滤波、显示刷新、异常处理这一整条链路。如果你一开始没有明确是插电使用还是电池供电、是只要当前值还是必须看历史趋势，后面做出来的东西很可能不是你要的。

表里我特意标了优先级。实际做的时候，先把“必须”做完，再做“建议”，最后做“看场景”。比如低功耗这块，如果项目只是插电使用，完全不用考虑Stop模式，能省掉一大堆辛苦事，主循环想怎么写就怎么写；但如果要做成桌面小气象站那种长期摆着不拔电的设备，功耗就得认真抠。

我把“智能”这个词拆成了四个可以落地的点：

• 数据融合与修正：把温湿度、光照、空气质量多个维度放在一起综合判断；
• 阈值报警联动：超限后驱动蜂鸣器和指示灯，阈值可以在菜单里修改；
• 趋势判断：不是见到一次超标就报，而是连续几分钟超标才报，减少误报；
• 自动休眠唤醒：电池供电时定期唤醒采样，测完继续睡。

1.2 主控选型：为什么是STM32F103C8T6

定完需求，选型就顺理成章了。我选了STM32F103C8T6这颗芯片，理由其实很朴实：外设够用、资料够多、成本够低。整个系统需要I2C、ADC、UART、GPIO，它全都有，64KB Flash存代码也够用，我项目做到后期代码量大约35KB，还有余量。如果一开始选F103系列里Flash只有16KB的型号，后面加功能就会很痛苦。

有人会问F4系列或者G0系列行不行？行，但对这个项目来说没必要。F4的优势在浮点运算和更强的性能，环境监测这种低频采样任务，F103的72MHz主频绰绰有余；G0系列功耗更低，但资料和生态没有F103那么厚，新手遇到问题容易卡住。如果只看“先进程度”，F103不算年轻，但作为学习和稳定落地的选择，它依然是这个场景里最不容易出错的那颗。

顺手再说一句为什么不选51或者Arduino：51的8位核心和外设做多路传感器采集会吃力，尤其后期要加Wi-Fi模块、要跑状态机的时候，内存和开发效率都是问题；Arduino开发确实快，但库包了一层又一层，很多数据异常你根本不知道发生在哪一层。用STM32直接操作寄存器或者标准库，你能很清楚地看到“初始化GPIO→配置外设→读取数据”这条链路，这对理解嵌入式底层很有帮助。

系统的大致框图可以概括为：5V电源输入稳压到3.3V，传感器组通过I2C或UART把原始信号送给主控，主控处理后在OLED上显示，同时根据阈值逻辑驱动蜂鸣器，最后通过串口把数据送给上位机。这个划分是后面代码分层的依据，模块之间各管一摊，谁出问题就查谁，不会出现“一锅端”的混乱局面。

2. 传感器选型与硬件电路：数据质量的源头在电路细节

2.1 温湿度：单总线传感器看着方便，用起来最磨人

温湿度传感器我最早用的是DHT11，因为便宜、资料也多。但测试时发现单总线协议很吃时序，任何时候只要代码里有个关中断的操作，或者OLED刷个屏，读取就很容易出错，而且出错时返回的往往是上一次的缓存值，你很难判断数据是不是新鲜的。后来换成SHT30，同样两颗传感器放在同一环境，SHT30的读数稳定度明显好一大截。

选SHT30还有一个很关键的原因：它自带CRC校验，读到坏数据可以直接丢弃重读。环境监测系统最怕的不是“读不到数据”，而是“读到假数据”还当成正常值显示出来。DHT11没有校验，单凭这一点我就不会把它用在需要长期稳定运行的监测设备里。

SHT30接线很简单，SDA接PB7、SCL接PB6，再加4.7kΩ上拉电阻到3.3V就行。它的供电范围虽然宽到5V，但如果要挂在同一个I2C总线上，供电最好和主控保持一致，避免电平不匹配影响通信。

2.2 光照和空气质量：模拟量与数字量的取舍

光照传感器有两种路线。一种是光敏电阻加分压电阻，输出模拟量进ADC，优点是成本就一两块钱，缺点是非线性、一致性差，每块板子都要单独校准；另一种是BH1750这类数字传感器，内部自带16位ADC，直接通过I2C输出lux单位，测量范围0~65535lux，一致性很好，价格也就几块钱。做监测系统我用的是BH1750，因为它省掉了ADC校准的麻烦，多个设备之间的数据还能互相比较。

空气质量这块，很多人一上来就买MQ系列气体传感器。MQ系列确实便宜，但有几个实际问题：一是内部加热丝要持续通电，模块整体功耗高，不适合电池供电；二是启动稳定要等好几十分钟，刚上电读到的数据基本不能用；三是交叉敏感明显，它对很多气体都有反应，很难说清到底测到了什么。如果是演示Demo，用MQ系列没问题；如果要做“超标报警”这种有实际功能的系统，我更推荐用SGP30这类传感器测VOC和eCO2当量浓度。它输出稳定、数字接口、功耗低，但它测的也是“等效值”而不是真实CO2浓度，这一点心里要有数。

要注意的是，SGP30在一段时间不通电后，初次上电后的前12小时数据会慢慢漂移，这是它的校准基线特性。跑测试时别刚上电就下结论，最好让它连续跑两三天，再评估长期数据是否合理。

如果项目需要真正的颗粒物浓度，比如PM2.5，那就得用激光粉尘传感器了。这类传感器内部带激光管和风扇，通过UART输出，精度高但体积和功耗都大，适合做成固定设备而非随身设备。我在系统里预留了UART接口，需要时插上就能读。

2.3 电源、上拉与PCB布局：三个新手最容易忽略的坑

这里给出一张引脚连接表，方便直接抄作业：

电源这块是最容易被忽略的。系统供电从5V进来，用低压差稳压器降到3.3V。OLED屏幕刷新瞬间电流能拉到十几毫安以上，如果和传感器共用同一个稳压器输出，电源纹波就会直接影响传感器读数。我的做法是把OLED和传感器放在不同的3.3V供电分支，或者退一步，在共用节点上并一个470μF的电解电容当储能缓冲，实测读数据时的电压跌落能从300mV左右降到几十毫伏以内。

I2C上拉电阻也不能省。总线上的SDA和SCL必须接上拉，典型值4.7kΩ；如果总线上挂的设备多，上拉电阻适当减小到2.2kΩ，否则总线信号上升沿变缓，高速传输时容易误码。

PCB布局同样有讲究。传感器尽量远离电源插座、蜂鸣器这类功率器件，因为它们动作时会在PCB上产生电流浪涌；地线不要绕成圈，模拟地就近打孔接主地。这些细节短期内看不出问题，但等系统出现周期性的数据跳变时，回查布线就是头号嫌疑。

3. STM32驱动代码与数据处理：把原始信号变成可用数据

3.1 代码分层与第一个坑：硬件I2C还是软件I2C

代码结构我习惯分成bsp层和应用层。bsp层只管“怎么跟硬件打交道”，应用层只管“拿到数据后怎么办”。这样分开之后，想换传感器、想改报警逻辑，都只需要动其中一层，不会牵连全局。

project ├── bsp │ ├── i2c_soft.c │ ├── sht30.c │ ├── bh1750.c │ ├── pms7003.c │ └── oled.c ├── app │ ├── data_process.c │ ├── alarm.c │ └── menu.c └── main.c

这里第一个容易踩的坑是：STM32F103的硬件I2C模块有不少人用起来不顺手，现象是初始化正常，但读某个传感器时偶发卡在忙状态。原因是这颗芯片的I2C模块在实现上存在一些边界情况，网上讨论很多，很多人最后干脆用软件模拟I2C来解决：用两个GPIO手动翻转，配合延时产生通信时序。

我的经验是，对低速传感器而言，软件I2C完全可以胜任，而且代码直观、排查方便。SHT30和BH1750的通信速率要求都很低，100kHz就够，软件模拟时只要延时函数稳定就不容易出错。如果你决定用标准库或寄存器的硬件I2C，也没问题，但要做好“偶发卡死需要手动恢复”的心理准备。下面是SHT30的核心读取代码，我用的是标准库风格，HAL库思路一样：

#define SHT30_ADDR 0x44 #define SHT30_CMD_MEASURE 0x2C06 static uint8_t sht30_crc8(uint8_t *data, uint8_t len) { uint8_t crc = 0xFF; while (len--) { crc ^= *data++; for (uint8_t i = 0; i < 8; i++) crc = (crc & 0x80) ? (crc << 1) ^ 0x31 : (crc << 1); } return crc; } uint8_t sht30_read(float *temp, float *hum) { uint8_t cmd[2] = {0x2C, 0x06}; uint8_t buf[6]; uint16_t t_raw, h_raw; i2c_write_reg(SHT30_ADDR, cmd, 2); delay_ms(50); // 等待转换完成 i2c_read_buf(SHT30_ADDR, buf, 6); if (sht30_crc8(buf, 2) != buf[2]) return 1; // 温度CRC错误 if (sht30_crc8(buf + 3, 2) != buf[5]) return 1; // 湿度CRC错误 t_raw = (buf[0] << 8) | buf[1]; h_raw = (buf[3] << 8) | buf[4]; *temp = -45.0f + 175.0f * (float)t_raw / 65535.0f; *hum = 100.0f * (float)h_raw / 65535.0f; return 0; }

这段代码里最需要注意的就是CRC校验。传感器返回6字节，前两字节是温度原始值，后两字节是湿度原始值，中间各夹了一个CRC字节。不校验直接算，一旦总线出现一个错误的bit，显示出来的就是一个莫名其妙的温度。

如果用的是串口型粉尘传感器，思路也类似：按数据手册解析帧头、帧长、数据区和校验位即可。这类传感器一般是周期性主动上传，我会在串口接收中断里做一个简单的状态机，整帧收齐之后再交给应用层解析，而不是在主循环里阻塞式等待一个完整数据包。

3.2 数据滤波与修正：样本够稳定，显示才不会“乱跳”

传感器原始读数直接上屏，一定会有跳动。一方面来自传感器自身噪声，另一方面环境里微小的空气流动也会让温湿度在小范围内波动。对监测系统来说，2秒刷新一次的页面如果数字一直在跳，用户第一反应就是“这设备坏了”。

我用得最多的方法是滑动平均，窗口取8个样本就够：

#define FILTER_SIZE 8 static float temp_buf[FILTER_SIZE]; static uint8_t temp_idx; float temp_smooth(float sample) { temp_buf[temp_idx] = sample; temp_idx = (temp_idx + 1) % FILTER_SIZE; float sum = 0; for (uint8_t i = 0; i < FILTER_SIZE; i++) sum += temp_buf[i]; return sum / FILTER_SIZE; }

这个算法最大的好处是没有复杂的浮点运算和动态内存分配，一个环形缓冲区就搞定了。光照和空气质量数据也做同样处理，只是窗口大小可以调：变化慢的温度用8个样本，变化快的光照用4个样本，保证响应速度不会太迟钝。

实际滤波效果可以参考下面这张实测表：

除了滤波，还要考虑修正。一个常见现象是：设备装进外壳后，传感器距离主控太近，MCU发热会让传感器测到的温度比环境高2~3℃。这种情况下更靠谱的办法不是改算法，而是把传感器放到离主控远一点的位置，比如用排线引出；如果距离没法变，就在读数里做一个固定的温度偏移校准，但偏移量一定要在系统稳定运行半小时后再标定。

另外可以做露点计算，作为温湿度之外的第三项参考数据。公式不复杂：

gamma = ln(RH/100) + (17.62 * T) / (243.12 + T) Td = 243.12 * gamma / (17.62 - gamma)

T的单位是℃，RH是百分比。这个指标对判断“要不要关窗”很有用：同样25℃下，室外湿度60%时露点大约16.8℃，室内湿度只有35%时露点大约8.8℃，比单看湿度数字直观得多。

3.3 “智能”判断：阈值、迟滞和趋势

最后说一个容易被忽略的细节：报警逻辑并不是“值大于某个数就报警”这么简单。如果你写的是“温度大于35℃就报警”，系统很可能在35℃上下反复触发、反复关闭，蜂鸣器跟抽风一样。

正确做法是加迟滞：比如温度达到35℃开始报警，降到32℃才解除报警，中间这3℃就是迟滞带，用来避免抖动。代码层面可以这样组织：

typedef struct { float high_set; // 报警上限 float low_clear; // 解除下限 uint8_t active; // 当前报警状态 } threshold_t; void alarm_update(threshold_t *t, float value) { if (t->active) { if (value < t->low_clear) t->active = 0; } else { if (value > t->high_set) t->active = 1; } }

更进一步，报警不要用单次数据触发。比较稳妥的做法是连续读取几次，如果每次都超阈值，才确认一次报警并把计数清空。这样可以挡住绝大多数由于传感器偶发毛刺造成的误报。既然叫“智能环境监测系统”，这部分判断逻辑就应该放在嵌入式端，而不是简单把数据发给云平台再靠云端判断，毕竟现场设备自己具备基本判断能力，可靠性会高很多。

4. 人机交互与数据上送：数据要能看得见、传得走

4.1 OLED显示与刷新策略：别用全屏清屏

0.96寸OLED用的驱动芯片是SSD1306，它内部有1KB显存，每次全屏刷新都要把这1KB数据整个通过I2C传过去。我用软件I2C按400kbps算，传1KB也要20ms以上，如果每200ms全屏刷一次，主循环大部分时间都在发数据，留给传感器读取的时间就变得很紧张。

所以显示这一层的关键是局部刷新。具体做法是：

• 在内存里维护一份framebuffer，只在数据变化时更新对应区域；
• OLED底层提供“更新区域”的接口，而不是每次整屏重发；
• 页面用状态机管理，按键切页时才全屏刷新，平时只在数字变化的位置做局部更新。

比如只更新温度数字那一小块区域，思路大概是这样：

void display_page_main(void) { static float last_temp = -999, last_humi = -999; if (temp != last_temp) { oled_show_num(0, 2, (int)(temp * 10), 5); last_temp = temp; } if (hum != last_humi) { oled_show_num(0, 4, (int)(hum * 10), 5); last_humi = hum; } }

这样I2C总线上每次只传十几字节，刷新压力小很多，主循环也能空出时间去处理按键、读取传感器和报警逻辑。

4.2 串口协议与Wi-Fi上云：帧格式先定好，后面不加价

如果数据要交给PC或云平台，不建议只是把数值直接printf出来，否则接收端得靠字符串解析，效率低还容易出错。我的做法是在串口上定义一个简单的二进制帧：

帧头(2字节) 0xAA 0x55 长度(1字节) 类型(1字节) 数据(N字节) CRC16(2字节)

帧头用来快速定位帧起点，长度表示数据区大小，类型区分温湿度、光照、空气质量等不同数据包，CRC16保证传输内容完整。上位机收到一帧后先校验CRC，通过才算有效。

如果要做Wi-Fi上云，一般是在STM32和Wi-Fi模块之间也用同样的串口帧格式，STM32负责采集和组帧，Wi-Fi模块负责透传或者把帧内容封装成MQTT协议发出去。上报频率建议5秒一次，室内环境监测的实时性完全够，也能省流量和云资源。数据到了云端，价值就是看历史曲线：晚上客厅相对湿度从45%升到60%，光照从300lux掉到几乎为0，这些趋势单看现场屏幕是看不出来的。

数据上送看起来是加分项，但对环境监测系统来说，没有历史数据，很多东西只能靠猜。我建议哪怕一开始不上云，也把帧格式和协议先写好，后面想加只是加一块模块的事，不用推翻代码重来。

5. 实测调优与踩坑记录：那些教程不会写的东西

5.1 OLED一刷新，传感器读数就开始漂移

先说我印象最深的故障。最初整机联调时，传感器数据在空载情况下很稳定，但只要OLED开始刷新，SHT30读取失败率就从不到1%直接升到接近三成。一开始怀疑是时序冲突，排查了半天没结果，后来拿示波器测3.3V电压轨才明白，OLED刷新瞬间会产生约300mV的纹波。

根因是OLED模块和传感器共用了同一个3.3V稳压输出，OLED内部动态电流冲击不小，直接把电压轨拉得起伏。解决办法有两个：一是给OLED单独用一个稳压器，二是在共用电源节点加大电解电容储能。我最后在PCB上给传感器供电支路串了一个磁珠，再并上10μF电容，同时把总电源输入电容加到470μF，问题基本消除，读取失败率降回了正常范围。

这个坑说明一件事：传感器“接上就能读”很容易，但数据要长期稳定，供电设计比驱动代码更值得你花时间。

5.2 ADC读数跳变：不一定是传感器的问题

早期方案里光照部分用的是光敏电阻加ADC的方式，结果发现同一光照条件下读数跳动能到几百个计数值。排查思路是逐步排除：

• 软件滤波加了没？加了，但效果有限；
• ADC时钟配了多少？当时图省事用了最高时钟，采样周期只配了几个周期；
• 参考电压稳不稳？示波器一测，电源轨上确实带有噪声。

最后定位到两个主要问题：ADC采样时间太短，采样电容没有充足时间充电到被测电压；参考电压VREF跟随电源噪声一起波动。把ADC时钟分频到12MHz、采样周期配置成比较长的档位之后，原始读数跳动大幅下降，再加上滑动平均滤波，显示出来的光照数值就非常平稳了。如果项目对光照精度要求更高，可以加独立参考源芯片，但做室内监测这个级别，把采样时间拉长已经足够。

5.3 休眠唤醒后I2C总线卡死：外设状态要手动重置

想给系统做低功耗时，又一个坑冒出来：进入Stop模式后，用定时器唤醒，唤醒后第一次读传感器就卡在等待应答的while循环里。我一开始怀疑是唤醒时序问题，试了半天才发现，休眠前I2C外设还处于忙状态，唤醒后没有恢复机制把它重置回来。

解决办法是：进Stop模式前先把I2C外设时钟关闭、GPIO释放，唤醒后再重新初始化一遍；如果用的是软件模拟I2C，这个问题会更轻，因为GPIO模式重新配置一次就行。

另外实测功耗时有个细节容易被漏掉：开发板上通常自带LED、USB转串口芯片这些额外耗电设备，测量由STM32和传感器组成的系统真实功耗时，这些都要断开，不然后续所有低功耗判断都会被误导。

这个调试过程中我总结出一条通用路径：遇到“看起来像软件”的硬件问题，先测电源轨道；遇到“看起来像硬件”的软件问题，先检查外设状态有没有恢复。交叉排查，往往能少走一半弯路。

如果重新做一遍这个项目，我会把PCB供电设计和传感器布局的优先级提到驱动代码前面。传感器数据是整个系统判断的基础，基础不稳，显示、报警、上云都建立在沙子上。另一个体会是，环境监测这类系统的价值不在“能读到数据”，而在数据能够被长期稳定地采集、有效判断，并以合适的方式呈现给使用者。希望这篇基于STM32的智能环境监测系统设计分享，能让你把项目做得少一些返工、多一些从容。