1. 这个毕设项目为什么值得做：从选题逻辑到学习收益
毕业设计选“STM32 WiFi远程温控风扇系统”，说实话在嵌入式方向的课题里属于性价比很高的一类。它不是那种需要昂贵设备才能验证的课题，也不像纯理论学习那样做完就忘，整套系统覆盖了传感器采集、主控逻辑、无线通信、云端转发、终端控制这五个物联网项目的核心环节，做完之后你能拿出手的技能点非常完整。
我见过很多同学选课题时踩两个极端：一是选题太宽，比如“智能家居系统”，一听就是要做十个八个设备联动，最后论文写得像产品说明书，答辩时被问细节就卡壳；二是选题太窄，比如“基于XX芯片的LED闪烁控制”，工作量肉眼可见地撑不起一篇合格的毕业设计。温控风扇这个题目卡得刚刚好——硬件上有一块主控、一个温度传感器、一个WiFi模块、一个风扇驱动电路，软件上有嵌入式逻辑、通信协议、上位机或小程序，既有难度梯度又有完整的系统闭环。
这个题目的价值还在于“远程”这两个字。本地温控风扇太常见了，买一个几十块钱的温控插座就能实现，但加上WiFi远程之后，整个系统的复杂度立刻提升了一个层级。你需要在设备端解决WiFi连接稳定性，在通信层解决数据上报和指令下发的可靠性，在应用层解决可视化界面的交互逻辑。这三个问题恰好是物联网行业里每天都在面对的真实问题，无论你以后找工作方向是嵌入式、物联网还是前端可视化，这份毕设经历都能直接写进简历。
另外，作为开源项目发布，这个题目还有一个额外的优势：复现门槛低。STM32最小系统板加ESP8266模块的成本控制在五六十块钱以内，温度传感器用最经典的DS18B20，风扇用电脑机箱拆机风扇配上MOS管驱动，整套硬件成本不超过一张百元钞票。我见过不少学生做的课题，单是硬件平台就要花上千块买开发套件，最后答辩完只能吃灰，而温控风扇这个项目做完之后还能继续改造，加个屏幕、加个语音控制、换个大功率风扇，扩展空间非常大。
对于打算把代码开源的同学，我也多说一句：毕设开源的收益远超你想象。代码放在Gitee或GitHub上，不仅答辩时可以直接展示项目主页，面试官点进去看一眼你的工程结构、提交记录和README，对你工程能力的判断比看十页简历都准。更重要的是，开源项目会逼着你把代码写规范、把注释写清楚、把文档写完整，这个过程本身就是一次很好的工程习惯训练。
2. 硬件选型与电路设计的底层逻辑
2.1 主控芯片：为什么STM32F103C8T6是毕设的最优解
STM32家族型号非常多，F0、F1、F4、H7各有各的定位，但毕设项目里我强烈建议用STM32F103C8T6，也就是大家常说的“蓝板”或“C8T6最小系统板”。这颗芯片的Flash有64KB，RAM有20KB，主频72MHz，对于温控风扇这个项目来说性能绰绰有余。你跑的是一套裸机逻辑或者轻量级RTOS，外设只用到了GPIO、定时器、ADC、UART，连FSMC和DMA都用不上，F103的量级刚刚好。
选C8T6有几个具体的现实理由。第一是资料多，遇到问题随便一搜就是解决方案，这对毕设节奏非常重要，你没时间在某个冷门寄存器上卡三天。第二是价格便宜，正常渠道十几块钱一片，就算焊坏了也不心疼。第三是你以后做其他项目也用得上，学习成本不会被浪费。相比之下F407性能强很多但价格和上手难度都上去了，F0系列倒是便宜但外设库和例程丰富度不如F1，H7就不用考虑了，毕设用H7就像去菜市场买菜开了一辆越野车。
2.2 温度采集：DS18B20的单总线协议细节
温度传感器这个环节，主流选择有DS18B20、NTC热敏电阻、LM75、SHT30这么几种。NTC需要自己做ADC采集和查表标定，精度和一致性一般；LM75走I2C总线，精度不错但接线要多两根线；SHT30是数字温湿度传感器，精度高但价格稍贵。对于温控风扇这个场景，DS18B20是最合适的——单总线通信只需要一根数据线连到单片机GPIO，测量范围-55℃到125℃，12位分辨率下精度0.5℃，日常生活和机房场景完全够用。
DS18B20虽然接线简单，但通信时序是出了名的严格。单总线协议要求初始化、读时隙、写时隙都有精确的微秒级时序要求，初学者经常在这里翻车。比如初始化时主机拉低总线480微秒以上，然后释放总线等待60微秒，如果从机存在会拉低总线60到240微秒——这个“存在脉冲”是判断传感器是否在线的重要标志。我用标准库写DS18B20驱动时，最常遇到的现象是温度读数恒定显示85℃，这个值其实是DS18B20上电后的默认温度寄存器值，读到85℃说明通信根本没有成功，大概率是时序延迟没写对或者上拉电阻缺失。
还有一个容易忽略的细节：DS18B20数据线必须要接4.7kΩ左右的上拉电阻，不然总线在释放状态时电平不确定，通信会频繁出错。有的最小系统板上已经带了上拉，有的没带，接之前先看原理图确认一下。数据线尽量短一些，超过20厘米就要考虑干扰问题了。
2.3 WiFi通信：ESP8266的三种工作模式选择
WiFi模块的选择比较常见的是ESP8266和ESP32。ESP32是双核MCU，自带WiFi和蓝牙，性能强，但在这个项目里用ESP32会模糊“STM32为主控”的课题定位；ESP8266作为纯粹的WiFi透传模块，正好配合STM32的串口使用，职责分工非常清晰，论文里也更好描述系统架构。
ESP8266模块有三种常见的固件模式：AT指令模式、NodeMCU Lua模式、以及直接用Arduino IDE写代码的模式。毕设项目中我建议用AT指令模式，原因很务实：STM32的代码只需要通过串口向ESP8266发送AT指令就能完成联网和TCP通信，不需要你在ESP8266端做二次开发，整个系统的软件架构清晰很多——STM32负责业务逻辑，ESP8266只当“网卡”用。
AT指令模式下的核心通信链路是这样一个流程：ESP8266连接路由器，然后通过AT+CIPSTART建立TCP连接，之后往串口里发AT+CIPSEND指令，紧接着把要发送的数据发给模块，模块自动转发到服务器端。这块儿有一个非常坑的细节：模块收到AT+CIPSEND并回复“>”之后，你需要计算好发送字节数，因为AT+CIPSEND=50这样的指令要求你告诉模块“我接下来要发50个字节”，如果实际发的字节数和声明的不一致，数据就发送失败。所以每次发送前都要用strlen函数精确计算数据长度，不能想当然地写死数字。
2.4 风扇驱动：MOS管方案与三极管方案的取舍
风扇驱动是很多新手犯迷糊的地方。风扇如果是那种USB小风扇，工作电流只有几百毫安，用一颗NPN三极管（比如S8050）就能驱动；但如果用的是电脑机箱风扇，启动电流可以达到1安培以上，三极管的驱动能力就开始吃紧，这时候最好换成MOS管方案。
MOS管选型这块，我推荐用AO3400这颗N沟道MOS管。它的最大持续电流5.7A，内阻只有几十毫欧，只需要3.3V或5V的栅极电压就能完全导通，正好匹配STM32的GPIO输出电平。电路接法是：STM32的GPIO通过一个100Ω左右的电阻连到MOS管的栅极，MOS管的源极接地，漏极接风扇的负极，风扇的正极接电源正极。GPIO输出高电平时MOS管导通，风扇转动；输出低电平时风扇停止。
这里有一个值得注意的细节：STM32的GPIO输出电流能力有限，直接驱动MOS管虽然可行，但如果追求稳定性，可以在中间加一级三极管做推挽驱动。此外，风扇这样的感性负载在关断瞬间会产生反向电动势，必须在风扇两端并联一个续流二极管（比如1N5819肖特基二极管），否则反向电压可能击穿MOS管。我测试时就烧过一颗AO3400，当时就是忘了加续流二极管，一开一关就报废了。
电路设计阶段还有两个常被忽略的点：一是整个系统的电源要从USB或充电器取5V，主控板上自带稳压到3.3V，而风扇需要5V驱动，所以风扇电源和主控电源要用同一个5V源，不要让风扇电流流过主控板上的细走线；二是所有共地问题——ESP8266需要和STM32共地，服务器端和局域网通信本身也要保证电源地一致，不然串口电平会乱跳，通信间歇性失效。
3. 从裸机到系统：软件架构与通信协议设计
3.1 主循环架构：轮询式与状态机的实际组合
写完硬件和驱动，接下来面临的问题就是软件架构。很多教科书上的例子喜欢用一个大while(1)循环塞满所有逻辑，但真正上项目的时候你会发现，这种写法调试起来非常痛苦，尤其是在需要同时处理温度采集、按键扫描、串口收发、WiFi状态机的情况下。
我的建议是采用一个轻量的时间片轮询架构：主循环里放一个定时器标志，每10ms扫描一次按键，每100ms读一次温度，每500ms上报一次温度数据，每10ms处理一次串口接收缓冲。这样每个任务都有明确的执行周期，不会出现某个任务卡住导致其他任务饿死的情况。定时器可以用SysTick，也可以用TIM2做10ms中断置标志位，主循环里只查标志，不等待。
WiFi模块的状态管理适合用状态机：初始化状态、连接路由状态、获取IP状态、建立TCP状态、在线工作状态、掉线重连状态。每个状态下做的事情不同，状态之间靠事件驱动切换。比如ESP8266在AT+CWJAP指令发出后，需要等待WIFI CONNECTED和WIFI GOT IP两条响应，如果10秒内没有收到就跳转到重新连接状态。这套状态机逻辑跑起来之后，系统的稳定性会有一个明显的提升，WiFi断了能自己恢复，而不是死等在哪里。
3.2 通信协议：JSON格式与长度字段的防粘包设计
设备和服务器之间的通信协议设计，是很多人想简单了的地方。最开始写的时候很容易直接往TCP连接里丢一串裸文本，服务器收到即显示，但一跑起来就会遇到两个问题：一是数据粘连，两个温度数据包被TCP一次性收过来，服务器无法区分边界；二是数据解析不可靠，中间一个字符错位后面全废。
我在这个项目里采用的方案是：应用层协议用JSON格式，传输层数据包增加一个4字节的包头来标记数据长度。具体设计是每一帧数据用起始符（比如0xAA）、数据长度字段（2字节）、JSON数据体、校验字节（累加和）四部分组成。接收端先找起始符，再读长度字段，等凑够长度之后开始解析JSON。这套方案虽然“浪费”了几个字节，但换来的是极大的调试便利性——你可以在服务器上直接打印JSON日志，用通用JSON库就能解析，不需要自己发明二进制协议再写一套解析代码。
设备端上报的数据我用的是这样一个JSON结构：设备ID、温度值、风扇转速百分比、工作模式、在线状态。服务器下发指令的JSON结构则是：设备ID、指令类型（开关机、调速、模式切换）、参数值。指令类型我用整数区分，比如1表示开机、2表示关机、3表示自动温控模式、4表示手动调速，这样解析时用switch语句处理非常直观。
3.3 物联网平台选型：云平台连接与小程序的接入方式
远程控制这件事，根据你论文的工作量期望值和技术栈倾向，有三条不同的路可以走。
第一条路是使用现成的物联网云平台。国内几家主流物联网平台都提供了MQTT接入通道和移动端App配套，你不需要自己写服务器代码，只需要在设备端用AT指令连接MQTT服务器，然后在平台的控制台里配置数据流和设备影子即可。这条路的优点是开发效率极高，配置两个晚上就能跑通远程控制链路；缺点是你在论文里能写的东西比较少，因为核心逻辑都是平台帮你做好了，自己只相当于一个数据中转站。
第二条路是自己搭建一个轻量级MQTT服务器。在云服务器上安装EMQX或者Mosquitto，然后用ESP8266以MQTT协议连上来，订阅主题接收指令、发布主题上报数据，小程序或者网页端也用MQTT客户端接入同一个服务器。这条路的工作量适中，而且在论文里可以大书特书“采用MQTT协议实现设备与云端双向通信”，这个技术点面试官听了也会点头。
第三条路是纯TCP裸协议加自建TCP服务器。ESP8266通过AT指令建立TCP长连接，服务器用Python或Node.js写一个Socket服务，收数据存数据库，控制指令通过WebSocket转发给浏览器页面。这条路显示你对底层协议的理解更扎实，但工作量会大一些，要处理并发连接、心跳保活、断线重连等问题。
我建议大多数人选第二条路，MQTT是目前物联网行业的事实标准协议，学完这个项目之后你直接掌握了行业通用技能。如果时间特别紧，可以退一步选第一条路，毕竟毕设的重点是系统完整度和论文逻辑，不是炫技。
3.4 控制端的选择：微信小程序、H5与桌面App的对比
控制端的选择决定了整个项目“远程控制”交互的上限。我分别聊一下三者的利弊，你按自己的技术储备来选。
微信小程序是覆盖面最广的选择，因为微信几乎是每人必装的App，导师和答辩老师用微信扫一下你的小程序码就能体验，不用额外装一个App，这个体验差异在答辩现场特别讨喜。但小程序有一个门槛：需要注册小程序账号，而且个人主体的小程序在某些类目上限制比较多，如果你只是想做一个“设备控制面板”，个人主体是可以过审的。开发工具用微信开发者工具，前端语言是类似Vue的语法，学习成本不算高。
H5网页是开发门槛最低的方案，直接在浏览器里打开网页就能看数据和下发指令，用Vue或React写一个单页应用，部署在云服务器的Nginx上即可。缺点是手机浏览器上体验不如原生小程序流畅，而且如果服务器没有备案域名，接入时会有一些波折。
桌面端App用Electron或者Python的Tkinter也可以，但考虑到这是一个物联网项目，控制端还是移动场景为主，桌面端会显得有些“格格不入”。除非你坚决不碰前端，否则我不太推荐走桌面端。
实际操作中，我最推荐的组合是“网页控制端为主，附加一个可选的简单App壳”。先用网页把核心功能跑通，答辩展示时用平板或手机浏览器打开页面就行，如果时间富余再套壳做成App图标。
4. 温控逻辑的核心：PID算法和PWM调速的工程实现
4.1 传感器温度与风扇转速的映射关系设计
温控风扇的核心不是“温度高了就开风扇”，而是“温度多少就该开多少转速”，这个映射关系直接决定了系统是否好用。最简单的是阈值控制：温度超过30℃开风扇，低于25℃关风扇，中间加一个滞回区间防止临界点反复跳动。这种模式实现简单，论文里也好解释，但用户体验一般，噪音控制也不行——它给不了你“线性平滑”的感觉。
更好的做法是使用分段线性映射。定义一个目标温度区间，比如25℃为起始转速点，35℃为满转速点，在这个区段内转速百分比=(当前温度-25)/(35-25)×100%，低于25℃风扇全停，高于35℃风扇全速。这个映射逻辑用代码写就是几行数学计算，在论文里还可以画一条温度-转速曲线图，非常直观。
分段线性控制已经能覆盖大部分场景了，但如果你希望系统有一定的“智慧感”，就需要引入PID算法。
4.2 PID温控的工程落地：采样周期、参数整定与输出限幅
PID在这套系统里做的事情是：根据目标温度和当前温度的误差，动态调整PWM占空比，让温度尽快收敛到目标值，同时避免过冲和振荡。比如目标是30℃，当前35℃，温差大时P项输出大，风扇提速；当温度接近30℃时，P项输出减小，I项负责消除稳态误差，D项负责抑制超调趋势。
PID在裸机上的实现其实很简单：三行公式。比例项kpe(k)，积分项ki∑e(i)，微分项kd*(e(k)-e(k-1))，输出=三者和。但工程上有几个隐藏陷阱需要注意。
第一个陷阱是积分饱和。如果温度一直降不到目标值，积分项会一直累积，等到温度终于降下来时，积分项已经“冲”过头了，会导致温度过冲。解决方法是限制积分项的累积范围，比如限制在0到100之间，超出部分直接截断，这个细节在论文里写出来是加分项。
第二个陷阱是输出限幅。PID计算出来的输出可能大于100%或小于0%，但你最终要PWM输出0到100%的占空比，所以必须做限幅处理。这里有一个技巧：直接限幅会导致风扇在低转速区间出现卡顿，因为PWM占空比如果小到一定程度，风扇可能转不起来，这时候需要设置一个最小占空比阈值，比如低于15%就直接给0停止，避免风扇在半转不转的状态下发出嗡嗡声。
第三个陷阱是采样周期。PID的计算频率要和温度采样的频率匹配，我建议每1秒做一次PID计算，因为DS18B20的转换时间本身就要750毫秒左右（12位分辨率下），PID算得再快也没用。
4.3 手动模式与自动模式的切换策略
完整的温控风扇系统不应该只有自动模式，因为用户可能想手动让风扇全速运转（比如刚开完火，想让屋里快速通风），也可能想手动关掉风扇省电。所以系统设计上要有手动调速和自动温控两个模式的切换逻辑。
切模式这个操作用按键来做是最直观的。STM32上接两个按键，一个切换自动/手动，另一个在手动模式下调节转速档位。配合WiFi远程控制，服务器下发的指令也要能切模式和调速。这里要处理优先级问题：如果用户在手机端切到手动模式，设备端的按键操作还能不能影响系统？我的设计是本地按键和远程指令都有权限切换模式，但同一时刻以最后一次操作为准。这种“最终操作生效”的策略虽然简单，但符合用户直觉。
需要考虑的另一个细节是掉电记忆。如果用户把风扇调到了手动75%转速，突然断电重启后风扇应该回到默认自动模式，还是回到75%？我的建议是默认回到自动模式、转速根据当前温度自动计算，因为自动模式是安全模式，手动模式极端的转速设置可能在无人值守时造成问题。
5. 联调阶段的真实踩坑记录：从现象到根因的完整排查流程
5.1 第一次上电：温度能显示但风扇不转
硬件焊接完、代码烧录完、屏幕和串口都正常出数据了，但风扇就是不动。这个问题非常典型，几乎每个做这个项目的同学都会遇到一次。
我的排查思路是这样的：先确认主控这边有没有输出PWM波形——用手头的逻辑分析仪或者示波器看PA1引脚的输出，结果波形正常，说明代码没问题。那就怀疑到驱动电路。量MOS管栅极电压，发现栅极也有高电平，但漏极电压一直是12V，也就是说MOS管没有导通。量源极和地之间居然有2V的压差。问题出在接地：我的MOS管源极接在了面包板另一侧的电源地，风扇负极也接在那个电源地，但STM32的GND接在了面包板这一侧的电源地，两个地之间没有连通，MOS管栅极对源极的电压其实不够，所以不导通。把两块地的导线接上之后，风扇立刻转到飞起。
这个错误本质上就是共地问题，但它藏得很深，因为你用万用表去量单点电压都对，量不对的点就看到的全是假象。后面我总结了一个习惯：任何电路先检查所有模块的GND是否全部连在一起，这比检查电源电压还优先。
5.2 串口输出乱码：波特率不匹配还是电平不兼容
串口打印信息一上电就满屏乱码，这是第二个高频问题。我以前遇到的乱码原因有一个很隐秘的坑：我的代码里用的是HAL库的HAL_UART_Transmit函数，在循环里频繁往外发日志，但是初始化串口时用的是115200波特率，电脑端串口助手选的却是9600。第一反应肯定是看波特率是否一致，把两边都调到115200之后，乱码消失了。
这个问题的另一层原因是，ESP8266的AT指令固件默认波特率很多是115200，但有些模块出厂设置可能被改成了9600或4800，如果直接按默认设置发AT指令，模块大概率没有任何反应。所以调试WiFi模块的第一步应该是先确认它的固件波特率。可以用一个简单的扫描脚本，挨个波特率发送测试指令，看哪个波特率下模块有响应。
5.3 WiFi频繁掉线：路由器兼容性与TCP长连接保活
系统在家里测试时WiFi很稳定，但拿到实验室或宿舍就频繁掉线，这个现象背后的原因比较复杂。ESP8266的2.4G信号在很多环境里干扰很严重，尤其是宿舍里几十个路由器同时工作，信道拥挤，ESP8266的抗干扰能力又一般，掉线在所难免。
TCP长连接保活是另一个容易踩的坑。路由器NAT表默认的TCP会话超时时间一般在120秒到300秒之间，如果设备每隔几分钟才上报一次数据，中间没有任何网络通信，路由器就会把这条TCP连接从NAT表中清掉，后续数据包发到路由器就被丢弃了。解决办法是心跳机制：让ESP8266每隔30秒或60秒发送一个心跳包，这个包可以是一段极短的JSON数据，也可以是TCP层面的keepalive。我在系统里加了一个30秒定时器，到时间就上报一次最新温度数据，这样一举两得——既保活了连接，又让服务器界面的温度数据实时刷新。
5.4 服务器收不到数据：“透传模式”和“普通模式”的AT指令差异
这个坑主要出在对ESP8266通信模式的理解上。ESP8266的AT指令串口默认是普通模式，你在串口里发了AT+CIPSEND之后进入发送状态，数据发完自动退出；但如果你开启了AT+CIPMODE=1（透传模式），串口收到的所有数据都会自动转发到TCP连接里，不再需要每次发送都输入CIPSEND。
听起来透传模式很方便，但它的副作用是：服务器下发的数据也会直接在串口打印出来，与普通模式下用“+IPD”前缀标识接收数据完全不同。我起初在代码里混用了两种模式，STM32这边以为数据有+IPD前缀，结果服务器下发指令时串口直接打印原始JSON，解析失败，手机端控制一直无效。最后统一使用普通模式，每次发送都手动走CIPSEND流程，虽然代码多一点，但逻辑容易控制。如果你打算用透传模式，在STM32端就一定要处理好“如何区分正常回显和服务器下发数据”这个问题。
6. 可视化控制端的设计要点与交互打磨
6.1 状态面板该展示哪些数据
控制端页面设计的第一原则是：一屏看到关键信息，不让用户点三层菜单才能找到风扇开关。我的页面布局是顶部放一个当前温度和风扇转速的大型卡片，中间放一个手动/自动模式的切换开关，底部放一个滑杆用来手动调速。这样用户打开页面之后，第一眼就知道设备现在是什么状态。
状态卡片上除了温度和转速，最好再加一个“数据更新时间”字段。很多物联网项目在设备掉线之后，控制端还是显示旧数据，用户以为设备还在正常工作，容易造成误判。加上更新时间后，用户一眼就能发现数据已经很久没刷新了，自然知道设备可能掉线。这个细节看似不起眼，但在答辩讲解系统稳定性时是一个很好的加分点。
6.2 MQTT订阅机制：设备上下线与指令确认
如果用MQTT做通信，控制端和设备的交互模型需要稍微设计一下。设备上电后订阅一个指令主题，比如“device/001/command”，同时每秒向“device/001/status”主题发布一次状态数据。控制端订阅“device/001/status”主题拿实时数据，向“device/001/command”主题发布控制指令。
这里要重点设计的是指令确认机制。MQTT是异步消息协议，你发了一条“打开风扇”的指令，服务器并不知道设备是收到了还是没收到。一个简单的解决方案是让设备收到指令后，立即发布一条“指令确认”消息，内容带上指令序号，控制端在收到确认后才把按钮状态置为“已生效”，否则只显示“指令已发出，等待设备响应”。这个机制虽然简单，但能让用户体验变得可靠很多，哪怕WiFi有问题，用户也知道是“指令没送达”而不是“按钮没反应”。
6.3 掉线重连的交互反馈
控制端还有一个交互细节容易疏忽：设备掉线时，页面不能用上一次的温度数据继续“假装在线”。我在开发里踩过一次这种情况，设备都断电了，手机上的温度还停在31℃，连风扇转速都显示正常。排查后发现是后端逻辑里把最后一次上报的数据一直缓存着，控制端定时拉取的时候没判断在线状态。
后续的处理方式是，后端存储里维护一个last_seen字段，每次收到心跳都刷新它；控制端轮询时如果发现last_seen距离当前时间超过60秒，就返回“设备离线”状态，Web前端把整个控制面板置灰，显示“设备离线”大提示，禁用所有操控按钮。这样虽然页面看起来没那么“活跃”，但信息的真实性是可控的，这在工程上比“看着在动但其实早就断了”重要得多。
7. 实测数据与调参经验：让温控效果真正能看能讲
7.1 不同温度场景下的风扇转速响应实验
论文里只写代码实现是不够的，必须有实测数据支撑。我做了一组实验：把DS18B20贴在发热源旁边，分别设定目标温度25℃、30℃、35℃，记录系统从启动到温度稳定的全过程数据，每5秒记一次温度值和转速值，最后画出收敛曲线。
实验结果是分段线性控制大约在30到40秒内能把温度稳定在目标值正负2℃以内，PID控制在15到25秒内能把温度稳定在目标值正负0.5℃以内。这个对比非常直观地展示了PID算法的优势，也解释了为什么在论文里PID是核心创新点——虽然分段线性控制也能用，但PID的收敛速度和稳态精度明显更好。
我还记录了一个很有意思的极限场景：当发热源功率突然加大，温度从目标值附近快速飙升时，PID能提前凉风全开，而分段线性控制要等温度跨过阈值之后才开始加转，存在明显的滞后。这个现象放在论文的实验章节里，比任何文字描述都有说服力。
7.2 PID参数的整定过程记录
PID参数整定这块，我说一下我的实际调参过程。初始参数我直接用了kp=100、ki=5、kd=10，上电实测发现风扇转速振荡非常厉害，温度还没到目标值风扇已经在全速和停止之间来回抽动。明显是P和D的配合有问题。
我的整定策略是先将KI和KD都置为0，只保留KP，从小往大加。KP=30时系统响应很慢但稳定，KP=80时出现轻微超调，KP=120时出现振荡。最终确定KP=60，然后慢慢加KI。KI的作用是消除稳态误差，加上KI=15之后，温度能稳定在30.2℃不再有偏差，但积分累积导致了一个约2℃的超调。把KI降到5，超调消失了。
最后调KD的值，KD=20时转速变化太灵敏，风扇声音听起来像在“抖动”；KD=8时表现很平滑，温度曲线也没有振荡。最终的参数组合是KP=60、KI=5、KD=8，实测效果相当不错。这套参数整定的逻辑——先P再I最后D——是经典的齐格勒-尼科尔斯方法的简化版，写进论文里也比直接给一组参数专业得多。
值得注意的是，PID参数在不同环境中可能需要微调，比如风扇功率不同、房间大小不同、温度传感器放置位置不同，都会影响系统响应。我在论文里也明确写了这一点：参数默认值适用于常规场景，不同使用环境可在调试接口上在线调整参数，不需要重新烧录固件。这也引出了下一个话题——远程参数调节功能。
7.3 远程调参与阈值设定的必要性
温控风扇系统如果只是把温度数据和开关指令传到手机端，那它和普通的智能插座没有本质区别。真正体现物联网优势的是“远程调参”能力。我在控制端加了一个“控制参数设置”区域，用户可以远程调整自动模式下的起始温度、满转温度和PID三个核心参数的在线值。用户在家里发现风扇太吵了，不用重新烧固件，直接打开手机把起始温度从25℃调到27℃，风扇就不转了。
这个功能的技术实现其实不复杂：控制端下发一条JSON指令，里面带上参数字段，设备端解析后更新运行参数，同时把参数保存在STM32内置Flash里，掉电不丢失。STM32的内置Flash写入需要注意擦除扇区和对齐操作，不能直接像RAM那样随机写。我用的方案是在Flash里开辟一个专门的页，每次要保存新的参数时先擦除整页再写入，虽然有点浪费Flash寿命，但毕设场景下使用强度很低，完全够用。
这个远程调参功能在答辩时演示效果极好。你可以现场把起始温度调低，风扇立刻开始转动，几分钟后温度稳定在一个新的目标值，整个流程行云流水，评委能看到系统是一个真正完整可用的产品，而不是一个烧录了固定逻辑的实验板。
8. 开源的工程化准备：代码规范、文档与演示素材
8.1 代码目录结构与命名规范的建议
项目要开源，工程组织就不能是“main.c一个文件写一千行”的状态。我建议在Git仓库里按照功能模块分目录组织代码，比如：Core目录放主循环和系统初始化，Hardware目录放各外设驱动，App目录放业务逻辑，Middlewares目录放第三方组件，Docs目录放文档和接线图。每个目录下再按源文件归属命名。
命名规范上，外设驱动文件用模块名前缀，比如DS18B20驱动就命名ds18b20.c/ds18b20.h，函数命名统一用前缀加动作，比如DS18B20_Init、DS18B20_ReadTemp。这样做的好处是，别人看你代码时看到函数名就知道该调什么、不该动什么。我见过很多学生的代码，变量名叫temp1、temp2、temp3，函数名叫getdata、senddata，这样的代码自己三天不看就忘了哪个是哪个，开源出去效果自然不会好。
还有一个细节是给每个文件加上文件头注释，注明作者、日期、版本号和功能描述。虽然这些信息在代码里看起来“占地方”，但对审阅代码的老师和面试官来说，这些注释表明你是一个有工程规范意识的人，这在学生项目里属于稀缺品质。
8.2 README怎么写才能让人快速复现
README文档是开源项目的第一印象。很多人的README只有一句“这是一个STM32温控风扇系统”，然后贴一个百度云链接，这样开源是没人愿意看的。合格的README至少包含这些内容：项目简介（做的是什么、有什么功能）、硬件清单（每个硬件模块的型号、数量、链接参考）、接线表格（芯片引脚与模块引脚的对应关系）、开发环境（MDK版本、固件库、编译器版本）、烧录步骤（用什么下载器、选什么芯片型号）、上位机配置（MQTT服务器地址、账号密码设置）、使用说明（怎么进入配置模式、怎么连接WiFi）。
接线表格这块我强烈建议用表格形式，比如“DS18B20数据线 — PA0”、“ESP8266 TX — PA2（STM32 USART2 RX）”、“风扇控制 — PA1（TIM2 CH1）”。这样别人拿到项目后不需要看原理图也能快速搭出系统，复现门槛一下子降下来了。如果你的硬件是PCB而不是面包板，那就在Docs目录里放好原理图和PCB文件，让想复现的人可以直接发板子加工。
8.3 演示视频与答辩PPT的材料设计
开源项目的演示视频和毕设答辩PPT是“两场仗”。演示视频的做法是屏幕录制加硬件特写双画面：左边是控制端界面，右边是实物风扇和温度传感器特写，温度变化时风扇转速改变，两面对比让观者一目了然。
答辩PPT的节奏我建议控制在“背景与意义一页、系统架构一页、硬件设计三页、软件设计四页、实验数据三页、总结一页”。重点放在系统架构图、通信协议时序图和实验数据表上。PPT每一页不是放满字，而是放一张图加三行关键说明，答辩时以自己的话讲，不要念PPT。同时把开源仓库地址放在最后一页，告诉评委“代码完全开源，欢迎指教”，这个姿态通常能留下好印象。
还有一个经常被忽视的准备：演示Demo用的WiFi网络要提前测试。答辩现场的WiFi可能是教学楼公用无线网络，勘察现场后发现很多会议室根本没有外部WiFi，或者信号差到ESP8266连不上。这时候你可以提前用手机开一个热点，用热点做演示。为保险起见，把WiFi连接失败时自动重启重连的间隔调短一些，防止现场等待时间过长尴尬。
9. 我踩过最有价值的一个坑：断电重启后找不到WiFi
这个问题我想单独拿出来说，因为它真的折腾了我整整两天。现象非常诡异：系统正常工作时一切正常，但只要断电重新上电，ESP8266大概率连不上路由器，而按一下复位键之后又能正常连接。
一开始我怀疑是ESP8266的AT指令发送时机有问题。排查代码后发现，STM32上电后立刻就开始发AT+CWJAP指令，而ESP8266模块自身也需要时间完成上电初始化。如果STM32太快发指令，模块还没就绪，指令直接丢失，自然不会去连WiFi。解决思路是在初始化WiFi之前加一个延时，等待模块准备好。标准的做法是循环发送AT测试指令，直到收到模块的“OK”响应后再继续后续流程，这比单纯加延时更可靠。
但这只解决了一半问题。真正深层的原因是路由器在设备断电后的DHCP租约问题：设备断电瞬间TCP连接没有正常关闭，路由器保留着旧的ARP缓存和租约记录，设备重新上线时如果请求的IP和旧IP一致，部分路由器会拒绝响应。解决办法是让STM32在每次上电时先发AT+RST重置模块，然后等2秒再开始联网流程，相当于让ESP8266以干净的“新设备”身份接入网络。
这个坑的价值在于，它揭示了物联网设备在真实使用环境中会遇到的一个经典问题——上电时序。后续我写所有带WiFi模块的项目时，都会在初始化流程中加上“等待模块就绪”的判断逻辑，这个习惯帮我避开了很多类似的问题。
10. 最后多说一句：毕设项目开源的正确心态
做这个项目之前，你可能觉得“开源”就是把代码传到网上，但真正做下来你会发现，开源的过程本质上是“用别人能理解的方式重新组织你的工程”。为了写出清晰的README，你会认真梳理接线关系；为了代码能被别人编译，你会顺手把依赖路径整理干净；为了让演示视频看起来专业，你会真正把系统调到稳定。这些动作反过来会让你的毕设质量上一个台阶。
这套系统的价值不在于它的技术难度有多高，而在于它是一个完整的产品级闭环，从传感器到云端再到用户手指尖的每个环节都经得起追问。做完它之后，你对外可以说“我独立完成了一个软硬件结合、具备远程控制能力的物联网温控系统”，这句话在面试和答辩里都很有分量。而把它开源出去，让后来者少走弯路、能站在你的肩膀上改进，对于一个开发者而言，也是挺有成就感的一件事。
