STM32 WiFi远程温控风扇系统：DS18B20与PWM调速完整实战

如果有人问我，嵌入式毕业设计里哪个题目看着最不起眼、做起来却最考验基本功，我一定提名“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-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、DQ），DQ 需要外接一个 4.7kΩ 上拉电阻，主控用一个 GPIO 就能完成所有通信。测温范围 -55℃ 到 +125℃，对风扇温控场景绰绰有余。

2.4 驱动电路：三极管、MOS管、L298N、继电器怎么选

这是新手重灾区。风扇驱动有四种常见方案，我列一下实际表现：

做毕设最合适的是 N-MOS管（AO3400）。它是逻辑电平 MOS，STM32 的 3.3V 或 5V GPIO 可以直接驱动栅极，导通电阻只有几十毫欧，风扇电流 200mA 以内时几乎不发热。接线就是：

STM32 GPIO（如 PA6）—— 100Ω 电阻 —— MOS管栅极(G) 源极(S) 接 GND 漏极(D) —— 风扇负极 风扇正极 —— 电源正极（5V 或 12V，按风扇规格）

我强烈建议在风扇两端反向并联一个 1N4148 或 SS14 二极管，也就是续流二极管。否则风扇关断瞬间产生的反向电动势可能直接打坏 MOS 管，这个细节很多教程都没写。

3. 数据链路与控制策略：从温度值到 PWM 占空比

3.1 一条链路上的信号走向

整个系统的数据流是这样的：

1. DS18B20 检测环境温度，把 12 位温度值通过单总线协议送到 STM32 的 GPIO。
2. 主控把原始数据传输成十进制温度值，比如 27.5℃，保存到一个全局变量里。
3. 控制策略模块根据当前温度、当前模式（自动/手动）计算出目标 PWM 占空比。
4. 定时器以设定的占空比输出 PWM 波形到 MOS 管栅极。
5. 同时，主控通过串口把温度值、风扇状态封包发给 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 指令模式。配置流程分三步：

第一步，配置工作模式并连接路由器：

AT+CWMODE=1 AT+CWJAP="你的SSID","你的密码"

连接成功后，模块会返回 WIFI CONNECTED 和 WIFI GOT IP。到这里，模块已经获得局域网 IP。

第二步，建立 TCP 连接：

无论用手机 APP 直连，还是经过云平台转发，本质上都是 TCP 连接。以手机 APP 作为 TCP Server、设备作为 TCP Client 为例：

AT+CIPSTART="TCP","192.168.1.100",8080

连接成功会返回 CONNECT OK。

第三步，透发数据：

AT+CIPSEND=9 > #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，比如端口 8080，WiFi 模块连同一个路由器后主动连接手机 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 接模块 RX，STM32_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、自动重装载 3600，PWM 频率大约就是 10kHz；想要 20kHz，把重装载值调到 1800。调好后听不到啸叫，波形也稳定。

5.5 设备上电顺序与 WiFi 初始化超时

WiFi 模块上电后需要约 1~2 秒完成内部初始化，如果 STM32 在它还没准备好就发 AT 指令，指令会全部丢失。解决方法是在 STM32 初始化代码里加一段延时，等 1.5 秒后再开始发送连接指令。更稳妥的方式是不断轮询发送 AT，直到收到 OK 再继续，这样即使上电时序有波动也不会卡死初始化流程。

另外，开机时最好不要断电重启太快，模块 Flash 频繁快速写入容易产生文件系统异常。我遇到过几次模块莫名掉线，重新上电后又正常，怀疑与快速上下电有关。

6. 把毕设从“能转”做成“能讲”：几点扩展建议

6.1 加一块 OLED 显示实时状态

做毕设演示时，观众不可能一直盯着手机屏幕。加一块 0.96 寸 OLED（I2C 接口），在主界面上显示当前温度、目标温度、风扇转速百分比、当前模式，整套设备看起来立刻完整很多。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 上逐段打通，别一上来就全系统联调。链路顺畅了，剩下的都是锦上添花。