STM32智能移动加湿器设计：原理图、源程序与调参实战

简介：基于STM32单片机的智能移动加湿器设计资料，面向嵌入式初学者与物联网应用开发者，提供从硬件原理图到软件源程序的完整参考方案。项目以STM32为核心，融合温湿度传感器采集、PID湿度调节、移动供电、Wi-Fi/蓝牙远程操控等典型功能；硬件原理图涵盖电源电路、最小系统、传感器接口与雾化器驱动电路，软件源程序则包含底层驱动、控制逻辑与上层人机交互设计，同时兼顾LCD显示、按键操作及防干烧等安全措施，便于理解智能硬件从硬件到软件的全流程实现。压缩包共214个文件，以C/H源程序、uvprojx工程文件、原理图pcbdoc、hex固件及PNG图片为主，整体833KB，目录按模块划分清晰，易于定位与复用。资料内附完整可编译的工程与烧录固件，可直接导入进行二次开发。已有2207人学习/浏览，适合希望系统掌握STM32编程、传感器应用、物联网通信及硬件电路设计的开发者深入学习与二次开发。

1. 从桌面加湿器到移动加湿器：为什么非要用 STM32

把加湿器加上“移动”二字，意味着它不再是插着墙电、放在桌角固定出雾的定频设备，而是一个带有底盘电机、电源管理、传感器融合和小型控制系统的机电一体化产品。这类设计出现在智能家居课程设计、电子竞赛和产品预研里，核心价值是能用一套硬件同时处理“环境感知—运动决策—执行驱动”三个环节，而这恰好是 8 位单片机比较吃力的场景。STM32 在这类项目里成为主流选择，并不是因为它比 51 更“高级”，而是因为它的定时器资源、ADC 通道数、DMA 和硬件 I2C/UART 能让加湿器同时兼顾传感器轮询、电机调速和雾化片驱动，而不用靠频繁中断把 CPU 占满。

一个典型的智能移动加湿器，硬件上由 STM32F103C8T6 最小系统、DHT11 或 SHT30 温湿度传感器、水位检测、L298N 或 TB6612 电机驱动、超声波雾化片或继电器控制的加热式加湿模块、锂电池充放电管理组成。软件上则要处理 PID 调速、低水位保护、遥控或按键状态机切换。本文会从原理图怎么画、源程序怎么组织、参数怎么调三个角度，把一套可以在开发板上复现的完整方案拆开讲，重点放在“哪些地方看起来简单、实际会反直觉”的细节上。

这套资料的受众很明确：正在做 STM32 课程设计或毕业设计的学生、想把桌面加湿器改成自动巡航版本的产品爱好者，以及需要快速评估方案可行性的硬件工程师。如果你手里已经有一块 STM32F103C8T6 最小系统板和几个常见模块，那么本文涉及的电路和代码可以直接挪用，不需要额外购买专用开发板。

2. 原理图设计：围绕 STM32F103C8T6 搭建加湿器主控电路

2.1 最小系统原理图的关键节点：晶振、复位、Boot 引脚

STM32F103C8T6 的最小系统原理图是所有外设电路的基础。很多同学直接复制网上的最小系统图，结果晶振不起振或下载不了程序，问题往往出在负载电容的取值上。常见的做法是使用 8MHz 晶振并联两个 22pF 电容，但要注意 STM32F103 内部谐振电路对负载电容 CL 的匹配范围是 12pF 到 20pF 之间。具体计算公式是 CL = (C1 × C2) / (C1 + C2) + 寄生电容，其中寄生电容通常估算为 3pF 到 5pF。以 22pF 并联为例，得到的实际负载电容大约是 11pF + 4pF = 15pF，落在推荐范围内。如果是手工焊接，建议直接选用 12pF 电容，因为焊接引脚的寄生电容会让实测频率偏低。

除了晶振，复位电路和 Boot 引脚设置也容易踩坑。STM32F103 的 NRST 引脚内部已有上拉电阻，外部只需接一个 0.1uF 电容到地即可。但如果你在原理图上画了按键复位，必须串联一个 100Ω 左右的电阻再接 NRST，避免按键按下瞬间产生过冲损坏芯片。Boot0 和 Boot1 引脚建议各接一个 10kΩ 下拉电阻，确保默认从主闪存启动。如果 Boot0 悬空，有些板卡会因为引脚噪声导致偶尔无法正常运行。还有一点是 VCAP 引脚，STM32F103 的 VCAP 需要外接一个 2.2uF 钽电容或陶瓷电容到地，这个电容容量选小了会直接导致芯片复位不稳定或运行中死机。

2.1.1 供电树设计：3.3V 模拟与数字分区

加湿器系统里同时存在模拟电路（水位传感器、温湿度传感器输出）和数字电路（单片机、电机驱动逻辑），如果共用一个 3.3V LDO 而不做滤波分区，ADC 采样值会随电机启停跳动 20 到 50 个 LSB。建议使用 AMS1117-3.3 作为主电源，输出端用 10uF + 0.1uF 电容组合滤波，然后通过磁珠或 10Ω 电阻将 3.3V 分割成 VCC_D 和 VCC_A 两个网络，分别给数字和模拟部分供电。ADC 的参考电压 VREF+ 直接接 VCC_A，并在 VREF+ 引脚旁边放一个 1uF 电容。

电源输入端必须加防反接和过流保护。移动加湿器使用锂电池供电时，典型方案是先用 DW01 保护 IC + 8205A 双 MOS 管做过充过放保护，再经过 ME2188 或 HT7333 这类低压差 LDO 输出 3.3V。不要直接把锂电池正极接到 AMS1117 输入端，因为锂电池最高电压 4.2V，而 AMS1117 的压差在输出 3.3V 时需要至少 1V 余量，输入低于 4.3V 时输出就会跌落。低压差 LDO 在 3.6V 输入时仍能稳定输出 3.3V。同时，电机驱动电源和单片机电源要分开布线，L298N 的 12V 或 5V 供电线走短粗路径，不要与传感器信号线平行布线超过 2cm，否则电机 PWM 切换时的 di/dt 会耦合进信号回路导致传感器误触发。

2.2 传感器与执行器接口电路：DHT11、水位、电机驱动、雾化片

温湿度传感器 DHT11 在原理图上只需要一个上拉电阻，典型值是 4.7kΩ 到 10kΩ。不过这里有一个常见的原理图错误：有人把上拉电阻接到 3.3V，但 DHT11 的 VCC 也接 3.3V，看起来没问题，实际却因为 DHT11 的 IO 输出高电平是 VCC-0.3V，而 STM32 的 GPIO 输入高电平阈值是 0.7 × 3.3V（约 2.31V），3.0V 的高电平确实能识别，但噪声裕量只剩 0.7V。如果加湿器底盘电机转动产生电磁干扰，数据线就容易误码。最稳妥的接法是 DHT11 VCC 接 5V，上拉电阻接 3.3V，这样 IO 高电平约 4.7V，STM32 识别毫无压力。如果传感器模块板上已经自带 5V 上拉，那就直接接 5V 兼容输入。

水位检测有两种常用方案：电极式和水位传感器（如 XKC-Y25 非接触式）。电极式原理简单，利用水的导电性短接两根探针，原理图上是两个引脚之间接一个 1MΩ 上拉电阻，当水漫过探针时 IO 被拉低。这种方案成本极低，但探针在自来水或纯净水中长时间使用会电解，建议将探针驱动电流限制在 1mA 以内，即串联一个 3.3kΩ 电阻。XKC-Y25 是 NPN 常开输出，模块通电后无水位时输出高阻，有水时输出低电平，原理图里只需在输出脚接一个 4.7kΩ 上拉到 VCC，然后直接进 STM32 GPIO，不需要额外放大电路。

电机驱动部分，L298N 的 IN1/IN2/ENA 等引脚不能直接接 STM32 的 GPIO。STM32F103 单个 GPIO 最大输出电流约 25mA，而 L298N 的逻辑输入需要大约 20mA 驱动电流，直接驱动会导致 GPIO 电压被拉低到 2V 左右，逻辑不稳定。正确接法是 GPIO → 74HC245 缓冲器 → L298N，或者直接用 1kΩ 串联电阻后接 L298N 的逻辑输入，但需要将 L298N 的 VSS 接到 5V，同时用 5V 电平转换板做中转。更简单的替代方案是使用 TB6612FNG 模块，它的逻辑输入电流只需 0.1mA，可以直接接 STM32 GPIO，且效率比 L298N 高 20% 左右，适合电池供电的移动应用。

雾化片驱动是加湿器区别于其他移动机器人的核心。超声波雾化片需要大约 110kHz 的交流驱动信号，原理图上不能直接使用 STM32 的 PWM 输出驱动，因为功率不够且信号不是正弦波。常见做法是使用专用雾化片驱动 IC，如 ZD2412 或 EK-03 模块，STM32 只需用 GPIO 控制 MOS 管的栅极或 IC 的 EN 引脚，实现雾化开启和关闭。如果要在原理图上自己搭振荡电路，可以选用三极管 8050 和 8550 组成的推挽震荡电路，配合电感 L1（22uH）和电容 C1（102/2kV）并联谐振在超声频率上。需要注意：雾化片不能无水空转，否则会烧毁压电陶瓷片，设计上必须把水位检测信号和雾化片使能信号做硬件联动。原理图上可以使用一个 NPN 三极管做与门，只有水位检测输出高电平（表示有水）时，单片机控制雾化使能才能导通。如果只靠软件判断，一旦单片机死机或传感器故障，雾化片就会空烧。以下是一个简单的联动电路段：

// 伪代码用于说明电位关系，实际实现见源程序章节 if (GPIO_ReadPin(GPIOB, GPIO_PIN_0) == SET && water_level_flag == 1) { HAL_GPIO_WritePin(GPIOB, GPIO_PIN_1, GPIO_PIN_SET); // 开启雾化使能 } else { HAL_GPIO_WritePin(GPIOB, GPIO_PIN_1, GPIO_PIN_RESET); // 关闭雾化 }

这段逻辑的代码含义是：PB0 引脚读取水位传感器的输出电平，water_level_flag 由 ADC 采集水位电压阈值决定，两个条件同时满足时 PB1 输出高电平去使能雾化驱动。参数上，PB0 接水位传感器数字输出，建议开启内部上拉，PB1 接雾化模块 EN 脚，需要查模块手册确认真实 EN 高电平电压范围，有些雾化模块 EN 是 5V 逻辑。另外一个要点：STM32 的 GPIO 开漏输出加上拉电阻也是可行方案，但开漏模式翻转速度只有推挽模式的 1/3 左右，而雾化 EN 不需要高频切换，所以这个场景可以接受。

2.3 原理图自检清单与常见错误：页码、网络标号、DRC 检查

拿到一份加湿器原理图，直接开始画 PCB 之前，建议花十分钟按以下清单检查一遍。首先看电源网络：3.3V 是否同时出现在模拟和数字区域，VCC_A 和 VCC_D 是否通过磁珠或电阻连接，GND 是否在 ADC 采样点附近单点连接。其次看下载接口：SWDIO/SWCLK 是否加上拉和串联电阻，SWDIO 通常加 10kΩ 上拉到 3.3V，SWCLK 加 100Ω 串联电阻，防止下载线过长时信号反射导致连不上仿真器。

原理图页码设置也是一个被忽视但容易出问题的细节。分页绘制原理图时，不同页面之间的网络连接依赖全局网络标号，但很多 EDA 工具允许不同页使用同名网络标号而实际上并未电气连接，这就是常见的“跨页断裂”问题。在 AD20 或立创 EDA 中，建议把每一页的 Off-Sheet Connector 或全局网络标号统一设置为相同名称，并开启全局网络检查。另外，页面编号重复在多人协作或复制页面时经常发生，可能导致导出的网表在 PCB 导入时报错。检查方法很简单：在原理图编辑器的文档选项里查看所有页面的 Page Number 设置，确保从 1 到 N 连续不重复。这在 AD20 里是“Properties → General → Page Number”，在立创 EDA 里是“图纸设置 → 页码”。

DRC 电气检查至少要关注三类错误：ERC 报告中的 Unconnected Pin、Pin Type Conflict 和 Passive Pin 警告。其中 Pin Type Conflict 在 STM32 最小系统里常见于 BOOT0 引脚，因为 STM32 的 BOOT0 是输入引脚，而复位电路中的电容或按键网络被错误定义为输出类型。L298N 电路也会产生类似的冲突提示，VCC 逻辑输入脚在库文件里被定义为 Passive，接到 STM32 推挽输出的 GPIO 时某些 EDA 会报警告。这不算真正的连接错误，但需要逐个确认不是电源短路。更严重的错误是网络标号拼写错误，比如 3V3 和 3.3V 被当成两个不同网络，DRC 不会自动识别语义相同但名称不同，这会直接导致 PCB 上出现悬空电源引脚。用表格总结一下检查项：

3. 源程序框架与核心驱动：从寄存器到状态机的实现路径

3.1 源程序文件结构与工程配置要点

一套完整的 STM32 加湿器源程序，不应只有一个 main.c 堆功能。比较稳妥的做法是分成以下模块：bsp_dht11.c 温湿度驱动、bsp_motor.c 电机控制、bsp_pump.c 雾化或水泵控制、bsp_adc.c 水位与电池电压采样、app_main.c 状态机与业务逻辑。每个模块包含 .c 和 .h 文件，.h 里只暴露必要的初始化函数和状态读取接口，不暴露全局变量。这样做的好处是当你在原理图里改了引脚映射，只需要修改对应模块的宏定义，不会牵连其他功能。

工程配置上有一个高频坑：使用 Keil5 建立工程时，如果选择了 STM32F103C8 但没有添加启动文件 startup_stm32f103xb.s，程序编译能通过，但下载后没有任何反应。这个启动文件负责初始化堆栈指针、调用 SystemInit 和 main 函数，缺失时程序跑飞。检查方法是在工程文件的 Device 选项卡里确认 Startup 文件是否存在，或者在编译输出信息里看是否包含 startup_stm32f103xb 的目标文件。另外，在魔法棒选项卡的 C/C++ 编译选项里，Define 预处理需要加入 USE_HAL_DRIVER 和 STM32F103xB。如果不定义 STM32F103xB，HAL 库默认按 F103 全系列编译，某些外设寄存器地址会不匹配，虽然编译能过，但运行到 ADC 或定时器初始化时会死机。对于 8MHz 晶振配 72MHz 主频的配置，系统时钟初始化里必须正确设置 PLL 倍频系数为 9，如果配成 12，主频会超频到 96MHz，超过 F103 规格上限，程序可能在连续运行几个小时后随机死机，且极难排查。

3.1.1 使用 STM32CubeMX 快速生成外设初始化代码的取舍

很多用户习惯用 STM32CubeMX 生成初始化代码再补业务逻辑，这种方式适合快速搭框架。在 CubeMX 里需要配置以下引脚：DHT11 数据脚设置为 GPIO_Output 或开漏输出，电机 PWM 脚设置为 TIM2_CH1 和 TIM2_CH2，频率设置为 10kHz 到 20kHz；水位检测脚设置为 GPIO_Input；雾化使能脚设置为 GPIO_Output。时钟树里将 HSE 设为 8MHz，SYSCLK 设为 72MHz。

一个特别容易忽略的参数是 PWM 频率的选择。TB6612 电机驱动的 PWM 频率一般在 10kHz 到 50kHz 之间，频率太高会增大驱动芯片的开关损耗，太低则电机会发出人耳可闻的啸叫声。通常建议先设 20kHz，如果发现电机噪音明显再降到 10kHz 或提高到 30kHz 做对比。雾化片控制不需要 PWM，只需 GPIO 开关，如果使用定时器输出比较模式来驱动雾化片的震荡电路，则需要把频率设定为雾化片的谐振频率（通常 108kHz 到 113kHz），而不是随意设定 PWM 频率。雾化片参数可以在规格书上找到，如果手头只有模块没有规格书，可以通过示波器观察电流波形确定谐振点，没有示波器就用“听”的方法：雾化片出雾量最大且声音最尖锐的频率就是谐振点附近。

3.2 DHT11 时序驱动与数据校验的实现细节

DHT11 的驱动逻辑是这套源程序里最需要精细控制的部分。DHT11 采用单总线协议，通信时序是：主机发送起始信号（拉低至少 18ms），DHT11 响应后拉低 80us，再拉高 80us，然后开始输出 40 位数据。每一位数据的“0”和“1”由高电平持续时间区分，典型值：26us 到 28us 为“0”，70us 为“1”。STM32 的 HAL 库函数在处理这些微妙级信号时如果不小心，很容易读到错误数据。以 HAL_GPIO_ReadPin 加延时函数的实现为例：

uint8_t DHT11_ReadByte(void) { uint8_t data = 0; for (int i = 0; i < 8; i++) { while (HAL_GPIO_ReadPin(DHT11_PORT, DHT11_PIN) == GPIO_PIN_RESET); // 等待低电平结束 delay_us(40); if (HAL_GPIO_ReadPin(DHT11_PORT, DHT11_PIN) == GPIO_PIN_SET) { data |= (0x80 >> i); // 高电平持续超过40us，判为1 } while (HAL_GPIO_ReadPin(DHT11_PORT, DHT11_PIN) == GPIO_PIN_SET); // 等待高电平结束 } return data; }

这段代码的逻辑含义是：每一数据位从低电平开始，先等待低电平结束（约 50us），然后延时 40us 再读引脚。如果此时引脚为高，说明高电平已持续超过 40us，该位判定为“1”，否则为“0”。参数上，40us 这个阈值是由 DHT11 时序规范推导出来的：“0”的高电平最大持续 28us，“1”的最小持续 68us，40us 正好是两者的中间值。如果环境温度很低（低于 0℃），DHT11 的电气特性会变化，此时可能需要把阈值调整到 35us。另一个问题是 DHT11 两次读取之间必须间隔至少 1 秒，否则传感器会输出上一次的缓存数据，这不是 bug 而是器件规格。在移动加湿器应用里，1 秒的采样间隔完全足够，因为湿度变化本身是个缓慢过程。如果项目中湿度显示读数频繁跳变，先检查读取间隔是否小于 1 秒，不要急着给数据加滤波。

DHT11 的 40 位数据由 8 位湿度整数、8 位湿度小数、8 位温度整数、8 位温度小数和 8 位校验和组成。校验和应等于前四个字节之和的低 8 位。校验失败的处理策略在新手代码里往往是“丢弃数据”，但更稳妥的方式是保留上一次有效数据并重试读取。加湿器控制不需要实时性极高的湿度值，即使连续两次校验失败，也不应该让系统进入死循环等待。正确的做法是设置一个读取失败计数器，连续失败超过 10 次就将湿度值强制置为 0，同时关闭加湿执行器和运动电机，进入安全保护模式。这样设计的原因是：DHT11 数据线开路或短路时，系统必须能自动降级而不是卡死在 while 循环里。

3.3 状态机与低水位保护：让加湿器动作有序可预期

移动加湿器的行为逻辑建议用状态机而不是顺序执行。状态划分至少包括：IDLE（待机）、HUMIDIFYING（加湿中）、MOVING（巡航移动）、LOW_WATER（低水位保护）和 CHARGING（充电中）。状态与状态之间通过事件跳转，事件包括：按键按下、湿度低于阈值、水位检测脚变低、充电器插入等。用 switch-case 实现即可，不需要引入操作系统。

低水位保护是整个智能移动加湿器源程序中最关键的逻辑。加湿器在水位不足时如果继续让雾化片工作，会导致雾化片干烧损坏，同时水泵空转也会烧毁电机。在程序里，低水位检测不能只靠单次 ADC 采样判断，因为水面的晃动会导致水位探针接触电阻波动，ADC 读数可能瞬间跳到阈值以上。正确的做法是连续采样 10 次，中间间隔 50ms，如果 10 次中有 8 次低于阈值，才确认进入低水位状态。以下是一个带消抖和滞回的低水位检测函数：

#define WATER_THRESHOLD_LOW 1800 // 低水位阈值，对应ADC值 #define WATER_THRESHOLD_HIGH 2000 // 高水位阈值，滞回区间 uint8_t WaterLevel_Check(void) { uint32_t sum = 0; uint16_t sample = 0; for (uint8_t i = 0; i < 10; i++) { HAL_ADC_Start(&hadc1); if (HAL_ADC_PollForConversion(&hadc1, 100) == HAL_OK) { sample = HAL_ADC_GetValue(&hadc1); } sum += sample; HAL_Delay(50); } uint16_t avg = sum / 10; if (avg < WATER_THRESHOLD_LOW) { return WATER_LEVEL_LOW; } else if (avg > WATER_THRESHOLD_HIGH) { return WATER_LEVEL_OK; } return water_level_last_state; // 滞回区间内保持上次状态 }

这段代码的逻辑是：ADC1 连续采样 10 次取平均，平均值低于 LOW 阈值判定为缺水，高于 HIGH 阈值判定为有水，中间 1800 到 2000 的区间是滞回区，保持上一次状态。参数 WATER_THRESHOLD_LOW 的设定依据是：STM32F103 的 ADC 是 12 位，参考电压 3.3V，水位传感器输出电压随水位升高而升高。当水位低时典型输出 1.0V，对应 ADC 值约 1000 / 4096 × 3.3V = 0.8V；当水位正常时输出 2.2V，对应 ADC 值约 2730。把 LOW 设为 1800（对应 1.45V）可以避免传感器在两种状态边界处的抖动。滞回区间宽度应至少是 ADC 噪声幅度的 5 倍，一般取 200 左右即可。注意 HAL_ADC_PollForConversion 的超时参数设置为 100ms，如果超过 100ms 没有转换完成，说明 ADC 外设异常，需要返回错误而不是继续执行。

3.4 电机调速与加湿量联动：PWM 参数与电池电压补偿

移动加湿器的运动控制并不需要复杂的闭环 PID，开环 PWM 调速即可满足需求。但对 PWM 和相关定时器参数的设置要清楚。TIM2 的时钟来自 APB1 定时器时钟，72MHz。要得到 20kHz 的 PWM，需要设置 Prescaler 为 0（不分频）， Period 为 3600，即 72MHz / (0+1) / (3600+1) ≈ 20kHz。占空比 50% 即 CCR1 = 1800。关键点在于 Period 的值减 1 和加 1 的区别：STM32 定时器的自动重装寄存器 ARR 和比较寄存器 CCR 都是在计数值等于设定值时触发，所以实际周期是 Period + 1 个计数单位。如果你在 CubeMX 里设置 Period 为 3599（实际周期 3600），代码注释里要注意别搞混。

电池电压对 PWM 占空比的影响经常被忽略。移动加湿器用锂电池供电时，电池电压从 4.2V 到 3.6V 变化范围约 15%。如果 PWM 占空比固定，电机转速会随电压下降而降低，加湿器的巡航速度越来越慢。更合理的做法是通过 ADC 采集电池电压，然后对 PWM 占空比做补偿。例如目标占空比 60%，电池电压 4.0V 时实际输出 2.4V；当电池电压降到 3.7V 时，将占空比提高到 65% 来维持相同的电机电压。补偿公式可以简化为：compensated_duty = base_duty × (3.7 / battery_voltage)，限制在 0% 到 95% 之间，留出 5% 余量防止占空比饱和。这样实现简单，不需要电流环，适合低成本移动加湿器场景。可以增加一个表格来对比不同电压下的补偿系数：

ADC 采样值 = 电压 / 3.3 × 4096。补偿系数 = 3.7 / 当前电压，3.7 是选取的基准电压。实际配置时，每 100ms 读一次电池电压并更新占空比，不需要更频繁，因为热惯性会让慢速变化成为主体特征。

4. 源程序缺陷排查与误用排除：从 Keil5 编译警告到运行期死机

4.1 Keil5 中 STM32F103C8 与 C51 工程的共存问题

Keil5 默认支持 ARM 编译器，但很多用户会同时安装 C51 的扩展包，如果安装顺序不对，工程目标设备里找不到 STM32F103C8，或者编译时报“Target not created”错误。常见原因是 Keil5 的 Pack Installer 里没有勾选 Keil::STM32F1xx_DFP 设备支持包。解决方法是打开 Pack Installer，在 Packs 选项卡下找到 STM32F1xx_DFP，点击 Install。安装后需要重启 Keil5，然后在 Device 对话框里就能看到 STM32F103C8。如果没有网络安装包，可以手动下载 STM32F1xx_DFP 的离线包（.pack 文件）双击导入。

另一个容易混淆的问题是 Keil5 中同一个 IDE 同时装 C51 和 ARM 编译器时，工具栏会多出一个“选目标”的下拉框。如果同时打开了 51 和 STM32 两个工程，编译命令会误用上一次的编译器。排查方法是在 Options for Target 的 Target 选项卡里查看 ARM 编译器版本是否显示为 “Use default compiler version 5” 或类似选项，如果显示为 C51 的编译器，则编译会报大量语法错误。把两个工程放在不同的文件夹，并为每个工程单独创建 Keil 工程文件（.uvprojx），不要在同一个工程里混合 51 和 ARM 源文件。更彻底的方案是使用 VSCode 搭配 EIDE 插件管理工程，通过 CMake 构建，这样能彻底规避 Keil5 的 51/ARM 共存冲突。

4.1.1 编译警告里哪些能忽略、哪些必须解决

STM32 加湿器工程在 Keil5 中常见的警告有：warning: #1-D: last line of file ends without a newline、warning: #68-D: integer conversion resulted in a change of sign和warning: #177-D: function "xxx" was declared but never referenced。第一种是文件末尾没有换行符，不影响功能但建议加上，避免某些工具链在处理时产生不可预期的行为。第二种发生在 ADC 采样值和阈值比较时，例如uint16_t avg与WATER_THRESHOLD_LOW（定义为 1800）比较没问题，但如果把 avg 赋给int8_t变量就会产生符号转换警告，此时应该检查数据类型是否选对，不解决的话可能导致后续判断逻辑错误。第三种是写了函数但没有调用，常见于调试过程中注释掉了某些功能，可以在调试完成后删除或注释掉。

真正必须解决的警告是error: L6220E: Region RAM overflowed with stack，这说明栈空间不够。F103C8 的 SRAM 只有 20KB，如果在工程里开启了较大的全局数组（例如液晶屏显存 1KB × 4 或用于存放温湿度历史条目的数组），再加上 HAL 库的默认堆栈配置 512 字节，很容易溢出。解决方案是打开启动文件的 Stack_Size 和 Heap_Size 定义，将 Stack_Size 从 0x400 改到 0x800，Heap_Size 从 0x200 改到 0x400。但要注意不能无限加大，因为 SRAM 总量固定，加大栈就会减少全局变量可用空间。另一个做法是在工程设置里勾选 Use MicroLIB。MicroLIB 是一个精简的 C 运行库，能减少约 2KB 的 RAM 占用，代价是某些标准库函数（如 printf 的浮点支持）会被裁剪。

4.2 运行期死机与复位循环的三种典型场景

程序下载后反复复位，仿真器能连上但运行到某个函数就跑飞，这种问题在加湿器项目里最常见的原因有三种。

第一种是 ADC 采样死锁。HAL_ADC_PollForConversion 的超时参数如果设成 HAL_MAX_DELAY，而 ADC 外设因为引脚冲突无法完成转换，程序会永远停在轮询循环里。这不是真正的死机，但能在仿真器里看到 PC 指针停在一个固定地址。排查方法是在线仿真时暂停，看当前停在哪个函数。如果是 HAL_ADC_PollForConversion，就需要检查 ADC 引脚是否被复用冲突（比如 PB1 同时配置为 ADC_IN9 和 TIM2_CH2 PWM 输出）。F103 的引脚复用不是任意选择的，同一时间一个引脚只能复用一种外设，必须在 GPIO_Init 的 Alternate 参数里指定正确的外设。

第二种是 I2C 或 UART 通信挂死。如果加湿器外接 OLED 显示屏或通过 UART 与蓝牙模块通信，而对方设备没上电或接线松动，I2C 的 SCL 和 SDA 可能被拉低，导致 HAL_I2C_Mem_Write 函数发送地址后等待 ACK 超时。处理方式是给 HAL_I2C_Init 的时序参数设置严格超时，例如将 I2C 超时设为 100ms，超时后返回 HAL_ERROR 并重新初始化 I2C。不要使用阻塞式的无限等待，否则任何单点故障都会让整个加湿器停止工作。

第三种是看门狗误触发。如果启用了 IWDG 独立看门狗，而主循环的喂狗操作在某个状态机分支里遗漏了，系统会周期性复位。加湿器状态机里 LOW_WATER 状态和 CHARGING 状态最容易忘记喂狗。一个稳妥做法是单独开一个定时器中断，比如 TIM6 中断 100ms 触发一次调用 HAL_IWDG_Refresh，这样喂狗不依赖主循环的分支覆盖。

4.3 输出波形检查：用逻辑分析仪或示波器验证 PWM 和时序

软件调试进行到一定程度后，必须用硬件手段验证 PWM 和 DHT11 时序是否正确，否则参数设错了只会表现为电机转速偏低或湿度读数偶尔出错。逻辑分析仪的价格已经很便宜，对于 20kHz 的 PWM 和 DHT11 的单总线信号，采样率 20MHz 以上的逻辑分析仪足够用。

检查 PWM 输出时，将探头接在 STM32 定时器输出引脚上，观察频率和占空比。一个小技巧：不要只测占空比 50% 的情况，要设置占空比为较低的 10%，此时能明显看到极性错误（高有效还是低有效）带来的区别。如果 TB6612 的 PWM 输入极性设定为高有效，而实际上输出配置成了低有效，电机在 20% 的指令占空比下实际转速会是反向 80%，轻则转速与预期相反，重则撞到障碍物。逻辑分析仪可以直接解码 PWM 的占空比数值，与代码里写的 CCR/ARR 值对比。如果偏差超过 1%，检查时钟树是否正确，比如 APB1 定时器时钟是否误配置为 36MHz 而不是 72MHz。

DHT11 的时序检查比较特殊，需要用逻辑分析仪的单总线协议分析功能。如果逻辑分析仪没有现成的 DHT11 解码器，就手动数高电平宽度。看波形时重点观察高电平脉冲持续时间是否为 26us 和 70us 两档。如果你发现所有脉冲都在 50us 左右，说明传感器的时序和你的延时函数有偏差，通常是系统主频不是 72MHz 导致延时偏长或偏短。将延时函数改用定时器微秒级延时或者直接调用 HAL_Delay 的微秒变体，可以规避主频不对的影响。没有逻辑分析仪时，用示波器也可以，但效率低一些，至少能看频率是否正确。如果 PWM 频率完全不对（比如 20kHz 的设置了实际输出 2kHz），检查 ARR 是否填的是计数器最大值加 1，这是 ARM 定时器普遍的“从 0 计数到 ARR，然后返回到 0”机制带来的常见误解。

5. 调参与验证：在真机上加湿器里确认每一路信号

5.1 使用标准库与 HAL 库的混用建议：减少新手踩坑面积

STM32 开发有标准外设库（StdPeriph）和 HAL 库两个体系，你在网上找到的加湿器源程序可能用的是标准库，也可能用 HAL 库。如果完全看不懂 HAL 库的结构，强行修改会带来不可预期的编译错误。建议的做法是：在同一个工程里尽量只使用一种库，不要混用。比如 GPIO 的读写，如果你在用 HAL 库，就不要在中断回调里调用标准库的 GPIO_ReadInputDataBit。混用最容易出的问题在时钟使能上，HAL 库的 __HAL_RCC_GPIOA_CLK_ENABLE() 和标准库的 RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA) 虽然都能打开 GPIOA 时钟，但在某些情况下 HAL 库的时钟恢复逻辑会与标准库冲突。从可维护性角度，建议以 HAL 库为主，因为 CubeMX 生成的初始化代码可以直接复用。

工程里源文件的包含路径也要注意。.h 头文件如果散落在不同文件夹，Keil 编译报找不到文件，一般是在 Options for Target 的 C/C++ 选项卡的 Include Paths 里没有添加对应路径。STM32F1xx_HAL_Driver 的 Inc 文件夹、CMSIS 的 Include 文件夹、自己写的 bsp 文件夹都要加进去。如果报重复定义，那多半是同一个 .h 文件被包含了两次且没有定义头文件保护宏。可以在每个头文件头部加#ifndef __DHT11_H和#define __DHT11_H，并在文件末尾加#endif。

5.2 真机调试步骤：按顺序验证电源、时钟、传感器、执行器

硬件接线完成后不建议直接下载程序跑完整逻辑，而是按以下顺序分块验证。第一步检查电源：用万用表测 3.3V 和 5V，记录实测值。如果 3.3V 实测只有 3.15V，且 STM32 芯片表面明显发烫，可能是引脚接反导致内部 LDO 过流，此时应立即断电检查。第二步烧录一个最小程序，让板载 LED 以 1Hz 频率闪烁。这能验证晶振是否起振、启动文件是否配置正确、下载器连接是否稳定。如果 LED 不闪，先用示波器看 8MHz 晶振引脚是否有正弦波形，没有波形就是晶振电路故障，多半是电容计算错误或晶振本身虚焊。

第三步单独测试 DHT11。写一个只读取温湿度并通过串口打印的测试程序，波特率 115200，打开串口助手观察输出。正常情况下 1 秒输出一组数据，温度和湿度值稳定在合理范围。如果输出为 0，大概率是上拉电阻没接或 DHT11 数据脚接错。如果数据偶发错误，先检查上拉电阻是否过大（大于 10kΩ），导致上升沿变缓。第四步测试电机：给 PWM 设置固定 50% 占空比，听电机是否有嘶嘶声并测量电机端电压。如果电机不转但电压正常，检查 TB6612 的 STBY 引脚是否被拉高，这个引脚是电机驱动芯片的总开关，很多模块默认不拉高，需要程序主动置 1。最后一步测试雾化片，开启水位检测和雾化使能后，用万用表电流挡测雾化模块输入电流，正常工作时电流应该在 300mA 到 500mA 之间（不同雾化片规格差异大，以数据手册为准），电流过小说明雾化片没在震荡，电流过大则可能是水位不足导致过流。

5.2.1 雾化量不均匀的排查方向

加湿器出雾稳定后，如果发现雾化量忽大忽小，排查方向不要一开始就看程序。最常见原因是水箱水位波动导致雾化片浸泡深度变化。超声波雾化片需要被水淹没 2mm 到 5mm 才能正常工作，水位过高会增大水层阻尼，过浅则可能空振。修正方法是调整水位检测探针的位置，让低水位触发点设置在雾化片上表面以上 5mm 左右。程序上的配合是：低水位保护触发之后，需要滞后 30 秒才能重新开启雾化，因为断电后水波回稳需要时间，立即重启会导致水位误判。

滤网堵塞是另一个被忽视的原因。移动加湿器在巡航过程中吸入灰尘，雾化片上积累了水垢，输出量会逐渐减少。这属于硬件维护问题，不是在程序里能解决的，但如果程序里有累计运行时间统计，可以做一个提醒功能：每累计 200 小时让状态机进入 MAINTENANCE 状态并闪烁 LED 提示清理雾化片。这个功能不需要额外硬件，只需在 RTC 或者定时器中断里递增一个变量，掉电保存到 Flash。

5.3 整机联调：让状态机切换不卡顿、不互相干扰

整机联调是最后一关。先将加湿器放在桌面上，不要装水，验证移动到桌边时能否及时掉头。如果没有安装红外避障传感器，至少要在程序里加入超时掉头机制：在 MOVING 状态下，如果前进受阻超过 3 秒，程序应自动切换为后退或转向。这个超时可以通过电机电流或测速码盘的脉冲计数来判定。加湿器实际场景中由于负载恒定，电机电流波动不大，最简单的方式是加一个霍尔测速码盘，如果码盘脉冲在 3 秒内没有变化就认为遇到障碍：

static uint32_t last_encoder_ticks = 0; static uint8_t blocked_counter = 0; void Motor_CheckBlocked(void) { uint32_t current_ticks = get_encoder_ticks(); if (current_ticks == last_encoder_ticks) { blocked_counter++; if (blocked_counter > 30) { // 10Hz 调用，3秒无移动 set_motor_dir(BACKWARD); blocked_counter = 0; state = STATE_BLOCKED_TURNBACK; } } else { blocked_counter = 0; } last_encoder_ticks = current_ticks; }

这段代码的逻辑是：每 100ms 调用一次，检查码盘计数是否变化。连续 30 次不变则判定为堵转，切换方向并进入 STATE_BLOCKED_TURNBACK 状态。这里的 30 次对应 3 秒，如果地面摩擦力较大，可以适当减小到 15 次，但不要小于 5 次，否则一次暂时打滑也会误判。get_encoder_ticks 函数从定时器编码器模式读取当前计数值，使用编码器模式时，TIM 的 SMCR 寄存器需要配置为编码器模式 1 或 2，此时外部时钟源由 A 相和 B 相提供。如果你的底盘电机不带编码器，可以用霍尔传感器加磁环的办法，那样不需要改造电机本体，只需在车轮轴上粘一个磁环并用霍尔开关采样脉冲。调通这段逻辑后，加湿器就能实现最基本的“碰壁掉头”，配合湿度传感器判断加湿时间，整个项目作为课程设计的验收点就基本齐了。

最后要提一个实际调参技巧：湿度低于 40% 时开启高速巡航和雾化，湿度高于 55% 时关闭雾化并回到 IDLE。不要试图把湿度恒定在某个精确值，因为超声波雾化器的湿度惯性很大，实测从 40% 到 45% 往往需要几分钟，这时候控制波动反而会让雾化片频繁启停。用滞回区间来控制是最稳的：低于 40% 开启，高于 55% 关闭。中央区间不动作。这是整个智能移动加湿器设计中唯一一处需要“反直觉”操作的地方，简化控制反而能获得更大的出雾稳定度和更小的传感器抖动影响。

本文还有配套的精品资源，点击获取