企业官网建设流程全解析

这套多功能智能温控风扇系统，是我基于STM32F103C8T6做的一个完整开源项目，从需求梳理、原理图设计、C语言代码编写到Proteus仿真验证，整个流程走了一遍，最后把代码、原理图和仿真工程全部打包开源。一句话概括它的功能：通过DHT11温湿度传感器实时采集环境温度，单片机根据温度自动调节风扇转速，温度高转得快，温度低转得慢甚至停转，同时还带手动调速、OLED显示、阈值报警这些实用功能。它能解决的问题很实在——设备一热风扇自动跟上，降温后自动减小噪音和功耗，不用人反复去拨开关。如果你想拿STM32练手，从零跑通“传感器采集→数据处理→执行器控制→人机交互”这条完整链路，或者正在找课程设计、毕业设计的参考项目，这份开源资料可以直接拿当样板。

1. 为什么做这个项目：温控风扇背后的设计逻辑

1.1 从需求出发：一个风扇能解决什么问题

先说应用场景。路由器和NAS长期开机，夏天摸外壳烫手，风扇一直全速转又吵；3D打印机的热床和喷头旁边需要一个辅助散热风扇，温度到了才启动；工控机柜、实验室设备、甚至鱼缸降温，都面临“什么时候该吹、吹多大风”的问题。普通风扇只有开关和固定档位，不管温度高低都是同一个转速，要么散热不足，要么噪音和功耗浪费。

很多入门者做温控风扇，直接就是个“开环”方案：温度超过阈值就开风扇，低于阈值就关。这能用，但体验很一般。实际做项目你会发现，如果阈值设成30℃，风扇会在29℃和31℃之间来回开关，继电器“咔哒咔哒”响，电机频繁启停，寿命和噪音都受不了。所以这套系统我一开始就定了几个目标：第一，温度连续控制风扇转速，而不是简单的开和关；第二，加滞回区间解决临界点反复跳变；第三，保留手动模式，让使用者在自动之外能强制控制；第四，要有显示和按键，方便调试。

这些需求拆解下来，核心其实就是一个“温度到 PWM 占空比的映射”问题，再往外扩展就是模式切换、显示刷新、报警处理这些状态管理。想明白这一点，整个项目架构就清晰了。

1.2 核心方案选型：主控、传感器、驱动、显示怎么组合

方案选型是嵌入式项目最早也是最重要的一步，选错了后面全得返工。先给出一套我用下来最稳的组合，然后逐个说理由。

主控选STM32F103C8T6没什么悬念，72MHz主频、64KB Flash、20KB RAM，对付这种项目绰绰有余。芯片便宜，而且资料全到不能再全，网上随便一搜就是上千篇教程。另外一个现实因素是国产APM32F103C8T6在硬件上基本兼容，程序可以直接烧进去跑，这也是我做项目时的一个小心得：选主流芯片，后面做产品降本、找替代料都从容。

温度传感器我选了DHT11而不是DS18B20，因为这套系统除了温度还想顺便显示湿度，DHT11一个传感器两路数据，性价比高。如果对温度精度要求高，比如要控制到±0.5℃，DHT11不够看，得换DS18B20或SHT30，这个后面在“常见问题”里我会展开对比。风扇驱动部分，很多人一开始想用继电器的简单通断，但继电器没法做连续调速，而且频繁吸合寿命堪忧，直接否决。驱动部分用三极管还是MOS管，取决于风扇功率：0.1A级别的小风扇，S8050三极管就够；0.5A以上的大风力风扇，建议换成N-MOS管，比如AO3400，导通电阻小发热低。显示选了OLED，因为I2C只要两根线，还能做成一个小的状态面板，直观看到当前温度、湿度、模式和PWM占空比，比LCD1600省引脚也好看。

2. 硬件设计：原理图里那些容易被忽略的细节

2.1 最小系统搭建：晶振电容计算与启动配置

原理图设计从最小系统开始。STM32F103C8T6的最小系统比51单片机稍微讲究一点，主要包括电源、晶振、复位电路、BOOT引脚和下载电路。

先说晶振。板子上用8MHz无源晶振作为HSE时钟源，再经过PLL倍频到72MHz。无源晶振需要两个负载电容，容值不是随便接的，要匹配晶振的负载电容参数。计算公式是：CL = (C1 × C2) / (C1 + C2) + Cstray，其中Cstray是PCB走线和引脚引入的寄生电容，一般估3~5pF。拿8MHz晶振常用负载电容12pF为例，如果C1和C2各取22pF，并联后是11pF，加上寄生电容约4pF，正好15pF左右，偏大一点；想更接近12pF，可以取18pF。实际我焊过的板子，18pF和22pF都能正常起振，但有一个坑：如果PCB走线太长、布局太差，取22pF偶尔会起振不稳定，表现是程序能下载但跑不起来，万用表量晶振引脚电压异常。稳妥做法是电容先按18pF来，留两个空焊盘方便以后调。

复位电路就是一个10kΩ上拉电阻加一个100nF电容到地，注意STM32是低电平复位。BOOT0和BOOT1引脚要拉低，确保从主Flash启动。下载电路用标准的ST-Link SWD四线：SWDIO、SWCLK、GND、3.3V，再加上NRST复位脚，四针加上一根复位线足够用。还有一个容易漏的细节：STM32每个VDD引脚旁边都要放一个100nF去耦电容，而且尽量靠近引脚，电源入口再放一个10μF/16V的钽电容或电解电容做储能。很多人做板子只放一个总电容，结果电机一启动，单片机就复位，就是这个原因。

另外，如果购买的是最小系统板而不是自己画PCB，这些电路板厂已经处理好了，直接插上就能用。但如果你计划把这套智能温控方案产品化，建议还是从最小系统开始自己画一遍原理图，对电源完整性、去耦、晶振布局这些概念会有非常直观的理解。

2.2 传感器与执行器电路：上拉电阻和续流二极管不能省

DHT11接线非常简单：VCC接3.3V，GND接地，DATA信号线接到单片机GPIO，同时需要在DATA线上接一个4.7kΩ到10kΩ的上拉电阻到VCC。这个上拉电阻看起来不起眼，但去掉它之后，DHT11的通信会非常不稳定，数据要么读不出来，要么校验失败。因为DHT11是单总线开漏输出，靠外部上拉电阻产生高电平。我用4.7kΩ比较多，PCB走线稍长就用10kΩ，经验值，都能工作。

风扇驱动电路是这个项目里最容易出问题的地方，我单独强调一下。小风扇驱动用NPN三极管S8050做低端开关，电路结构是：风扇正极接5V电源，风扇负极接三极管集电极，三极管发射极接GND，基极通过1kΩ电阻接单片机PWM输出引脚。基极电阻一定要加，它是限流用的，不加的话GPIO口灌电流过大，轻则波形变形，重则烧引脚。S8050的放大倍数高，10kΩ也能导通，但为了让开关速度更快、饱和压降更低，1kΩ到4.7kΩ之间比较合适。

最关键的是必须在风扇两端反向并联一个续流二极管，正极接电源端，负极接三极管集电极端。这个二极管的作用是吸收风扇关断瞬间产生的反电动势。风扇是感性负载，电流突然中断时会产生一个很高的反向电压，峰值几十伏，不加二极管，这一下就能把三极管击穿。我第一次焊驱动板就吃过这个亏，风扇“啪”一声响，三极管烧了，后来才意识到是续流的问题。小电流用1N4148，大电流用1N4007或者SS34肖特基都行。

如果是12V大风扇，驱动方案类似，但注意三个问题：第一，单片机PWM信号电平是3.3V，驱动12V系统时要确认三极管或MOS管的开启电压阈值能满足；第二，12V电源和5V/3.3V电源必须共地，否则PWM信号没有参考地，风扇不会有反应；第三，大电流走线要加粗。更稳妥的做法是用光耦隔离，比如PC817，把3.3V控制侧和12V功率侧隔开，安全性高很多。不过做课程设计级别的小项目，三极管直连加共地就够了。

2.3 电源设计与功耗预算

电源部分是很多新手容易忽略的。STM32F103C8T6工作在3.3V，而DHT11和OLED通常也走3.3V，但风扇用5V或12V。所以整个系统至少需要两路电压：3.3V给逻辑部分，5V/12V给驱动部分。

我的方案是USB 5V输入，经过AMS1117-3.3稳压到3.3V，风扇直接由5V供电，不需要额外升压。AMS1117最大输出1A，而STM32整板电流加OLED屏幕也就几十毫安，绰绰有余。特别提醒：风扇不要从AMS1117的输出端取电，因为风扇启动瞬间电流可能冲到几百毫安，会导致3.3V电压跌落，单片机直接复位。风扇一定要接在5V入口侧，和LDO前面，这样即使AMS1117短暂压降，3.3V波动也小。如果开关电源输入波动大，在5V入口并一个100μF电容，在3.3V输出并一个10μF电容，整个电源会稳很多。

功耗也好估算：STM32F103C8T6全速跑大约80mA，OLED峰值约20mA，DHT11工作电流小于1mA，S8050驱动小风扇时风扇电流约80mA，总功耗大概5V × 180mA = 0.9W。这个功耗用USB口供电完全没问题。如果换12V大风力风扇，电流0.3A以上，功耗会到3.6W，那就要考虑外置适配器供电，不能指望USB口带得动。

3. 软件实现：从温度采集到PWM调速的完整逻辑

3.1 工程结构：状态机为核心，模块化拆分

软件架构我拆成了几个独立模块：main.c负责整体流程和状态机，dht11.c负责温湿度采集，display.c负责OLED显示，fan.c负责PWM驱动，key.c负责按键处理，buzzer.c负责报警。每个模块只公开几个接口函数，内部实现细节封装起来，这样调试的时候能快速定位问题在哪个环节。

整体运行逻辑是一个典型的状态机：系统启动后做外设初始化，进入主循环，主循环里依次处理温度采集、按键扫描、模式切换、风扇控制、显示刷新。状态分为手动模式、自动模式和报警模式。手动模式用户通过按键直接设定风扇转速；自动模式根据温度计算目标转速；当温度超过报警阈值时，不管当前什么模式，蜂鸣器都会响，同时风扇强制全速转，直到温度回落到安全范围。

关于用标准外设库还是HAL库，我个人的建议是：如果是入门学习或者想快速做出可以跑的东西，标准外设库就够用，代码直接清晰，网上例程也最多；如果以后准备往企业开发方向走，HAL库是主流，但上手难度高一点。这套项目源码我用的标准外设库，因为中断、定时器PWM、GPIO这些操作在寄存器层面更容易理解，对初学者友好。

3.2 DHT11温度采集：单总线时序与坑点

DHT11是单总线通信，数据线只有一根，所有时序都由高低电平脉冲的宽度来定义，而且时序要求比较严格，差个几十微秒就可能读错数据。通信过程分两步：主机先发送起始信号，DHT11响应后连续发送40位数据，每一位都以50μs低电平开始，高电平26~28μs表示“0”，高电平70μs表示“1”。湿度高8位、湿度低8位、温度高8位、温度低8位，最后8位是校验和，前四个字节相加等于校验和才说明数据有效。

读取一个字节的核心代码如下：

uint8_t DHT11_ReadByte(void) { uint8_t i, data = 0; for (i = 0; i < 8; i++) { while (GPIO_ReadInputDataBit(DHT11_PORT, DHT11_PIN) == 0); // 等待50us低电平结束 Delay_us(30); // 延时到数据位中间 if (GPIO_ReadInputDataBit(DHT11_PORT, DHT11_PIN) == 1) data = (data << 1) | 0x01; // 此时仍为高 -> 1 else data = (data << 1) | 0x00; // 此时已变低 -> 0 while (GPIO_ReadInputDataBit(DHT11_PORT, DHT11_PIN) == 1); // 等待电平释放 } return data; }

这段代码逻辑上没毛病，但实际用的时候有一个很大的坑：延时函数必须足够精确。用延时循环Delay_us(30)的时候，编译器优化等级不同、主频不同，实际延时时间差很多，可能变成50μs甚至80μs，读回来的数据就是错乱的。所以我自己写的时候，直接用SysTick做us级延时，保证延迟精度在±2μs以内，再关掉可能干扰时序的中断。

另外，DHT11的采样间隔要求大于1秒，意思是从主机发送起始信号到下一次发送起始信号，中间至少间隔1秒。如果读取频率太高，传感器不响应，返回的数据全是高温高湿的乱码，这个很容易误判成传感器坏了。注意读完之后把数据线拉高，让总线保持空闲状态，否则下一次读取也会失败。

3.3 风扇PWM调速：定时器配置和温度映射策略

PWM输出用STM32的定时器，我用的是TIM3通道1，选择PA6引脚。定时器配置的核心是确定频率和占空比。频率太高，MOS管和三极管的开关损耗变大；频率太低，风扇会发出明显的“嗡嗡”声。我的经验是5kHz到25kHz之间都可以，耳朵几乎听不到噪音，我最终选了10kHz。计算方法：72MHz主频分频后得到想要的频率，(PSC+1) × (ARR+1) = 72MHz / 10kHz = 7200，所以取PSC=71，ARR=99，即72MHz / 72 / 100 = 10kHz。

定时器初始化代码：

TIM_TimeBaseInitTypeDef TIM_TimeBaseStructure; TIM_OCInitTypeDef TIM_OCInitStructure; RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM3, ENABLE); TIM_TimeBaseStructure.TIM_Period = 99; // ARR = 99 TIM_TimeBaseStructure.TIM_Prescaler = 71; // PSC = 71 -> 10kHz TIM_TimeBaseStructure.TIM_ClockDivision = 0; TIM_TimeBaseStructure.TIM_CounterMode = TIM_CounterMode_Up; TIM_TimeBaseInit(TIM3, &TIM_TimeBaseStructure); TIM_OCInitStructure.TIM_OCMode = TIM_OCMode_PWM1; TIM_OCInitStructure.TIM_OutputState = TIM_OutputState_Enable; TIM_OCInitStructure.TIM_Pulse = 0; // CCR初始为0，占空比0% TIM_OCInitStructure.TIM_OCPolarity = TIM_OCPolarity_High; TIM_OC1Init(TIM3, &TIM_OCInitStructure); TIM_OC1PreloadConfig(TIM3, TIM_OCPreload_Enable); TIM_Cmd(TIM3, ENABLE);

调节占空比就是修改CCR寄存器的值，CCR=0对应占空比0%，CCR=99对应100%。温度到占空比的映射我用分段线性方案：25℃以下占空比0（风扇停），25℃到40℃之间线性从30%升到100%，40℃以上全速。这个区间设置可以根据实际场景改，比如散热要求高的设备可以把25℃下调到20℃。核心代码：

#define TEMP_BASE 25.0f #define TEMP_FULL 40.0f #define DUTY_MIN 300 // 对应30% #define DUTY_MAX 999 // 对应99.9% uint16_t TempToDuty(float temp) { if (temp <= TEMP_BASE) return 0; else if (temp >= TEMP_FULL) return DUTY_MAX; else return (uint16_t)((temp - TEMP_BASE) / (TEMP_FULL - TEMP_BASE) * (DUTY_MAX - DUTY_MIN) + DUTY_MIN); }

这里有个细节：ARR设成99，CCR最大只能到99，30%对应30，100%对应99。如果我想让占空比精度高一点，会把ARR设成999，CCR范围0~999。代码里DUTY_MAX我写了999，意味着实际用的时候ARR应该设成999，PSC重新计算让频率保持在10kHz附近。这个细节在源码里要注意，不然初始化配置和占空比计算会对不上。

再一个必须处理的问题：滞回。假设没有滞回，温度正好卡在25℃附近，风扇会一会儿转一会儿停，非常烦。我加了一个简单的滞回逻辑：开启阈值30℃，关闭阈值28℃，温度升到30℃以上风扇启动，之后要降到28℃以下风扇才停，中间保持上一次状态。这样既保证了响应速度，又不会频繁启停。

#define FAN_ON_TEMP 30.0f #define FAN_OFF_TEMP 28.0f static uint8_t fan_run = 0; if (temp > FAN_ON_TEMP) fan_run = 1; else if (temp < FAN_OFF_TEMP) fan_run = 0; if (fan_run) PWM_SetDuty(TempToDuty(temp)); else PWM_SetDuty(0);

3.4 按键交互和OLED显示状态机

按键我用三个独立按键：模式切换键、加键、减键。模式逻辑是：短按模式键在“自动模式”和“手动模式”之间切换；手动模式下，加键和减键调节目标PWM占空比，步进5%；长按模式键进入“参数设置模式”，可以设置报警阈值。参数设置模式里OLED显示内容变化，加键和减键变成调阈值。

按键处理最大的坑是抖动。机械按键按下和释放的瞬间，会产生几毫秒到几十毫秒的电平抖动，不去抖动的话一次按键会被识别成好几次，参数乱跳。我用了最简单的延时消抖：检测到低电平后延时20ms，再确认一次还是低电平，才认为是有效按下。注意延时消抖期间要避免阻塞太久，20ms在项目里可以接受，不影响其他任务。

OLED显示用SSD1306的I2C接口，地址0x3C。显示内容分两屏：第一屏显示实时温度、湿度、当前模式、PWM占空比；第二屏显示报警阈值和温度曲线趋势。OLED刷新不要在主循环里每圈都全量刷新，那样会占用很多时间且屏幕闪烁，我是每150ms刷新一次，够用也不晃眼。这里也提示一下：STM32F103的硬件I2C在实际使用中有一些已知的兼容性问题，偶尔会卡在BUSY状态出不来，如果遇到OLED一直无响应，可以改用软件模拟I2C，稳定很多。我在这套代码里就是用的软件I2C，省心。

4. Proximity仿真搭建与整体调试：从Proteus到实物的落差

4.1 Proteus仿真环境搭建步骤

Proteus仿真最大的价值在于：在没有硬件的情况下，把整个程序的逻辑跑通一遍，尤其是状态切换、PWM输出、按键响应这些行为层面的验证。我用的Proteus 8.x版本，搭建步骤如下。

第一步，新建工程，在元件库搜索并放置STM32F103C8T6、DHT11、LCD/OLED（如果你想让仿真贴近实物，Proteus里有OLED模型）、按键、电阻、风扇模型（或者用一个LED加示波器代替）。第二步，连接电路：STM32的PA6接风扇控制引脚，PD0接DHT11数据线，加上拉电阻，PD1接OLED SDA，PD2接OLED SCL。第三步，编译工程生成hex文件，在Proteus里双击STM32芯片，找到Program File选项，加载hex文件，同时把Crystal Frequency设置成8MHz。第四步，点击运行，如果一切正常，虚拟OLED屏幕开始显示，温度改变时PWM输出变化。

DHT11模型在Proteus里的使用方式和实物不太一样。真实DHT11需要时序精确调用，Proteus的模型也模拟了单总线时序，但它在仿真中读取温度和湿度是靠元件属性设置的。你可以在仿真里双击DHT11，修改它的Temperature和Humidity属性来模拟环境变化，观察风扇转速是否按预期变化。如果模型属性改不了，一个替代办法是用数字电位器或者按键调节模拟量，再用ADC通道采集，临时验证“采集→处理→输出”的链路。两种方式都能帮助验证主控代码逻辑。

4.2 仿真验证的边界：哪些问题一定要上实物

仿真环境对逻辑验证非常友好，但有几个坑必须提前知道，免得被误导。Proteus仿真默认是理想化的，芯片引脚的GPIO翻转时间、上电时序、电源瞬态都和真实芯片有区别。DHT11在Proteus里是模型，不存在真实传感器的电气噪声和时序抖动，所以你在仿真里跑通的读取代码，拿到实物上不经过调试可能读不到正确数据，这是最典型的“仿真一时爽，实物两行泪”。

另外，Proteus仿真里没有“风扇启动瞬间的大电流“、没有“电源线上的纹波”，也没有“三极管发热”。所以仿真通过不代表硬件一定正常。我个人的调试经验是：仿真负责把算法和逻辑调对，实物负责把驱动和时序调稳，两个阶段缺一不可。这也是为什么我强烈建议先做仿真再做板子，而不是直接焊板子然后边猜边调。

如果不想装Proteus，在线仿真平台Wokwi也是一个选择，它对STM32F103有实验性支持，可以在浏览器里写代码、接电路、看串口输出，适合快速验证想法，但支持的元件库和模型丰富度目前还比不上Proteus。

4.3 实物调试三步走

拿到打样的板子或者面包板搭好电路之后，我的调试习惯是分三步，绝不一步到位直接跑完整程序。

第一步，最小系统点灯。只烧一个GPIO翻转的程序，用LED验证芯片能跑起来，顺便确认下载器和烧录链路没问题。这一步很多初学者跳过了，结果后面程序没反应，分不清是芯片没烧进去还是外设没工作，浪费时间。

第二步，单独测DHT11。写一个最简单的串口打印程序，只读温湿度，通过串口助手观察数值是否合理。这时候如果读到0或乱码，重点查上拉电阻、GPIO配置、时序延时。DHT11在正常室温下读到温度20多度、湿度40%~60%都算合理，读到55℃、湿度99%这种极端值，基本可以断定通信有问题。

第三步，再接PWM驱动和风扇。用固定占空比测试，比如先写死CCR=500（约50%占空比），看风扇是否转、转速是否稳定。这时候要重点观察：风扇启动时声音是否正常、有没有异味、震动大不大。固定占空比能跑通再上自动调速逻辑，否则温度一变风扇就乱转，很难定位是测温问题还是驱动问题。

5. 常见问题与排查技巧实录

5.1 烧录和环境类问题

报错“No STM32 target found”是出现频率最高的问题之一。这个报错说明ST-Link没有和芯片建立连接。排查顺序从硬件到软件：先检查ST-Link的SWDIO、SWCLK、GND三根线是不是真的接到了芯片对应引脚，很多是杜邦线松了；再确认芯片供电是否正常，3.3V引脚能测到电压，芯片不能过热；然后看BOOT0有没有被拉高，如果BOOT0是1，芯片进入系统存储器模式，SWD连接不一定会失败，但有时会被干扰，拉回0更稳；最后检查ST-Link驱动是否正常，Windows设备管理器里看到“STM32 Virtual COM Port”感叹号这类情况，重装ST-Link驱动即可。还有一个容易忽略的点：如果板子上有电解电容极性接反，会导致整个电源系统异常，ST-Link也无法连接。

如果用的是最小系统板，经常遇到“能识别到芯片但下载提示Flash时代不支持”或者干脆连接超时。这种情况下先确认MDK工具里的Flash Download选项是否选对了芯片容量，STM32F103C8T6是64KB Flash，选错成512KB的型号下载会失败。

5.2 传感器读数和显示问题

DHT11读回来的数据一直是0或者是固定值，首先要怀疑通信时序。用逻辑分析仪抓一下数据线波形，看起始信号是否发出、DHT11是否有80μs的响应低电平，如果没有响应，大概率是传感器供电或上拉电阻问题。如果响应了但数据全是0，那就是读取延时不准确，把us级延时函数校准一遍。注意用SysTick做完延时之后，读单字节时中断优先级要控制好，避免在时序关键点被定时器中断打断。

温度跳变特别大，比如一会25℃一会60℃回来，除了传感器本身故障外，还可能是传感器位置离热源太近，或者被风扇吹到出风口。DHT11外壳有一定热惯性，放在出风口附近会受到风扇气流影响，测到的温度和真实环境温度不一致。解决办法是把传感器放在进风口或者远离风扇的位置。

OLED花屏或完全不显示，先量I2C地址是不是0x3C，再查SCL和SDA是否接反，最后确认上拉电阻。SSD1306的板子有的自带I2C上拉，有的没有，外部加上4.7kΩ上拉比较稳。软件I2C一般不会有硬件I2C的BUSY卡死问题，但延时不能太短，I2C时钟频率控制在100kHz~400kHz，软件延时循环如果太快，OLED也会不按章法出字符。

5.3 风扇驱动和电源问题

风扇不转，但是万用表量ST-Link输出的PWM引脚有波形，问题往往出在驱动级。先用示波器看三极管基极的电压波形，正常应该在0和3.3V之间切换；再看集电极波形，关断时电压会冲到接近电源电压，如果有尖峰到十几伏但没烧管，说明续流二极管正常工作。风扇“嗡嗡”响但转不起来，是典型的启动电压不够。有些风扇电机在低速占空比下启动困难，解决办法是启动时给一个全速脉冲（比如占空比100%持续200ms），然后再回落到目标转速。

另一个我踩过的坑是风扇正负极接反。无刷散热风扇内部有驱动电路，接反了不会反转，而是根本不转，有的会烧内部元件。接线前一定看风扇标签上的红黑线定义。

电源问题最典型的是“一开风扇单片机就复位”。原因基本是风扇启动瞬间电流把3.3V电压拉垮了。检查风扇是否接在LDO前面，如果接在3.3V输出端，立刻改接；同时在5V入口加大电容。如果还复位，考虑在STM32的VDD引脚再加一个100μF电容，给芯片提供一个瞬间的能量缓冲。

5.4 排查速查表

这套排查思路不仅适用于这个温控风扇，几乎所有“单片机+传感器+电机”的项目都可以套用。先隔离问题：软件层查波形，功率层量电压，电源层抓纹波，不要一上来就怀疑芯片坏了。芯片坏的几率远远低于接线错、配置错。

最后再分享一个小经验。这个项目做完之后，我把它重新整理开源，不只是扔一堆代码文件了事，而是把硬件设计说明、仿真使用步骤、常见问题都写成文档放进仓库。很多人会把开源简单理解成“挂代码”，但实际上代码之外的设计思路和踩坑记录才是最大的财富。后来有网友拿这套架构改成了鱼缸温度控制，用加热棒替代风扇，加热逻辑和降温逻辑本质上是同一个问题，只是执行器从风扇换成了加热棒，PWM控制从调转速变成调加热功率。这也印证了这个项目的价值：核心在于“传感器采集→数据处理→执行器控制”的完整闭环，把这个框架吃透，后面无论做智能家居、小型设备散热，还是温度控制类产品，都能很快上手。