1. 为什么选这个题从毕设题目里拆出真实需求每年毕业季电子信息、物联网工程、计算机相关专业的学生都会涌向一批经典题目智能火灾预警就是其中之一。乍一听名字可能你会觉得这题目已经被人做到烂大街了但真把它做扎实、做成一套能讲清楚从传感器到云平台完整链路的系统每年能达标的人其实不算多。这个题目标题里虽然写的是基于STM32与物联网但实际要交付的东西往往不只是板子和代码而是整个闭环传感器数据采集、本地声光报警、联网上云、手机端/平台端远程监控、以及最终的论文和答辩演示。换句话说你要向评审老师证明的不只是我写了一个能跑的程序而是我设计了一个从物理世界的火情信号到远程告警通知的完整系统。这个题非常适合三类人电子信息、自动化、物联网专业的毕设选择想覆盖硬件和软件两个方向嵌入式入门不久、想做一个综合项目的同学通过这个项目把ADC采集、定时器、中断、状态机、串口通信、MQTT协议一次性串起来想积累完整项目经验用于找嵌入式/物联网方向实习或工作的人。我见过不少学生代码能跑、硬件能亮、平台偶尔能收到数据但被老师一问就露馅报警阈值是怎么定的传感器输出是什么原理MQTT和HTTP的区别是什么断线重连怎么处理这篇文章就是围绕这些问题把整套系统的设计思路、选型依据、硬件细节、软件逻辑、上云链路、实测排障、论文编排全部过一遍让你拿到之后能真真正正做出来、答上问。2. 方案选型先别急着买器件把架构想明白2.1 三套主流方案横向对比做一个火灾预警系统技术路线其实有好几条。我在指导项目时最怕看到的情况是器件还没买全就已经开始纠结代码里某个函数怎么写。方案没定后面全是返工。第一套方案是STM32 GSM短信模块。传感器接STM32检测到火情后通过SIM800C等GSM模块发短信通知用户。这套方案几年前很流行但实际用下来缺点明显短信有延迟资费虽然不贵但每次都要消耗套餐而且现在的基站对2G网络不断退网模块稳定性逐年下降。做毕设的话光是把SIM卡调试通就要耗掉不少时间不推荐。第二套方案是ESP8266/ESP32单芯片方案。直接用ESP8266或ESP32连接传感器自己跑MQTT协议上云代码量小、成本低、开发速度快。这套方案从技术角度完全可行但有一个致命问题如果你的毕业设计题目明确写了基于STM32那评审老师第一句话就会问STM32在哪里。ESP8266的GPIO少、ADC精度一般、裸机开发容易翻车而且硬件部分太单薄论文没什么可写的。除非题目完全自由否则不建议这么干。第三套方案就是题目里这个组合STM32F103C8T6做主控负责传感器采集、滤波、状态判定、本地执行机构控制ESP8266做无线通信模块负责WiFi连接和MQTT消息收发。MCU和通信模块各司其职软件分层清楚答辩时可以从为什么这么分工讲出一大段设计逻辑。三套方案对比如下对比项STM32 GSM短信ESP8266/ESP32单芯片STM32 ESP8266分体式硬件工作量中等偏少适中软件工作量中等少较多能讲的故事也多实时性较差短信延迟好好成本高SIM卡流量最低低毕设适合度不推荐看题目要求推荐答辩可聊深度低低高我最后推荐的也是这篇博客后面全程围绕的就是第三套方案。2.2 我选的硬件清单与成本估算硬件清单其实非常清爽。STM32F103C8T6核心板一片十几块钱蓝色板那种ESP8266模块推荐用ESP-01S或ESP-12F大概十来块MQ-2烟雾传感器模块火焰传感器模块带LM393比较器输出数字量或模拟量DHT11温湿度传感器0.96寸I2C OLED屏有源蜂鸣器5V小风扇两个按键几个LEDAMS1117-3.3稳压芯片面包板、洞洞板或嘉立创打样PCB再加上一些电阻电容和杜邦线。整个系统的物料成本大概在100元上下非常可控。如果学校报销或者自己想做精致一点也可以把传感器和MCU画成一块PCB但毕设阶段用核心板加传感器模块完全够用重点是先把逻辑跑通后面有时间再画板子。我特别要提醒一件事传感器的模块版和裸芯片版差别很大。MQ-2模块板上已经集成了比较器电路和电位器调节直接输出ADC电压和TTL电平对新手极其友好而裸的MQ-2传感器需要自己搭负载电阻和比较电路调试难度直接上一个台阶。毕设阶段买模块版能省掉大量时间。2.3 系统级的功能拆解在动手写代码前建议先把系统的功能需求拆成一张表这样论文里第三章需求分析也有素材本地实时监测采集烟雾浓度、环境温度、湿度、火焰信号并在OLED上显示声光报警当检测到火情时蜂鸣器响起、LED闪烁、风扇启动排烟按键交互支持消音和复位两种操作消音只关蜂鸣器复位让系统回到正常监测状态远程监控通过WiFi将传感器数据上报云平台平台端可以看到实时数据远程控制通过云平台下发控制指令实现远程消音、远程复位历史记录云平台保存历史数据可回溯火情时间点。把功能先列清楚硬件设计和软件设计才不会跑偏。3. 硬件电路设计从最小系统到每个传感器的接线细节3.1 电源是整个系统的命脉STM32最小系统、传感器模块、ESP8266的电源设计是整个系统第一优先级的事情。很多同学做出来的系统偶尔抽风十有八九都是电源问题。系统外部供电我建议用5V直流USB供电或者5V充电头都行作为总输入。STM32F103C8T6核心板上面一般已经集成了AMS1117-3.3稳压芯片所以5V进来之后直接给核心板的5V引脚供电核心板输出3.3V给MCU和外设。ESP8266这里要特别注意它的峰值工作电流在WiFi发射瞬间可以达到250mA甚至更高如果直接从核心板的3.3V引脚取电电压会被拉低导致ESP8266反复重启。稳妥的做法是用一个独立的AMS1117-3.3给ESP8266供电且在ESP8266的VCC和GND之间并联一个100uF电解电容和0.1uF陶瓷电容保证瞬态供电充足。供电链路可以这样设计5V输入 → 核心板5V引脚 → 板载3.3V → STM32及部分传感器5V输入 → 独立AMS1117 → 3.3V → ESP82665V输入 → 蜂鸣器、风扇驱动电路电源所有GND必须共地这一点在接线时最容易漏。如果STM32的地和ESP8266的地不连在一起串口通信会出现各种随机乱码和错误数据。3.2 传感器模块的接线细节MQ-2烟雾传感器模块供电接5VGND接GNDAO模拟量输出接到STM32的PA0引脚。这里不要用DO数字量输出因为DO的阈值由模块上的电位器决定不够灵活用AO做ADC采集才能在软件里调整报警阈值、画出更精确的浓度变化曲线。火焰传感器模块VCC接3.3V或5V均可GND接地DO输出脚接STM32的PA1引脚。火焰传感器通过检测红外光谱来识别火源检测到火焰时DO输出低电平注意是低电平有效所以要配置为GPIO输入上拉模式。模块上也带一个电位器可以调节检测灵敏度。DHT11温湿度传感器VCC接3.3VDATA接STM32的PA2GND接地。DATA和VCC之间要接一个4.7kΩ的上拉电阻这是单总线协议的要求。DHT11的采样周期最少要间隔1秒程序里必须控制读取频率否则会读到乱码。OLED显示屏0.96寸I2C接口的OLEDVCC接3.3VSCL接PB6SDA接PB7正好对应STM32的I2C1外设。处理I2C时序的时候可以直接用HAL库的I2C驱动函数简单可靠。模块之间接线尽量短尤其是DHT11的数据线和ADC采样线长了容易受干扰。我实测下来杜邦线超过20cm后ADC采集值会出现明显的毛刺。3.3 执行机构驱动电路的设计要点蜂鸣器和风扇不能直接接在STM32的GPIO口上。STM32的GPIO最大输出电流只有约20mA而蜂鸣器和风扇的工作电流都远超这个范围强行直连轻则驱动不了重则烧坏引脚。蜂鸣器驱动使用NPN三极管S8050做开关。具体接法蜂鸣器正极接5V负极接三极管集电极三极管发射极接GND基极串联一个1kΩ电阻连接到STM32的PA3引脚。这样GPIO输出高电平时三极管导通蜂鸣器响输出低电平时截止蜂鸣器停。如果用的是蜂鸣器模块自带驱动电路那直接接GPIO就行但用裸蜂鸣器的话三极管驱动是必须的。风扇驱动推荐用N沟道MOS管AO3400或继电器。用AO3400的接法风扇正极接5V负极接MOS管漏极MOS管源极接GND栅极串联一个100Ω电阻接STM32的PA4引脚栅极再加一个10kΩ下拉电阻防止上电瞬间误触发。这个电路比三极管方案压降更小风扇能跑满转速。报警灯的闪烁可以单独用PB0、PB1接红色/绿色LED每个LED串联330Ω限流电阻再接GND。提示所有驱动电路在画PCB或焊接洞洞板时都要注意继电器或感性负载的反向电动势问题。小型蜂鸣器和直流风扇影响不大但如果用继电器控制更大的负载必须并联一个续流二极管否则容易损坏MOS管。4. 嵌入式软件核心逻辑采集、滤波与防误报判定4.1 CubeMX配置时最容易踩的小坑嵌入式软件我推荐用STM32CubeMX生成初始化代码配合HAL库开发Keil编译。这个组合的好处是外设初始化代码自动生成批量生产不容易出错而且网上资料最多。CubeMX配置项里必须做的几件事SYS里的Debug选择Serial Wire如果不选第一次烧录后第二次就无法用ST-Link连接了RCC里启用外部高速晶振HSEADC1配置IN0和IN1两个通道采样时间设置为55.5个周期以上。ADC采样时间太短会导致数据跳动很大USART1设置为异步模式波特率115200用于和ESP8266通信USART2设置为异步模式波特率115200用于调试打印I2C1用于OLEDTIM2做1ms定时器中断作为整个系统的软件时基GPIOPA1输入上拉火焰DOPA2输出开漏DHT11数据PA3推挽输出蜂鸣器控制PA4推挽输出风扇控制PA5、PA6作为按键输入上拉PB0、PB1推挽输出控制LED。时钟树配置成SYSCLK 72MHz这是STM32F103的标准主频。如果这里配错后面所有外设的波特率和定时时间都会跑偏。4.2 ADC多通道采集与滑动平均滤波火灾报警系统最忌讳误报。传感器本身输出的模拟电压波动很大特别是MQ-2烟雾传感器它内部有一个加热丝输出信号叠加了大量噪声。如果不做滤波处理阈值设得再合理也会被一个瞬时尖峰触发。我的做法是定时采集 滑动平均滤波。用一个100ms的定时器周期在主循环中用非阻塞方式判断周期性读取三路ADC通道值维护一个长度为10的滑动窗口每次新采集值进入窗口时移除最旧的值计算窗口内平均值作为有效值。这样既能平滑毛刺响应时间也不会太长。下面是一段参考实现#define FILTER_N 10 uint16_t smoke_buf[FILTER_N]; uint8_t smoke_index 0; uint32_t smoke_sum 0; uint16_t smoke_value_smoothed 0; void smoke_filter_init(void) { for (uint8_t i 0; i FILTER_N; i) { smoke_buf[i] 0; } } uint16_t smoke_filter_add(uint16_t adc_val) { smoke_sum - smoke_buf[smoke_index]; smoke_buf[smoke_index] adc_val; smoke_sum adc_val; smoke_index (smoke_index 1) % FILTER_N; return smoke_sum / FILTER_N; }注意一个细节初始化时缓冲区要全部填0或者第一次采集的值否则前面的平均值会明显偏低上电初期容易误报。DHT11的读取比较特殊它用的是单总线协议操作核心就是时序控制。拉低数据线至少18ms启动通信然后释放并等待从设备响应之后逐位读取40位数据。为了保证时序稳定建议把DHT11读取函数里的延时用DWT或SysTick实现并且读取期间避免被中断抢占。当然最稳妥的做法还是用定时器输入捕获来做但毕设阶段用阻塞延时通常也能跑通。读取完成一次后必须等待至少1秒再进行下一次读取。4.3 状态机设计正常、预警、报警之间如何迁移整个系统的报警逻辑不要写成一堆散落的if嵌套那样既难查错写论文也没法讲。推荐用状态机的方式管理。我定义四个状态NORMAL正常监测OLED显示实时数据蜂鸣器不响PRE_ALARM预警状态当某一项指标超过预警阈值但未达报警阈值时进入OLED显示预警字段蜂鸣器可以短鸣提醒ALARM报警状态蜂鸣器响、LED闪烁、风扇启动同时向云平台上报报警事件RESET_WAIT复位等待状态用户按下复位按键后系统先恢复到NORMAL并记录本次报警事件。状态迁移的原则是持续确认后才切换。例如烟雾浓度连续3次也就是300ms超过了报警阈值才进入ALARM状态如果只是某一次采集瞬时值超标则只记入统计不切换状态。这个机制对抗传感器尖峰干扰非常有效也是答辩时老师最愿意听的设计点之一。蜂鸣器控制也要非阻塞。我用TIM2产生1ms的tick计数通过软件计数实现响0.5秒、停0.5秒的周期控制这样整个系统不会因为等待蜂鸣器而卡死。每次按下消音键只清除蜂鸣器Enable标志但系统仍然停在ALARM状态直到环境参数恢复且按下复位键才回到NORMAL。主循环按照固定时基调度每20ms扫描按键每100ms采集一次传感器并更新滤波结果每500ms刷新OLED显示每1秒通过串口向ESP8266发送一次实时数据实时调用状态机处理函数。这种架构下所有任务都不互相阻塞即使WiFi网络卡住本地报警功能依然能正常运行这是消防系统非常关键的设计要求。5. 通信上云MQTT协议与平台接入的完整链路5.1 为什么选择MQTT而不是HTTP远程监控的实现方式有两种主流选择HTTP轮询和MQTT长连接。HTTP的问题在于它是请求-应答模式。设备端要定时向服务器发送GET或POST请求服务端无法主动把火灾报警推送到设备或应用端实时性差。如果要构建一个平台下发控制指令远程复位的功能HTTP就需要反向轮询或借助WebSocket在嵌入式裸机上做起来非常繁琐。MQTT是专门为物联网设计的轻量级消息协议基于发布/订阅模型。设备通过TCP长连接与Broker保持通信可以随时向某个主题发布消息也可以订阅某个主题接收消息。当服务器或手机端要向设备下发指令时只要往设备订阅的主题发一条消息即可。还支持心跳保活和遗嘱消息一旦设备掉线云平台能立刻感知。对比到具体场景火灾预警对实时性要求高报警消息要尽快上送远程控制需要下行通道网络可能不稳定需要自动重连。这三条正好都是MQTT的优势。所以这个项目里通信链路就是STM32 ESP8266 MQTT 阿里云物联网平台。5.2 阿里云物联网平台的设备配置步骤平台选择我用的是阿里云物联网平台。免费版够用而且文档完善、生态成熟手机上还有对应的IoT Studio可以搭可视化页面。创建过程大致分五步注册并登录阿里云进入物联网平台控制台创建产品。节点类型选设备联网方式选WiFi数据格式用Alink JSON。产品创建后记录下ProductKey在产品的设备列表中添加一个设备。设备名称DeviceName自己定义比如fire_alert_001。添加后平台会生成DeviceSecret在产品的Topic定义里增加自定义Topic。例如定义/product_key/device_name/user/up用于设备上报数据定义/product_key/device_name/user/down用于平台下发控制指令在IoT Studio或API调用中配置可视化看板把实时数据展示出来。设备连接MQTT时密码不是一个任意字符串而是需要用算法计算出的签名值。具体签名规则是把DeviceName、productKey、DeviceSecret、时间戳等参数做HmacSHA1加密。这个过程手动算很容易出错但在软件里可以用一个工具函数实现。需要注意的是不同平台和固件对MQTT连接参数的要求不完全相同一定要以平台文档为准。5.3 ESP8266从AT指令到数据上送的流程STM32和ESP8266之间通过USART1串口通信。ESP8266刷带MQTT功能的AT固件支持ATMQTTCONN等指令。整体流程是这样的第一步初始化ESP8266的AT指令集连接WiFiATCWMODE1 ATCWJAP你的WiFi名称,WiFi密码第二步连接MQTT服务器。阿里云平台的MQTT接入地址形如ProductKey.iot-as-mqtt.cn-shanghai.aliyuncs.com端口1883。具体指令为ATMQTTCONN0,ProductKey.iot-as-mqtt.cn-shanghai.aliyuncs.com,1883,1,clientIdString,UserName,passWord这里的clientId、UserName、passWord对应前面的MQTT连接参数。第三步发布消息到指定Topic。例如上报数据ATMQTTPUB0,/productKey/deviceName/user/up,消息长度,JSON数据,0,0JSON数据示例{temperature:26.5,humidity:60,smoke:320,flame:0,alarm:0,ts:1690000000}第四步订阅下行控制TopicATMQTTSUB0,/productKey/deviceName/user/down,0之后一旦平台下发消息ESP8266会通过串口把类似下面的内容发给STM32MQTTSUB: /productKey/deviceName/user/down,resetSTM32的串口中断接收函数里只需做一次字符串匹配如果收到reset就执行复位逻辑。为了保证协议可靠建议在STM32的发送数据末尾加上\n作为帧结束符ESP8266或平台端都按行解析数据。5.4 断线重连与心跳保活写实锤项目不写断线重连就是耍流氓。WiFi环境不稳定ESP8266可能会掉线MQTT连接也可能会断开。我在实测中遇到过的主要掉线场景有两个一是长时间无数据上报后被运营商中间链路掐断二是路由器信号弱导致断开。对应策略设置MQTT心跳时间keepalive一般选择30到60秒设备定时发送PINGREQ保活报文在STM32主循环里每隔一定时间发送ATMQTTSTATE查询连接状态。如果返回未连接则按重连WiFi→重连MQTT→重新订阅下行Topic的顺序恢复掉线期间的传感器数据可以暂存在一个小的环形缓冲区里网络恢复后补报最近几帧数据。这个细节很加分。我实测下来这一套重连机制在网络正常的情况下几乎感受不到掉线网络闪断后恢复的窗口大概在10到20秒左右。毕设演示的时候我甚至会故意拔掉路由器电源再插上展示系统自动恢复全程无须人工干预这个演示效果相当不错。6. 联调实测与排障实录最容易翻车的五个环节6.1 传感器预热漂移第一天测试数据全是错的MQ-2烟雾传感器内部有一个加热电阻上电后需要预热才能稳定工作。我第一天拿到模块上电即开始采集ADC值结果值一路从600慢慢爬到2000多差点以为传感器坏了。实际上这是预热阶段的正常现象。实测结论MQ-2洁净空气中的输出稳定电压大约需要上电3到5分钟才达到正常值。所以软件初始化时我加了一个启动预热等待流程——开机后OLED显示预热中请稍候系统延时30到60秒后再进入正常采集。虽然不能完全等5分钟但能避开最剧烈的漂移段。另外MQ-2的ADC基准值不是固定的它和供电电压、模块上的电位器调节位置、环境温湿度都有关。我在代码里做了一个一键标定功能上电预热结束后长按按键3秒记录当前ADC值作为基准值之后再拿实时采集值减去基准值作为相对浓度。这样即使换了一个传感器模块也不用改代码里的硬阈值。6.2 ESP8266供电不足导致反复重启这是整个联调阶段我最崩溃的一个问题。硬件接线全部完成串口打印一切正常但只要ESP8266开始连接WiFi系统就会整体掉电重启。用万用表一测ESP8266 VCC引脚上的电压在连接瞬间跌到了2.5V以下。原因其实前面已经提到ESP8266在WiFi发射瞬间电流峰值很大而STM32核心板上的3.3V稳压器最大输出电流有限瞬间压降过大导致模块复位。解决方法是给ESP8266单独一路AMS1117供电并在模块电源引脚旁边加一个100uF电解电容和0.1uF陶瓷电容。加了电容之后实测稳压器的最小电压稳定在3.25V以上再也没有出现连接瞬间重启的问题。这里我还要提醒一点如果用的是USB线供电劣质USB线的线阻也会造成压降尽量选线径粗一点的线材或者直接用充电头供电别都依赖电脑USB口。6.3 火焰传感器在阳光下的误报问题火焰传感器的原理是检测红外光谱。问题就在这——太阳光里也包含红外成分把模块放在窗边大晴天的时候DO输出会周期性跳变成低电平造成没火也报火的尴尬情况。我排查这个问题的过程先看串口打印的原始信号发现误报集中在光线强烈的时段然后用手机手电筒做对照实验发现白光也能触发传感器最后确认是红外干扰导致。解决方案是三重过滤给火焰传感器加一个短的遮光管只让它接收某一个方向的光线在代码里连续确认机制连续读到3次检测到火焰才判定为有效火焰信号综合判断不是看到火焰就立刻进入ALARM而是要求烟雾或温度也达到一定阈值才升级为高级报警。这个处理逻辑看起来会多几条if判断但它在答辩时意义重大你可以明明白白讲出我是如何区分真实火焰和阳光干扰的这是评审老师非常关心的工程问题。6.4 串口数据包乱码与粘包STM32与ESP8266之间、STM32与调试电脑之间的数据通信我一开始用的是最简单的HAL_Delay延时后用串口发一帧数据。结果数据量稍微一多就会偶尔出现一行乱码或者两帧数据粘连在一起。排查后发现原因有两个一是串口波特率不匹配ESP8266模块默认的AT固件波特率可能是115200但也有些商家出厂设置为9600必须先确认二是接收端只调用串口接收函数读一个字节并没有做帧同步如果发送中断处理不及时就会出现粘包。解决办法是设计一个简单的帧协议每帧数据开头是帧头0xAA中间是数据字段末尾是换行符\n。STM32的USART1中断接收函数把字节存入一个环形缓冲区主循环里解析缓冲区找到帧头后按换行符切分出一条完整指令。这样即使在一帧数据被拆成了两段接收也能正确重组。下面是一段参考实现#define RX_BUF_SIZE 128 uint8_t rx_buffer[RX_BUF_SIZE]; volatile uint8_t rx_len 0; volatile 状态标志_t rx_flag FLAG_IDLE; void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART1) { // 从串口读一个字节存入环形缓冲 // 若当前字节是‘\n’则置位帧完成标志 } HAL_UART_Receive_IT(huart1, rx_temp, 1); }帧协议虽然简单但对系统稳定性提升非常大。实测中至少在WiFi偶发延迟的情况下STM32不会再因为串口粘包而误解析出错误指令。6.5 平台能看到在线但看不到数据有一次联调时设备明明在线属性上报的Topic权限也配置了但平台的数据显示页就是空白。我花了一个晚上排查最后发现是上报的消息格式和平台定义的物模型不一致。阿里云IoT平台默认使用Alink JSON协议要求上报的属性名和物模型定义完全一致。如果产品里定义的物理量名称是SmokeConcentration代码里发的是smoke平台会直接丢弃这个消息。解决方法是回到平台上核对每个属性的标识符逐一和代码里的JSON字段名对齐。另外自定义Topic的权限也必须设置成发布和订阅都允许设备才能正常工作。每次修改Topic权限后设备需要重新上线才能生效这个也容易踩坑。我把整个联调过程中的高频问题和定位思路整理成了下面这张表方便你排障时对照现象可能原因定位方法解决手段ADC数据跳动大采样时间过短/电源纹波大串口打印原始ADC值增大ADC采样时间加强滤波检查电源蜂鸣器不响三极管驱动问题万用表测基极电压检查GPIO配置为推挽输出、驱动电路接线ESP8266反复重启3.3V供电不足示波器/万用表测VCC独立AMS1117大电容平台收不到数据Topic权限/数据格式不符在平台上使用设备调试功能核对物模型ID检查Topic权限串口乱码波特率不匹配/共地问题测两端地线是否为0V统一波特率确保共地下发的指令没有反应订阅Topic错误/引脚中断未解析串口看是否收到MQTTSUB检查下行Topic和解析逻辑7. 源码结构与论文编排让项目从能跑到能答辩7.1 代码工程怎么组织才不会被老师挑刺做毕设的时候代码往往成了导师判断工作量最直观的依据。如果整个工程只有一个main.c所有函数堆在一起即使功能全对印象分也会大打折扣。我建议把工程按模块拆分Core/Src和Core/Inc存放CubeMX生成的stm32f1xx_hal_msp.c等文件这个不用动Driver写BSP层bsp_adc.c负责ADC读取bsp_dht11.c负责DHT11时序bsp_oled.c负责显示bsp_esp8266.c负责AT指令和网络状态管理App业务逻辑层app_state_machine.c是核心状态机app_alarm.c处理报警策略app_comm.c处理串口帧协议和消息收发ThirdPartycJSON等第三方库用于组装和解析JSON数据。模块化的好处不只是好看更重要的是方便单测。我从大三时就有个习惯每写完一个模块先用串口打印的方式单独验证它再往上叠加。ADC模块验证完成之后再写DHT11DHT11独立跑通后再接OLED所有本地功能正常了才开始调WiFi。这个顺序是我反复验证过的推荐开发路径点亮OLED显示固定字符ADC采集烟雾值串口打印原始值和滤波值DHT11读取温湿度串口打印数据火焰传感器IO读取按下按键测试IO是否正常状态机逻辑跑通用按键模拟报警触发蜂鸣器和风扇驱动验证ESP8266 AT指令联调连接WiFiMQTT接入阿里云上报数据下行控制指令联调平台发指令本地复位。每一步都在物理层面验证过之后再进入下一步。这样到最后集成时即便出现问题也能迅速定位到是哪一层。按照这个路线正常进度的开发周期大约三周每天两三个小时。7.2 论文各章节写作重点与图表清单论文的章节结构要和实际的开发过程对应评审老师看论文时最关注的是逻辑完整性和交叉验证能力。一个比较稳的结构是这样的第一章绪论写研究背景、国内外智能火灾报警系统的发展现状以及本课题要解决什么问题。国外可以提多传感器融合的早期研究国内可以提近年智慧消防的推进但不需要堆砌太多。重点是要写清楚现有产品要么贵、要么单机不联网本课题用低成本方案实现联网预警。第二章相关技术介绍分别介绍STM32F103C8T6核心特性、MQ-2烟雾传感器原理、DHT11、火焰传感器、MQTT协议以及所选云平台。注意不要写成数据手册搬运每段要结合为什么在这个系统里用它来讲。第三章系统总体设计给出系统框图手画或用draw.io画清楚模块连线列出功能需求和非功能需求再展开硬件和软件的功能划分。第四章硬件设计放原理图和模块接线图。这里如果条件允许尽量用嘉立创EDA把原理图画出来哪怕只是几个模块的连线图也比直接截图开发板实物图显得专业得多。第五章软件设计这是最吃篇幅的部分。展示主流程图、状态机状态转移图、串口帧格式定义、MQTT通信消息格式表。每一段代码的关键函数可以贴核心片段不要全贴源码重点是讲清楚设计思路。第六章系统测试列测试环境、测试工具和测试数据表。比如烟雾报警响应时间模拟烟雾触发记录从触发到蜂鸣器响起的时间温度阈值验证用电吹风或热风枪靠近传感器记录触发阈值误报率统计在无火情环境下连续运行24小时记录误报警次数网络掉线恢复时间断网重启后观察重新连上平台的时间。这些表格数据不需要造假但一定要真实记录。答辩时评审老师最喜欢拿着测试表格中的数据来追问设计细节。7.3 演示与答辩时需要提前准备的东西演示环节是整个答辩的重头戏。很多同学在答辩现场翻车往往不是因为项目没做出来而是流程没排练。在正式答辩前我建议把演示流程固定下来第一步展示硬件系统指出STM32主控、各传感器模块和电源部分第二步OLED显示实时数据说明当前环境温湿度、烟雾ADC值第三步用打火机气体或香烟烟雾靠近MQ-2传感器。注意火焰传感器不要用打火机火焰正对以免不安全我用的是酒精棉球或者蚊香产生的烟雾更可控。观察系统进入报警状态蜂鸣器响、LED闪、风扇启动第四步打开手机端或电脑端云平台页面展示实时数据跳动和报警记录第五步在平台上下发复位指令远程让系统回到正常状态。另外要准备几张打印好的数据表格和系统截图放在讲台边上方便评审老师翻阅。答辩提问最常见的几个问题我在文章前面基本都覆盖了MQ-2和MQ-7的区别、阈值标定原理、为什么用MQTT、误报如何去除、为什么ESP8266会断电重启。如果你能把这些问题的因果关系讲透这个项目拿高分的概率就会非常大。我在实际开发中还有一个体会在做这类系统时不要只关注功能能不能跑通更要把为什么它应该这样设计想清楚。很多技术选型不是绝对的但你必须能回答为什么你选了它而不是另一个。这个思维习惯也是毕业设计之外更宝贵的东西。