简介基于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.31V3.0V 的高电平确实能识别但噪声裕量只剩 0.7V。如果加湿器底盘电机转动产生电磁干扰数据线就容易误码。最稳妥的接法是 DHT11 VCC 接 5V上拉电阻接 3.3V这样 IO 高电平约 4.7VSTM32 识别毫无压力。如果传感器模块板上已经自带 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 组成的推挽震荡电路配合电感 L122uH和电容 C1102/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.3VSWCLK 加 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 上出现悬空电源引脚。用表格总结一下检查项检查项正常状态异常状态常见原因VCAP 电容2.2uF 接地芯片复位不稳容值过小或未接Boot0/Boot110kΩ 下拉程序不启动悬空受噪声干扰DHT11 上拉4.7kΩ 到 5V湿度读取错误上拉到 3.3V 噪声容限不足晶振电容12-22pF频率偏差大容值超范围电机逻辑输入经缓冲GPIO 发热直接驱动电流过大雾化联动硬件与门空转烧毁仅靠软件判断水位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。如果不定义 STM32F103xBHAL 库默认按 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 设为 8MHzSYSCLK 设为 72MHz。一个特别容易忽略的参数是 PWM 频率的选择。TB6612 电机驱动的 PWM 频率一般在 10kHz 到 50kHz 之间频率太高会增大驱动芯片的开关损耗太低则电机会发出人耳可闻的啸叫声。通常建议先设 20kHz如果发现电机噪音明显再降到 10kHz 或提高到 30kHz 做对比。雾化片控制不需要 PWM只需 GPIO 开关如果使用定时器输出比较模式来驱动雾化片的震荡电路则需要把频率设定为雾化片的谐振频率通常 108kHz 到 113kHz而不是随意设定 PWM 频率。雾化片参数可以在规格书上找到如果手头只有模块没有规格书可以通过示波器观察电流波形确定谐振点没有示波器就用“听”的方法雾化片出雾量最大且声音最尖锐的频率就是谐振点附近。3.2 DHT11 时序驱动与数据校验的实现细节DHT11 的驱动逻辑是这套源程序里最需要精细控制的部分。DHT11 采用单总线协议通信时序是主机发送起始信号拉低至少 18msDHT11 响应后拉低 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”的最小持续 68us40us 正好是两者的中间值。如果环境温度很低低于 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 / (01) / (36001) ≈ 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% 余量防止占空比饱和。这样实现简单不需要电流环适合低成本移动加湿器场景。可以增加一个表格来对比不同电压下的补偿系数电池电压 (V)ADC 采样值 (参考 3.3V)补偿系数60% 基础占空比的实际值4.234810.8852.8%4.033150.9355.5%3.831480.9758.4%3.629821.0361.7%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 改到 0x800Heap_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% 关闭。中央区间不动作。这是整个智能移动加湿器设计中唯一一处需要“反直觉”操作的地方简化控制反而能获得更大的出雾稳定度和更小的传感器抖动影响。本文还有配套的精品资源点击获取