STM32 WiFi远程温控风扇系统：硬件选型、固件开发与调试实战-平芜编程栈

毕设题目里出现"STM32 WiFi远程温控风扇系统"这种名字，第一反应通常是温度加风扇加WiFi，三个东西一拼，好像没什么难的。真从零开始搭一套能演示、能答辩、能连续跑几个小时的系统时，你会发现每个环节都有坑：单总线时序调不通、风扇上电就全速转、WiFi隔一会儿就掉线、手机端指令下发后设备没反应。而这些问题的排查过程，恰恰是这套毕设真正的价值所在。我前后接触过几套同类项目，自己也完整搭过一遍，这篇文章把方案选择、硬件搭建、固件实现、远程通信和调试排错的完整过程梳理清楚，适合正在选嵌入式方向毕设题目、或者想从零入门STM32物联网项目的同学直接照做参考。

1. 这个项目到底在解决什么问题

1.1 先把需求拆开，别急着买零件

很多人拿到题目第一件事就是打开购物软件把STM32开发板、DS18B20、ESP8266、风扇全部加进购物车，然后等快递的几天里才开始想方案。这个顺序是反的，比较稳妥的做法是先把需求写清楚，再反推买什么。

这套系统表面上看就三件事：测温度、转风扇、远程连WiFi。但要拿它做毕业设计，老师多半会追问几个问题：温度怎么采的？风扇转速怎么调的？如果WiFi断了风扇会怎么动作？远程控制的数据链路是怎么走的？这些问题的答案，决定了系统设计成什么样。

我把这套系统的核心需求拆成了四层：

传感层：实时采集环境温度，精度达到0.5度量级，刷新周期在1秒以内。
控制层：根据温度自动控制风扇转速，同时支持远程下发手动模式。
通信层：设备通过WiFi接入网络，把状态数据上行传到控制端，并接收下行指令。
应用层：用户在手机或电脑上查看实时状态、切换模式、调整目标温度。

这四层想清楚了，硬件选型就顺着出来了：传感层用数字温度传感器，控制层靠STM32定时器输出PWM驱动MOS管，通信层交给ESP8266透传，应用层用MQTT协议接手机端。整个链路是传感节点采集数据，STM32做决策和控制，ESP8266只负责搬运数据，各司其职，出问题的时候也容易定位。

1.2 这套毕设的难度和含金量评估

从毕设选题的角度讲，这个项目我很推荐。原因很简单：难度层级很平滑，下限低，上限也能拉得比较高。

基础版：温度到了就开风扇，温度低了就关，用回差控制，WiFi只用来上报温度。这块做好至少是"能过"水平。
进阶版：用PID对风扇进行无级调速，温度波动小，远程可以切换自动和手动模式，这就到了"良好"水平。
提高版：加入OLED实时显示、设备掉线自动保护、多设备联动、微信小程序或者Web端控制，再配一套完整的PC上位机曲线图，这就到了"优秀"水平。

这种阶梯设计对毕设很有价值。进度紧张就做基础版，时间充裕就一路做上去。而且做完这套东西，要求的技能点很全：STM32的GPIO操作、定时器PWM、串口通信、DS18B20单总线协议、MOS管驱动电路、ESP8266的AT指令、MQTT应用层协议。这些技能放到就业市场上的嵌入式岗位描述里，出现频率非常高。也不夸张地说，一套做下来，比翻开教材看半年都管用。

核心难点其实就两个：一个是怎么把风扇转速平滑地控制住，另一个是怎么让WiFi通信稳定不掉线。把这两件事解决，答辩时在演示环节已经赢了大半。

2. 核心方案选型：每个模块为什么选它

2.1 主控芯片：用什么STM32比较合适

主控选择上，STM32F103C8T6是这类项目的绝对主流。Cortex-M3核，72MHz主频，64KB Flash，20KB SRAM，对于这个项目来说完全够用。关键是这块芯片的资料量非常大，从标准外设库到HAL库的例程满天飞，遇到问题基本搜得到答案。对毕设选手来说，能找到答案这件事，比芯片本身性能重要得多。

很多人问能不能用STM32F407或者STM32F4系列，能做但没必要。F103的资源已经绰绰有余，我还见过有人用F407做温控风扇，最后大部分资源都在空转，答辩时老师问为什么选个这么高性能的芯片，反而不知道怎么答。选F103C8T6还有一层考虑是成本，最小系统板十几二十块钱，即使焊坏两块也不心疼。

正经做的时候，建议用带板载ST-Link接口的版本，或者单独配一个ST-Link V2下载器。用串口ISP下载不但慢，还经常因为BOOT0跳帽设置不对导致识别不到芯片，很浪费时间。我后面调试代码时几乎每改一次都要下载，用ST-Link能做到即改即下，体验完全不同。

2.2 温度传感器：DS18B20为什么是首选

测温方案的对比很有意思。最简单的是热敏电阻，配合STM32的ADC就能读，成本一两毛钱，但你要自己搭分压电路、查表换算温度，还要做校准，精度完全看运气。用SHT30这类I2C温湿度传感器也可以，数字输出、免校准，但它偏重温湿度二合一，价格贵几块钱，而且对于"红外遥控电风扇"这种纯控温场景有点浪费。

DS18B20是这个项目的经典之选，原因很实际：

数字输出，单总线协议，一条数据线就能读数据，占一个GPIO就行。
测温范围-55到125度，12位分辨率时分辨率达到0.0625度，精度足够。
免校准，出厂前已经校准过，读到的就是实际温度。
价格便宜，拆机件几块钱，全新也不贵。
寄生供电模式可以只在数据线上取电，少拉一根线，但我不建议用寄生供电。

用DS18B20唯一的门槛是要写单总线时序，后面会详细说。这里先给一个明确的提醒：买的时候优先选不锈钢封装或者带引线的防水探头，比裸片封装更容易固定到测量位置，演示时也能更方便地用手捏住探头模拟温度上升。

另外，我建议把DS18B20和数据线放得离主控板近一点，或者至少别和电源线捆在一起走很长的距离。线一旦拉长到半米以上，抗干扰能力变差，读数就容易出现坏值，排查的时候非常折磨人。

2.3 风扇驱动方案：直接把PWM做进MOS管

风扇驱动是硬件部分最容易翻车的地方。很多入门教程喜欢用继电器控制风扇开关，但继电器只能实现开和关，无法调速，而且继电器通断时会有机械声，每次切换都让人听着揪心。也有用小功率三极管驱动风扇的方式，但三极管在大电流下管压降大、发热明显，长时间跑稳定性堪忧。

我推荐的方案是STM32直接输出PWM信号来驱动逻辑电平MOS管。找一个N沟道MOS管，型号如AO4406或者类似规格的逻辑电平管，Vgs阈值在一伏多，3.3V的高电平就能完全开通，导通电阻只有几毫欧。接线方式：12V电源正极接风扇正极，风扇负极接MOS管的漏极，MOS管的源极接地，栅极接STM32的PWM输出引脚。当PWM占空比变化时，风扇的平均供电电压跟着变化，转速就受控了。

这个方案的优势在于：

损耗小，MOS管导通电阻极低，基本不发热。
调速平滑，从0到100%转速连续可调，配合PID控制很漂亮。
开关速度快，PWM频率可以达到20kHz，听不到啸叫。
成本低，一个MOS管加几个电阻电容就搞定。

关于风扇的选型，我用的是12V四线电脑散热风扇。四线风扇里红线接12V、黑线接地、黄线是测速输出、蓝线是PWM调速输入。但直接用STM32的PWM去驱蓝线只能调转速，无法关闭风扇，所以更通用的做法还是用MOS管断掉电源回路。如果你手头只有三线风扇，两条电源线加一条测速线，就用MOS管调速，测速线接STM32的输入捕获引脚可以读实时转速，这是后话。关键在于：风扇选12V的，不要把5V风扇接到12V上，不然冒烟。

2.4 WiFi模块：ESP8266的两种玩法

WiFi模块的选择几乎是明牌：ESP8266系列。不是因为它性能有多强，而是因为它的资料量、生态和成本已经卷到一个很夸张的级别。我在项目中用的是ESP8266模块，通过串口和STM32通信，模块本身跑AT固件，STM32只需要通过UART发送AT指令，就能让它连接WiFi、建立TCP连接、收发数据。

ESP8266的玩法有两种，选择哪种取决于你打算让代码的复杂度落在哪一层。

玩法一：AT指令模式。ESP8266跑官方AT固件，STM32用串口给模块发AT指令，模块负责连接网络和传输数据。好处是STM32端逻辑简单，不碰网络协议栈；坏处是AT指令通信有个解析过程，处理粘包、回包的时候要写状态机。
玩法二：SDK开发模式。直接用乐鑫的ESP8266 SDK开发，让ESP8266自己跑逻辑，甚至把DS18B20和PWM都挂在ESP8266上。好处是省掉STM32，单芯片搞定；但这就是"ESP8266温控风扇"而不是"STM32 WiFi温控风扇"了，和题目不符，而且SDK开发的工程构建、烧录对新手来说门槛更高。

毕设场景我强烈建议玩法一。STM32是主控，ESP8266就是一个透传管道，职责单一。调试的时候先单独测ESP8266能不能连上网络，再单独测STM32的串口输出，最后串在一起联调，分层定位问题非常方便。

3. 硬件搭建实录：从零件到能跑的电路

3.1 完整接线清单与连接关系

我用的元器件清单如下，造价整体在几十块钱以内，适合学生党：

STM32F103C8T6最小系统板
DS18B20温度传感器模块（或探头）
12V直流无刷风扇
AO4406 N沟道MOS管
ESP8266模块（选型时注意模块引脚是否引出完整）
12V/1A DC电源适配器
AMS1117-3.3稳压模块或者直接用开发板上的3.3V
若干电阻电容，4.7k电阻、10k电阻、100nF瓷片电容、470uF电解电容

接线关系整理成下表：

STM32引脚	连接目标	说明
PA6（TIM3_CH1）	MOS管栅极	PWM输出，通过10kΩ下拉电阻到地
PA9（USART1_TX）	ESP8266 RXD	串口发送，交叉连接
PA10（USART1_RX）	ESP8266 TXD	串口接收，交叉连接
PB1	DS18B20 DQ	单总线数据线，接4.7kΩ上拉到3.3V
3.3V	ESP8266 VCC	需要保证供电能力
GND	所有模块共地	非常重要，缺了通信必乱

电源路径是：12V适配器进系统。12V直接给风扇供电，同时通过稳压到5V、再到3.3V给STM32和ESP8266供电。如果买的是开发板，板上已集成稳压电路，但前面的电流容量问题依然要考虑，下面详细说。

3.2 电源设计的第一课：ESP8266是一个电流陷阱

这是我做这套系统时翻车最惨的一次。一开始偷懒，把ESP8266直接插到STM32开发板的3.3V引脚上，开发板由USB线供电。结果只要ESP8266开始连接WiFi，整块板子就重启，重启后又连，连上又重启，循环反复没法用。后来查清楚原因，ESP8266在WiFi发射瞬间电流峰值能到300到400毫安，而USB口供电加开发板上的线性稳压器根本扛不住这个瞬时抽流，电压一下就跌到欠压阈值以下，芯片复位。

解决办法是让3.3V电源轨有足够的余量。我当时用了一个单独AMS1117-3.3稳压模块从5V降压给ESP8266供电，并且在ESP8266的VCC引脚附近并联一个470uF电解电容加一个100nF瓷片电容。电解电容负责扛瞬态电流，瓷片电容滤高频纹波。这样改完，ESP8266连接WiFi时电压波动从接近1V降到几十毫伏，问题彻底消失。

注意这里的电容不是随意加的。470uF在3.3V轨上提供了很大的电荷储备，相当于一个微型UPS，ESP8266发射时先从这个电容里抽电，稳压器再慢慢补回来。如果省掉这颗电容，哪怕电源芯片标称电流够，瞬态响应跟不上照样会导致复位。后面调试遇到"一开WiFi就重启"的故障，优先检查这一条。

3.3 三个容易被忽略的电路细节

第一，MOS管栅极必须加下拉电阻。STM32上电瞬间，GPIO默认状态往往是高阻或者不确定，如果MOS管栅极悬空，噪声就可能意外导通，表现为系统一上电风扇就全速转。在栅极和地之间加一个10kΩ电阻，保证上电瞬间栅极被拉低，风扇保持关闭，等固件跑起来由PWM接管。这个是官方规格书里不太会写、但做出来必踩的细节。

第二，DS18B20数据线上要接上拉电阻。单总线协议要求总线空闲时是高电平，所以DQ线必须通过一个4.7kΩ电阻上拉到3.3V。很多买回来的模块上已经焊好上拉电阻了，但裸探头没有。少了这个电阻，温度读出来要么是恒定-127，要么是偶发跳变，排查时特别容易怀疑时序问题而不是硬件问题。

第三，风扇电机两端要并一个续流二极管。风扇是感性负载，MOS管关断瞬间会产生反向电动势，尖峰电压如果不泄放，轻则干扰单片机复位，重则击穿MOS管。在风扇两根电源线之间反接一个1N5819肖特基二极管，负极接12V正极、正极接风扇负极，给电流一个续流回路。这个步骤加上去，系统的长期稳定性会有明显提升。

3.4 面包板、洞洞板还是打样PCB

如果只是验证功能，面包板是最快的。但注意面包板的跳线接触电阻和松动问题很折磨人，尤其ESP8266这种大电流模块，面包板上的长跳线会引入压降和噪声，我遇到过因为面包板接触不良导致ESP8266反复重启的。建议验证阶段就用面包板，一旦功能跑通，尽快把电路焊到洞洞板上。

洞洞板方案成本低、速度快，适合毕设作品展示。焊的时候注意：MOS管和稳压芯片附近留出散热空间，大电流路径尽量短粗，信号线和电源线别平行走太长。

如果时间充裕，我对你的建议是打一次PCB，哪怕两层的也行。把这个电路画进原理图、布局、投板、焊接、调试的过程完整走一遍，面试时拿出板子聊设计，比拿面包板有说服力得多。PCB打样价格已经很低了，几块钱能打好几片。

4. 固件开发：让风扇学会"看温度办事"

4.1 开发环境与工程初始化

软件开发我用的STM32CubeMX配合HAL库，这套组合目前在毕设里占主流。CubeMX里配置几个关键项：

时钟：外部晶振8MHz，系统主频拉满72MHz。如果用的是没有板载晶振的最小板，就把HSE换掉用内部HSI，否则串口波特率会不准，和ESP8266通信会乱码。
USART1：异步模式，波特率115200。这个串口接ESP8266。
USART2：异步模式，波特率9600或115200。这个串口接PC调试，打印日志。
TIM3_CH1（PA6）：PWM生成模式，频率20kHz，初始占空比0。
PB1：GPIO输出或推挽输出模式，用于单总线读写。

CubeMX配置完直接生成工程，然后把DS18B20的驱动文件加进去。我用HAL库之后花在GPIO配置上的时间几乎为零，大部分精力都集中在业务逻辑上，这比十年前用寄存器开发要友好太多。

4.2 温度采集代码：单总线的时序门槛

DS18B20的驱动是整个项目里第一个真正的关卡。单总线协议的核心在于严格的时序：初始化时主机拉低总线至少480us然后释放，DS18B20响应存在脉冲；写0时拉低60us，写1时拉低1到15us后释放；读数据时主机拉低1us后释放，然后在15us内采样电平。

代码层面，先实现微秒级延时函数，再依次实现复位、写字节、读字节，最后组合出温度读取流程：

float DS18B20_GetTemp(void) { uint8_t tempL, tempH; int16_t tempRaw; DS18B20_Reset(); DS18B20_WriteByte(0xCC); // 跳过ROM匹配 DS18B20_WriteByte(0x44); // 启动温度转换 HAL_Delay(750); // 等待转换完成 DS18B20_Reset(); DS18B20_WriteByte(0xCC); DS18B20_WriteByte(0xBE); // 读暂存器 tempL = DS18B20_ReadByte(); tempH = DS18B20_ReadByte(); tempRaw = (tempH << 8) | tempL; return tempRaw * 0.0625; // 12位分辨率 }

这段代码的逻辑不复杂，但几个细节很关键：

转换等待时间：12位分辨率下转换时间最长750ms，如果读完就立马读温度，大概率读到0或者上一次的缓存值。我实测用500ms延迟偶尔会出现旧数据，改成750ms后稳定。
读到的原始值是带符号的16位数据，负温度时高字节高位为1，必须用int16_t类型承接，转float后乘以分辨率系数0.0625。
每次读温度之间一定要有足够的间隔，连续快速读会让DS18B20来不及转换。

延时函数的准确性直接影响时序。HAL_Delay只能做毫秒延迟，微秒级别的延迟我用SysTick实现或者干脆用空循环。如果是72MHz主频，一个空for循环大约能跑几个周期，我用示波器校准过延时函数，确保时序接近规格书的范围。这个校准步骤不能省，很多读不到温度的情况就是延时偏了。

4.3 PWM调速：频率、占空比与死区处理

PWM输出配置为20kHz。这个频率不是随便定的，人耳对10kHz以下的声音比较敏感，如果PWM频率太低，比如1kHz，风扇线圈会发出明显的"滋滋"啸叫，听着像电路坏了。20kHz已经超出人耳可听范围，实测没有可闻噪声。

Timer配置计算公式：

PWM频率 = 72MHz / ((Prescaler+1) * (Period+1))

如果选Prescaler=0，Period=3599，频率就是72MHz / 3600 = 20kHz。占空比由比较寄存器CCR决定，CCR从0到3599对应0%到100%。

PWM占空比和风扇转速不是线性关系，这是PID控制时要处理的一个问题。风扇存在启动死区：占空比低于20%左右时，风扇要么不转，要么转速极不稳定。处理办法有两个：

在控制算法中设置最小占空比下限，比如20%，低于这个值就直接输出20%。
需要完全停转时，不是把PWM占空比设为0，而是直接把PWM输出关闭，避免风扇在极低占空比下处于似转非转的状态。

这类"死区处理"在答辩时很加分，你可以直接指出这个现象并说明自己的处理策略，老师会觉得你确实做过实验而非纯抄教程。

4.4 自动控温逻辑：先说回差再说PID

自动模式下的控温逻辑，最简单的做法是回差控制：设定目标温度26度，回差1度，温度到27度开风扇，降到25度关风扇。这个逻辑简单可靠，但缺点是风扇只有开和关两个状态，温度会在目标值附近来回波动，演示效果不够"智能"。

更好的是做PID调速。以设定温度为目标值，当前温度为反馈值，PID输出对应PWM占空比，让风扇转速随温差连续变化。我用的简单位置式PID：

float pid_update(float target, float current) { float error = target - current; integral += error * dt; if (integral > INTEGRAL_MAX) integral = INTEGRAL_MAX; if (integral < -INTEGRAL_MAX) integral = -INTEGRAL_MAX; float derivative = (error - last_error) / dt; last_error = error; float output = Kp * error + Ki * integral + Kd * derivative; if (output > 100) output = 100; if (output < DUTY_MIN) output = DUTY_MIN; return output; }

几个参数参考：Kp取8到15，Ki取0.1到0.5，Kd在DS18B20场景下建议先设0。原因很实际，DS18B20测量值本身有量化噪声，微分项会放大这种噪声，让输出抖动。先用PI控制，等整定清楚了如果觉得响应太慢再微调微分项。

采样周期我设置为1秒。温度变化本身是慢过程，PID采样周期太长会失控，太短又没什么意义，1秒在温控场景下是一个自然的选择。dt在代码里就是1.0，不需要额外计算。

这里有个重要的体会：PID参数不要指望一次调好。我调试时的方法是先设Kp，Kp太小响应慢，Kp太大会震荡；然后加Ki消除稳态误差，Ki太大会产生超调。调参过程记录在纸上，每次改一个参数，观察温度曲线变化，大概花一下午时间能得到一组能用的参数。答辨时备好这组调参记录，老师问怎么确定参数时你可以展开讲一套实际过程。

5. 远程通信与控制端：把控制权交到手机屏幕上

5.1 ESP8266入网与AT指令透传

ESP8266在整套系统里的角色是透明的数据管道。STM32负责解析传感器数据和执行控制指令，ESP8266只管把数据从串口搬到网络上。为了让管道尽量透明，我用的是AT指令模式。

先把ESP8266配置成STA模式并连接家里的WiFi：

AT+CWMODE=1 AT+CWJAP="你的WiFi名称","你的WiFi密码" AT+MQTTUSERCFG=0,1,"stm32_fan_client","mqtt用户名","mqtt密码",0,0,"" AT+MQTTCONN=0,"broker服务器地址",1883,1

注意几个细节。ESP8266出厂固件版本要确认在1.7以上，新版固件才支持AT+MQTT指令集，版本太老只能用TCP透传自己拼MQTT报文。确认固件版本用AT+GMR指令。其次，如果所在环境的WiFi是5G频段的，ESP8266只支持2.4G频段，连不上5G热点是常见问题，调试时可以先用手机开一个2.4G热点测试。

连接成功后，STM32端要做的是通过USART1向ESP8266发送AT+MQTTPUB指令发布主题：

sprintf(buf, "AT+MQTTPUB=0,\"stm32_fan/status\",\"{\\\"temp\\\":%.1f,\\\"duty\\\":%d}\",1,0\r\n", temp, duty); HAL_UART_Transmit(&huart1, (uint8_t*)buf, strlen(buf), 1000);

JSON字符串在C语言里拼接时要转义双引号，这个细节每次都要检查一遍。发送AT指令后还需要读取ESP8266返回的OK或者ERROR，根据回包判断是否成功。我在STM32端写了一个简单的串口接收状态机，逐字符解析回包，判断最后两个字符是不是"OK"，是则继续下一帧，否则重发。

5.2 MQTT主题设计与上报逻辑

MQTT协议里主题设计直接决定了扩展性。我设计了三组主题：

主题	方向	载荷内容
stm32_fan/status	设备上行	温度、占空比、模式、开关状态
stm32_fan/cmd	云端下行	目标温度、模式切换、手动占空比
stm32_fan/online	设备上行	上线和掉线状态

上行数据每隔2秒发一次，如果频率太密没有意义，温度变化没那么快；太疏则手机端看起来像卡死。状态上报内容是JSON格式，把温度和占空比组装进去，手机端解析JSON显示。下行指令同样用JSON，手机发一句{"mode":"manual","duty":60}，STM32在cmd主题里收到后解析mode字段，如果等于manual就把PWM占空比设为60。

解析JSON在STM32端不要引大库，那会吃掉大量Flash。我的做法是用strstr函数定位关键字，再用sscanf提取数字。工作量大一点，但代码简单可靠，Flash占用也很少。比如收到指令后先找"mode"，再通过strstr判断是manual还是auto。

5.3 控制端的选择与实现方式

远程控制端有很多种做法，按投入成本从低到高排：手机上装一个通用MQTT客户端App、自己写Web页面、用低代码工具做小程序、自己开发手机App。

我推荐一个对毕设来说性价比很高的方案：写一个简单的Web控制页面。MQTT服务端支持WebSocket接入，浏览器原生JavaScript里用MQTT.js库订阅设备状态主题、发布控制指令。这样控制端不需要安装任何App，打开浏览器就能用，答辩现场演示时也不用担心手机上没有预装软件。

页面功能就三个核心区：

状态区：显示当前温度、风扇占空比、运行模式。
控制区：模式切换按钮、目标温度设置滑块。
数据区：一个简单的温度曲线图，把收到的历史温度画出来。

温度曲线图是演示利器。拿手捏住DS18B20探头，看手机端温度曲线上升，同时风扇转速跟着加快，整个过程观众一目了然。这个效果对答辩印象分的提升非常明显。

如果不想写网页，也可以直接用公共MQTT客户端测试工具，输入服务器地址和主题，就能看到设备上报的数据，也能手动发指令。缺点是界面不够直观，做毕设展示稍显简陋，但对功能验证完全够用。

5.4 断线重连与心跳保活

WiFi不稳定是这个项目做出来之后最大的坑。设备连着连着掉线，手机端就失去联系，过一会儿可能自己又连回来。这种情况如果不处理，答辩现场掉链子风险极高。

解决思路分三层。第一层是MQTT协议层，连接时设定keepalive时间，我这里设30秒。如果30秒内没有收到任何消息，MQTT服务端会主动断开连接，所以设备端要定期发心跳报文或者上报数据，让连接保持活跃。我每隔10秒发一次心跳，比keepalive时间短，留出了网络波动的余量。

第二层是断线检测。ESP8266掉线后，STM32发AT指令会收到ERROR，或者发送超时没有回包。我在发送逻辑里加了一个计数器，连续3次发送失败就判定为掉线。

第三层是自动恢复。检测到掉线后，STM32先尝试重启ESP8266模块，用GPIO拉低ESP8266的复位引脚，让模块重新上电，然后重新执行AT+CWJAP和AT+MQTTCONN流程，全程不需要人工干预。这个逻辑做完之后，系统在WiFi信号不稳定的情况下能实现分钟级自愈，持续跑一整天不掉线。

这套断线重连机制在答辩时一定要重点讲。很多人的毕设项目是断线后要手动复位才能恢复，而你这个系统能自动重连，这体现的不只是代码能力，更是对可靠性的理解。

6. 调试实录：那些年一起踩过的坑

6.1 一上电就反复重启

这个现象大概率是供电问题，而不是程序问题。排查顺序：先把ESP8266从电路上摘掉，看STM32是否正常工作；如果正常，再把ESP8266接回去，同时用万用表量3.3V电压波动。如果一接ESP8266电压就往下掉，就是供电能力不足，按前面说的加电解电容、换稳压模块解决。

还有一个容易混淆的情况是如果烧录后程序一直在跑，但串口打印乱码，这多半是时钟配置不对，或者波特率算错了。用LOG引脚对地短接，或者确实确认一下板子上的晶振是8MHz还是其他频率，CubeMX里时钟树配置对不对。

6.2 风扇上电就全速转的真相

这个问题我之前提过：MOS管栅极悬空导致意外导通。还有一个可能性是PWM初始化代码里，比较寄存器默认值就是满占空比，GPIO配置成复用功能之前，IO已经输出了高电平。正确的代码顺序应该是：先配置定时器PWM模式，设置CCR=0，再初始化定时器，最后使能PWM输出。把初始占空比设置为0，再加上硬件栅极下拉，双保险。

如果你用了四线风扇的PWM调速线而不是MOS管控制电源回路，也可能出现上电瞬间风扇转一下的"瞬态启动"现象，这是电机驱动里很常见的。我的建议是直接用MOS管方案，逻辑更干净。

6.3 温度读取忽高忽低

温度读数跳动，先排除软件问题再排查硬件。软件上检查延时是否准确，读取时序是否正确，有没有在别的中断里长时间占用CPU导致时序被破坏。硬件上检查上拉电阻是不是虚焊、DS18B20的VCC和GND是否接触良好、数据线是否和电源线长距离并行。

另外，如果读到-127或者85，这不是环境温度，而是DS18B20的典型错误码。出现这种值说明通信时序没对，或者设备根本没响应。先复位DS18B20，再读存在脉冲，用小灯闪烁来观察存在脉冲是否正常出现，用这个办法把问题范围缩小。

6.4 PID参数调不稳

PID调参遇到的主要问题是震荡。温度到了设定值附近，风扇转速在快速波动，整个系统发出周期性忽高忽低的声音。这个现象多数是Kp设得过大，或者Ki过大导致积分项饱和，严重的还会出现"积分饱和"问题：温度升上来了，积分项还维持着很高的输出，导致风扇继续高速转动。

我的处理策略是限制积分项范围，比如这里-100到100，避免积分饱和失控。然后先禁用微分项，只用P控制，把Kp从0开始慢慢增大，直到温度逼近目标值且没有明显的震荡。接着加Ki，每次加一点，观察稳态误差是否能消除。整个过程记录数据，直到温度维持在设定值正负0.5度以内。

6.5 常见问题排查速查表

现象	大概率原因	排查动作
ESP8266连不上WiFi	频段不匹配、密码错误	确认2.4G频段，AT+CWJAP回包看错误码
串口输出乱码	波特率或时钟配置不对	检查CubeMX时钟树和串口波特率
DS18B20读-127	时序或上拉问题	示波器看波形，测DQ线电压
风扇上电狂转	栅极悬空或初始化顺序不对	加下拉电阻，CCR初始为0
一接WiFi就重启	3.3V供电不足	加470uF电容，独立稳压
手机端收不到数据	主题拼错或JSON转义错误	用MQTT工具直接订阅确认
PID输出震荡	参数过大或积分饱和	限制积分项，减小Kp

7. 毕设展示与后续扩展

7.1 答辩演示怎么安排更有说服力

答辩环节的演示质量往往比论文本身更能决定分数。我给这套系统设计了一个三分钟的演示脚本，按照这个顺序走基本不会冷场。

第一步，静态展示。拿起主板，按模块介绍系统架构：STM32最小系统板作为主控，DS18B20探头采集温度，MOS管驱动12V风扇，ESP8266模块负责WiFi通信。这几十秒主要证明这是你自己做出来而不是照抄别人图。

第二步，实时演示。打开手机上的Web控制页面，先指着温度显示说明当前环境温度，然后切换手动模式，在手机上把风扇占空比从0调到100，观众能看到风扇转速变化、听到噪音变化。这个过程直观展示了远程控制链路。

第三步，自动演示。切回自动模式，设置目标温度为40度左右，用手握住DS18B20探头，让体温把温度读数顶上去。此时风扇应该自动加速，松开手让温度回落，风扇自动减速。这个动作非常有说服力，因为它是温度和控制的闭环联动。

第四步，加分项演示。如果做了OLED屏，把屏幕朝向评委，展示上面实时变化的温度、占空比和模式；如果做了断线重连机制，可以故意把路由器断电再恢复，展示设备自动重新上线。

每个环节之间用一句话解释原理，比如"温度传感器通过单总线接口把数据送给STM32，STM32用PID算法算出目标占空比，PWM信号通过MOS管控制风扇供电，ESP8266通过MQTT协议把状态同步到手机端"。评委听到这套表述，大概就知道你确实吃透了整个链路。

7.2 可以继续深入的方向

系统基本完成后，可以往几个方向扩展，按性价比排序：

加入OLED显示模块：I2C接口的0.96寸OLED，12864像素，在本地显示温度和风扇状态。硬件成本极低，但答辩时设备脱离手机也能独立展示状态，完整性明显提升。
加入断电保护策略：设计成WiFi断开后风扇切换到本地自动模式，温度超过安全阈值时即使没有远程指令也必须转起来。这个策略体现了对安全性的思考，在工业场景有实际意义。
加入实时转速反馈：选四线风扇的测速线，接STM32输入捕获引脚，把实际转速和PWM占空比关联，形成闭环。这个方向能聊的东西很多，可以做PID转速环和温度环串级控制。
加入多设备联动：再做一个从机节点采集另一个房间温度，主机根据温差协调两个风扇。系统从单点变成分布式，技术含量又上一个台阶。

这些扩展方向都建立在现有架构上，不需要推翻重来，做毕设时可以根据剩余时间灵活选择。我的建议是至少把OLED加进去，投入产出比最高，还能覆盖"本地显示"这个基础需求。

7.3 一个关于项目记录的实用建议

整个开发过程中，建议养成用文档记录关键问题的习惯。我在调PID参数时，把每组的参数和对应的温度曲线截图存档；在排查ESP8266掉线时，把AT指令日志和修改记录保留下来。这些过程性记录最后整理进毕设论文，就成了非常生动的"分析与调试"章节，比空谈原理更有说服力。老师翻到这些内容时，会直接认为这个项目的实践深度是真实可靠的。

另外，代码的注释尽量写清楚关键逻辑的行。三个月后答辩时要回答的很多问题，都在注释里写着，到时不至于看着自己写的代码回忆不起当时为什么这样写。

最后再分享一个实际操作中的体会

整套系统从零做完，我最大的感受是：这个项目真正的难点不在单片机编程，而在工程化的那颗心。DS18B20时序、PWM配置、MQTT接入，每一项都有现成教程，照着抄一遍可能一天就能跑通。但要让系统稳定工作，要在断电重连、电压跌落、传感器偶发错误这些异常场景下还能活得很好，考验的是调试能力和对细节的敏感。

这套方案里最值得你保留的，不是某个具体代码片段，而是分模块拆问题、分层定位问题的思路。传感器出问题先查时序和供电，WiFi出问题先查供电和固件版本，风扇不受控先查初始化和硬件下拉，每一步都能独立验证，组合起来就是全套调式策略。把这些思路真正内化成自己的习惯，以后遇到任何嵌入式项目都会受用。

如果你正在做同为类的毕设题目，遇到"风扇上电就转""温度忽高忽低""WiFi掉线"这类问题卡住，优先回头看正文里的排查表。那些坑我都陪人走过也自己踩过，按照顺序排查基本半个小时内能找到病根。祝顺利做出让人眼前一亮的风扇系统。