如果有人问我嵌入式毕业设计里哪个题目看着最不起眼、做起来却最考验基本功我一定提名“STM32 WiFi远程温控风扇系统”。光看名字一个风扇而已可真正动手去做才会发现温度采集、PWM调速、WiFi透传、远程指令下发、控制策略回控这一整条链路几乎把单片机开发里的核心模块全串起来了。这篇文章我会从方案选型开始把硬件搭配、控制逻辑、通信协议、调试踩坑一条线写下来给准备做这个题目的同学一份可以照着复现的完整参考。1. 这个题目看上去简单实际考了你哪些硬功夫1.1 一颗芯片撑起一条完整数据链路先说这个系统最核心的一条链路温度传感器 → STM32 主控 → 控制策略运算 → PWM 输出 → 电机驱动 → 风扇与此同时STM32 通过串口与 WiFi 模块通信手机或电脑远程下发指令主控切换模式或修改目标温度再回到控制链路。这条链路看起来直白拆开每一段都是考点。第一段是传感器驱动。用 DS18B20 还是 NTC 热敏电阻直接决定了你的驱动代码工作量。DS18B20 是单总线协议靠一个 GPIO 引脚完成复位、存在检测、读数据、写数据时序要求严格这也是面试和答辩时最容易展开提问的通信协议之一。第二段是执行机构控制。风扇是直流电机调速要用 PWM这个动作本身不复杂但关键在功率驱动电路。三极管、MOS管、续流二极管怎么选、怎么接恰恰是很多同学上课时容易忽略的部分也是实际操作中翻车率最高的地方。第三段是无线通信。WiFi 模块在这里扮演的角色是“透明传输通道”主控通过串口发 AT 指令给它它负责把数据打包成 TCP 包发送到远端的手机或服务器再把远端指令回传给主控。这块涉及 AT 指令集、TCP/IP 报文以及主控与模块之间的通信状态机设计。第四段是控制策略。同样是“温度高就转”的系统有人做成简单开关有人做成带滞回的双阈值控制有人做成平滑调速也有人直接上 PID 做闭环恒温。这四档水平差异在毕设答辩时一眼就能看出来。1.2 毕设评审时最关注的三个维度这种题目在评审老师眼里有三个核心关注维度系统完整性从传感器采集到远程控制是不是一条封闭的、能跑通的链路。不少同学会把重点压在某一个模块上比如把 WiFi 调通就兴奋得不行结果温度控制策略做得极其粗糙风扇只会全速和停止缺少渐进控制过程整体就显得“断层”。抗干扰和稳定性温度读数偶尔跳变怎么处理WiFi 断线怎么重连手动模式和自动模式切换时风扇状态怎么过渡这些边界情况处理是否得当是拉开分数差距的关键。可复现性毕业设计不是纯科研老师会关注你的方案是否成本合理、操作是否方便、代码是否结构清晰。能给出“插上电就能演示”的完整操作说明印象分会明显不同。这个题目最讨巧的地方在于它天然自带物联网标签可以自然地串联 MCU 开发、无线通信、移动端展示等多层技术比单做一个温度检测仪或一个单纯手机遥控电扇要有内容得多。2. 硬件方案选型主控、WiFi模块、传感器、电机驱动怎么搭配2.1 主控选型的三种思路STM32 家族里我实测下来做这个题目最舒服的是 STM32F103C8T6。原因很现实资料最多出问题好排查72MHz 主频跑这个系统绰绰有余定时器通道充足输出两路 PWM 毫无压力价格便宜最小系统板几十块以内能搞定标准库和 HAL 库两种开发方式都有大量现成例程。如果老师要求“新一点”的方案也可以选 STM32G030 系列但前提是你自己熟悉 HAL 库开发流程。G0 系列的资料量相对 F1 要少一些遇到问题排查成本会明显高一些。最不推荐在这个题目上用 F407 甚至更高端的级别——性能冗余是一方面更大的问题是高配置芯片会让设计显得“小题大做”反而容易被追问为什么选这么贵的片子。顺带说一句如果你用 Arduino 框架来做验证确实能快速跑通功能但正式交付时不太建议——评审老师更愿意看到你用寄存器或标准库把关键逻辑写明白。2.2 WiFi 模块选择ESP-01S 还是 ESP-12F目前最常用的方案基本是 ESP8266 系列常见的是 ESP-01S 和 ESP-12F 两种封装。这里给一个实际对比对比项ESP-01SESP-12F引出引脚8 脚可用 GPIO 很少16 脚GPIO 丰富天线板载 PCB 天线外置天线或板载价格更便宜略贵接线方便程度简单适合面包板和焊接需要转接板适合场景纯做 WiFi 透传想用模块本身做更多控制这个题目里ESP-01S 完全够用。它的工作就一句话主控说“连上路由器”它就连主控说“把这包数据发出去”它就发。模块自己不需要承担太多业务逻辑GPIO 少根本不是问题。我个人的建议是使用 ESP-01S但是要在模块 VCC 和 GND 之间并联一个 10uF 电解电容和一个 0.1uF 陶瓷电容。原因是 ESP8266 在发射瞬间电流摆动很大如果不滤波ST 芯片和 ESP 模块共用一路电源时会出现复位重启的诡异问题这个后面第 5 章会展开说。2.3 温度传感器DS18B20 依然是省心之选温度传感器选项不少我用过 NTC、DHT11、DS18B20、LM75综合体验排在第一位的是 DS18B20。NTC 热敏电阻成本最低但你需要自己搭电桥、自己查表换算温度标定过程能折腾一整天。DHT11 能同时出温度和湿度但精度只有 ±2℃而且单总线时序带扰动读一次数据要好几毫秒。DS18B20 精度 ±0.5℃单总线协议直接输出数字量零校准成熟封装一抓一大把。DS18B20 三根引脚VCC、GND、DQDQ 需要外接一个 4.7kΩ 上拉电阻主控用一个 GPIO 就能完成所有通信。测温范围 -55℃ 到 125℃对风扇温控场景绰绰有余。2.4 驱动电路三极管、MOS管、L298N、继电器怎么选这是新手重灾区。风扇驱动有四种常见方案我列一下实际表现方案能否调速成本压降坑点三极管S8050 等可以最低较大电流稍大就发烫驱动能力打折N-MOS管AO3400可以低极小注意栅极驱动电压L298N 驱动模块可以中等较大体积大板上稳压管容易发热继电器不能中等无机械触点频繁通断寿命短有火花做毕设最合适的是 N-MOS管AO3400。它是逻辑电平 MOSSTM32 的 3.3V 或 5V GPIO 可以直接驱动栅极导通电阻只有几十毫欧风扇电流 200mA 以内时几乎不发热。接线就是STM32 GPIO如 PA6—— 100Ω 电阻 —— MOS管栅极(G) 源极(S) 接 GND 漏极(D) —— 风扇负极 风扇正极 —— 电源正极5V 或 12V按风扇规格我强烈建议在风扇两端反向并联一个 1N4148 或 SS14 二极管也就是续流二极管。否则风扇关断瞬间产生的反向电动势可能直接打坏 MOS 管这个细节很多教程都没写。3. 数据链路与控制策略从温度值到 PWM 占空比3.1 一条链路上的信号走向整个系统的数据流是这样的DS18B20 检测环境温度把 12 位温度值通过单总线协议送到 STM32 的 GPIO。主控把原始数据传输成十进制温度值比如 27.5℃保存到一个全局变量里。控制策略模块根据当前温度、当前模式自动/手动计算出目标 PWM 占空比。定时器以设定的占空比输出 PWM 波形到 MOS 管栅极。同时主控通过串口把温度值、风扇状态封包发给 WiFi 模块再由 WiFi 模块转发到远端服务器或手机。每一步都有明确的功能边界调试时可以逐段打日志验证传感器有没有读到数、控制策略有没有算出正确的占空比、串口有没有把数据发出去。这种逐层排查的习惯能让整个开发过程少走一半弯路。3.2 DS18B20 读取的关键细节与代码骨架DS18B20 的单总线时序有三个关键阶段复位脉冲、ROM 命令、功能命令。每次完整读温度需要先发复位拉低 480us 以上再释放然后发送跳过 ROM 命令 0xCC再发启动温度转换命令 0x44等待转换完成12 位精度约 750ms接着再复位发送跳过 ROM 命令 0xCC发读暂存器命令 0xBE连续读两个字节得到温度低字节和温度高字节。温度值等于高字节左移 8 位 | 低字节除以 16。实际项目中我把它封装成了下面这样的骨架float readTemperature(void) { uint8_t low 0, high 0; uint16_t raw 0; float temp 0.0f; if (!ds18b20_reset_pulse()) return -100.0f; // 设备不存在 ds18b20_write_byte(0xCC); // 跳过ROM ds18b20_write_byte(0x44); // 启动温度转换 delay_ms(750); // 等待12位精度转换完成 ds18b20_reset_pulse(); ds18b20_write_byte(0xCC); ds18b20_write_byte(0xBE); // 读暂存器 low ds18b20_read_byte(); high ds18b20_read_byte(); raw (high 8) | low; temp (float)raw / 16.0f; return temp; }时序实现里我踩过最大的坑是DS18B20 的读写时序对 GPIO 方向切换非常敏感。如果完全依赖库函数里的 GPIO 写和读接口逐位操作函数调用开销会把时序拉长导致读到 0xFFFF 或温度数据跳变。保险做法是在读写函数里用寄存器直接操作配合短暂延时。如果你用标准库的寄存器操作时序更容易控住。3.3 三种控制策略对比开关、滞回、分段调速拿到温度值之后核心问题就是怎么把温度映射成风扇的转动状态。策略一单阈值开关控制温度 30℃ → 风扇全速 温度 ≤ 30℃ → 风扇停止代码最简单但致命问题是频繁启停。温度刚好在 30℃ 附近小幅波动时风扇会一会开一会关电机反复启动的瞬间电流大、噪音明显观感也业余。策略二滞回双阈值控制温度 32℃ → 风扇全速 温度 28℃ → 风扇停止 28℃ ~ 32℃ → 保持当前状态不变这个方案相当于给策略一加了回差带延迟“开”和“关”的切换点能明显降低频繁启停。代码只多两个阈值判断成本很低却带来实打实的稳定感是我的首推方案。策略三分段线性调速温度 25℃ → PWM 占空比 0 25℃ ~ 35℃ → 占空比 (温度 - 25) / 10 * 100% 温度 35℃ → 100%把温度区间线性映射到 PWM 占空比风扇转速随温度平滑上升没有跳变观感最好。代码其实就是线性插值uint32_t speed 0; if (temp 25.0f) { speed 0; } else if (temp 35.0f) { speed 100; } else { speed (uint32_t)((temp - 25.0f) * 10.0f); // (temp-25)/10*100 } __HAL_TIM_SET_COMPARE(htim2, TIM_CHANNEL_1, speed * 65535 / 100);如果要在答辩时多讲一点东西我建议在分段调速的基础上再叠加滞回效果结合两者做“带滞回的分段平滑控制”降温路径比升温路径延迟 1℃ 再降速既平滑又不会波动。实际效果明显更好。4. 软件实现主控程序结构、WiFi透传与远程控制协议4.1 主控程序的任务划分STM32 端我用的是定时器中断 主循环轮询的结构避免用阻塞式延时把整个程序卡死。任务划分如下SysTick 定时器提供 1ms 系统节拍维护一个全局 tick 计数。TIM2 通道 1输出 PWM 到风扇 MOS 管。UART2连接 WiFi 模块串口中断接收远程指令。主循环每 200ms 读一次温度每 500ms 更新一次控制输出每 1s 上报一次数据到远端。主循环骨架大致是这样while (1) { if (Tick - lastRead 200) { currentTemp readTemperature(); lastRead Tick; } if (Tick - lastControl 500) { applyControlStrategy(currentTemp, currentMode); lastControl Tick; } if (Tick - lastReport 1000) { reportStatus(currentTemp, fanSpeedPercent); lastReport Tick; } processRemoteCommand(); // 解析串口透传下来的指令 }这里有个很重要的设计理念传感器读取、控制输出、数据上报三个任务用不同的周期解耦。很多新手会写成“读一次温度 → 算一次控制 → 发一次串口 → 延时”的线性结构一旦 WiFi 发送阻塞整个控制周期就被拖崩。周期解耦之后即使 WiFi 偶尔卡顿温度采集和控制输出仍能保持稳定运行。4.2 ESP-01S 的 AT 指令配置流程ESP-01S 上电后直接进入 AT 指令模式。配置流程分三步第一步配置工作模式并连接路由器ATCWMODE1 ATCWJAP你的SSID,你的密码连接成功后模块会返回 WIFI CONNECTED 和 WIFI GOT IP。到这里模块已经获得局域网 IP。第二步建立 TCP 连接无论用手机 APP 直连还是经过云平台转发本质上都是 TCP 连接。以手机 APP 作为 TCP Server、设备作为 TCP Client 为例ATCIPSTARTTCP,192.168.1.100,8080连接成功会返回 CONNECT OK。第三步透发数据ATCIPSEND9 #T,27.5#发送结束时模块会自动追加换行并返回 SEND OK。WiFi 模块收到网络端下发的数据后会通过串口把数据原样推给 STM32这就是透传。需要注意模块收到数据时会前置几个字节的前缀比如 IPD主控在接收解析时必须先把前缀剥离。4.3 远程控制指令协议的设计远程下发指令时我建议不用 JSON而是用自定义的短指令帧。理由很实际STM32 的 Flash 和 RAM 都有限解析 JSON 需要字符串处理逻辑会显著增加固件体积和出错概率。短指令的可读性和调试便利性反而更好。推荐协议格式字段: 帧头(1字节) 命令类型(1字节) 数据(1~2字节) 帧尾(1字节) 示例: #M,1# → 切换为手动模式 #M,0# → 切换为自动模式 #T,30# → 手动模式下设置风扇转速为 30% #A,28# → 修改自动模式目标温度主控解析逻辑用 switch 判断命令类型即可void processRemoteCommand(void) { char cmd rxBuffer[1]; int value rxBuffer[3] - 0; switch(cmd) { case M: currentMode value ? MANUAL : AUTO; break; case T: if (currentMode MANUAL) setFanSpeed(value); break; case A: targetTemp value; break; } }协议越简单出 bug 的概率越低演示时也越可靠。唯一要注意的是发送端必须约定好 ASCII 编码值超过 9 时发送端要发送多位数字接收端完整拼接后再转换。4.4 两种远程接入方案局域网直连与云平台转发这里给两种可选网络拓扑。方案 A局域网直连。手机开一个 TCP Server比如端口 8080WiFi 模块连同一个路由器后主动连接手机 IP。优点是链路最短、调试最快缺点是只能在同一个局域网下控制出了局域网就不行。对毕设演示来说这个方案基本够用。方案 B云平台转发。WiFi 模块连上互联网后与某个物联网平台建立连接温度数据定时上报手机通过平台查看实时数据和下发指令。优点是真正做到远程控制手机在移动网络下也能控制设备缺点是配置流程更复杂需要提前创建产品、获取密钥模块端还要处理 MQTT 协议或 HTTP 请求。如果时间紧张建议先跑通方案 A再把方案 B 作为进阶功能写进论文和演示。两者在模块侧的区别主要只是 TCP 连接的目标地址不同数据帧协议完全可以复用。5. 最容易翻车的五个环节以及我踩坑后的修复方案5.1 电源方案不当导致的“反复重启”这是最隐蔽也最坑人的问题之一。ESP8266 发数据时的峰值电流可以达到 200~300mA如果用 USB 5V 经 AMS1117 转 3.3V 供电一旦模块发射3.3V 电压被拉低STM32 就进入欠压复位。现象是系统运行几秒后突然重启串口打印停留在 WIFI GOT IP 之后。修复方法是在 3.3V 电源两端加 100uF 电解电容和 0.1uF 陶瓷电容并联并且最好用独立 LDO 给 WiFi 模块供电与 STM32 的 3.3V 分开。如果板子上已有 5V 输入直接用一个 5V 转 3.3V 的降压模块会更稳。5.2 串口线接反与电平不匹配WiFi 模块的串口是 3.3V 电平不能容忍 5V 输入。直接拿 5V 的 USB-TTL 小板去接它大概率把模块烧掉或产生串口乱码。正确做法是保证 TTL 小板本身是 3.3V 电平很多小板带电平跳线可以切换。STM32 的串口引脚如果标注为 5V 容忍可以和模块直连但 RX/TX 要交叉STM32_TX 接模块 RXSTM32_RX 接模块 TX。交叉接反是最常见的错误现象是 STM32 发指令模块完全没反应但模块自己发的数据能到 STM32。排查办法是先单独用串口助手连模块确认模块能返回 OK再接入 STM32 联调。5.3 DS18B20 时序不稳把 DS18B20 用 20cm 以上杜邦线连接时线缆分布电容变大读出来的数据经常跳变甚至读到 0xFFFF 表示设备不存在。解决方案是缩短线缆把传感器焊到小板上数据线上加 4.7kΩ 上拉电阻这是必需的有条件可以改用屏蔽线或双绞线。桌面演示场景下用短杜邦线连接基本问题不大。我实测过上拉电阻从 4.7kΩ 换成 10kΩ 时20cm 线缆下读取成功率明显下降所以 4.7kΩ 是这个系统的推荐值不要随意加大。5.4 PWM 频率不合适导致风扇啸叫PWM 调速直流风扇频率太低时能听到明显的“滋滋”啸叫声这是 PWM 谐波和电机绕组产生机械共振。我测试过1kHz 时几乎每个风扇都啸叫10kHz 时明显改善15kHz~20kHz 基本听不到啸叫。所以定时器的 PWM 频率建议设置在 15kHz~20kHz。以 72MHz 时钟为例设置预分频 1、自动重装载 3600PWM 频率大约就是 10kHz想要 20kHz把重装载值调到 1800。调好后听不到啸叫波形也稳定。5.5 设备上电顺序与 WiFi 初始化超时WiFi 模块上电后需要约 1~2 秒完成内部初始化如果 STM32 在它还没准备好就发 AT 指令指令会全部丢失。解决方法是在 STM32 初始化代码里加一段延时等 1.5 秒后再开始发送连接指令。更稳妥的方式是不断轮询发送 AT直到收到 OK 再继续这样即使上电时序有波动也不会卡死初始化流程。另外开机时最好不要断电重启太快模块 Flash 频繁快速写入容易产生文件系统异常。我遇到过几次模块莫名掉线重新上电后又正常怀疑与快速上下电有关。6. 把毕设从“能转”做成“能讲”几点扩展建议6.1 加一块 OLED 显示实时状态做毕设演示时观众不可能一直盯着手机屏幕。加一块 0.96 寸 OLEDI2C 接口在主界面上显示当前温度、目标温度、风扇转速百分比、当前模式整套设备看起来立刻完整很多。OLED 驱动代码用现成库就能跑不增加太多工作量但观感提升非常明显。显示信息可以这样设计Temp: 27.5C Speed: 45% Mode: AUTO配合 OLED还可以做一个加分功能显示最近 30 秒的温度变化字符网格让温控过程可视化。只需要维护一个环形数组每 1 秒存一个温度值30 个点就能画出一行走势实现成本很低。6.2 用物联网平台把数据做成折线图和远程告警如果愿意在方案 B 上再走一步可以找一个开放 API 的物联网平台定期上报温度和风扇转速。手机端打开平台小程序或网页就能看到折线图也能下发指令。这部分写进论文可以让“远程”这个概念从局域网扩展到公网含金量立刻提升。需要提醒的是平台接入需要注册和创建产品建议提前两三天做不要拖到答辩前。6.3 增加手动、自动、定时三种运行模式只做自动温控略显单薄手机端可以增加三个模式自动模式系统根据温度自动调速。手动模式用户直接设置风扇转速百分比。定时模式设定时间段内按低转速运行其他时间按自动模式。这个扩展本质是一个模式枚举变量主控逻辑不复杂但能体现你对用户使用场景的思考。答辩讲的时候从“我能遥控风扇”升级到“我设计了三种贴合实际场景的运行模式”叙事层次完全不一样。6.4 用 PID 做一个真正的闭环恒温控制如果学有余力可以尝试把控制策略从分段调速升级为 PID 恒温控制设定目标温度后PID 根据当前温度与目标值的偏差计算占空比。比如设定 25℃温度偏高则加速偏低则降速最终让环境温度稳定在目标附近。PID 三参数可以先凑后调比例系数先给一个值积分和微分暂设为零观察振荡情况再逐步增加积分项消除静差。实际上风扇温控属于大惯性系统微分项要非常小心过大的微分会导致输出剧烈抖动风扇转速忽高忽低。调参时先把 Kp 调到系统出现等幅振荡的 50% 左右再把 Ki 设为 Kp 的 1/10 起步Kd 从零慢慢加。整个调参过程本身就是很好的答辩素材。这个题目做到最后我最大的感受是它真正考验的不是你会用多少款芯片而是能不能把一条多模块链路稳定跑起来。温度读不准先怀疑时序而不是怀疑传感器WiFi 掉线先看电源再看代码PWM 啸叫先调频率再查驱动。把这些排查思路理清楚答辩时被问到的任何问题都能从容应对。如果正被这个题目卡在某个环节我的建议是先最小化闭环用 USB-TTL 单独验证 WiFi 模块单独验证 DS18B20再把它们接到 STM32 上逐段打通别一上来就全系统联调。链路顺畅了剩下的都是锦上添花。