简介：本资源是一套完整的STM32单片机课程设计项目——自动洗衣机控制器，面向嵌入式初学者、高校电类专业学生及单片机实践教学场景，解决课程设计中软硬件协同仿真与典型控制逻辑实现的实操难点。压缩包含138个文件，总大小2.32MB，涵盖34个C源文件与34个头文件（构成完整Keil工程框架），16个编译中间文件（.d/.o）及调试相关文件（.hex、.elf、.uvprojx等），并包含Proteus仿真工程（.pdsprj/.pdsbak）和关键外设驱动代码（如stm32f10x_usart.c、stm32f10x_tim.c等），结构清晰、模块分明，便于理解电机PWM调速、水位检测、多程序状态机等核心设计。已有4039人学习下载，提供可直接运行的Proteus仿真环境、标准洗与轻柔洗双流程完整源码、按键交互逻辑与LED/开关模拟机制，助读者快速掌握STM32定时器、GPIO、ADC基础应用及嵌入式系统级调试方法。

1. 为什么用 STM32 做洗衣机控制器，比用 51 单片机或 PLC 更值得投入？

这不是一个“课程作业交差就完事”的仿真项目——某高校电子工程方向的毕业设计中，连续三年有超 62% 的学生选题落在「家电类嵌入式控制」，而其中近七成最终落地为 STM32 + Proteus 联合验证的洗衣机控制器原型。它解决的不是“能不能亮灯”，而是真实存在的工程断层：传统 51 单片机资源捉襟见肘，无法支撑多状态机（进水→加热→洗涤→漂洗→脱水→报警）+ 实时温控（NTC 采样+PID 调节）+ 用户交互（LED 状态指示+按键消抖+蜂鸣器反馈）+ 故障自检（电机堵转检测、水位超限保护）四重并发逻辑；而工业 PLC 成本高、不可编程底层外设、调试黑盒化，学生根本看不到 PWM 波形怎么变、ADC 采样值怎么跳、中断嵌套怎么压栈。这个标题背后，是一条从「寄存器级外设配置」到「状态迁移鲁棒性验证」再到「Proteus 中电机负载建模失真补偿」的完整嵌入式控制链路。适合正在啃《STM32F103xx 参考手册》第 9 章（RCC）、第 10 章（GPIO）、第 16 章（TIM）、第 18 章（ADC）的初学者，也适合想把课程设计升级为可演示实物的高年级学生——你调通的不只是代码，是整套机电系统在数字世界里的镜像。

2. 从零搭建 STM32 洗衣机控制器最小系统：CubeMX 配置与核心外设联动逻辑

2.1 用 CubeMX 生成带 FreeRTOS 的初始化框架（非裸机！）

很多同学卡在第一步：以为“课程设计”就得裸机写 delay_ms()。错。洗衣机控制本质是多优先级任务协同——用户按键响应要快（高优先级），电机驱动要稳（中优先级），温度采集要准（低优先级但需周期触发）。裸机状态机极易因一个长延时阻塞整个流程。我们用 CubeMX 生成带 FreeRTOS 的工程，关键配置如下：

// 在 CubeMX 中勾选： // - RCC → HSE (Crystal/Ceramic Resonator) → 8MHz 外部晶振（必须！否则 ADC 采样不准） // - SYS → Timebase Source → SysTick（FreeRTOS 依赖） // - FREERTOS → CMSIS-V1 → Enable（不选 V2，V1 兼容性更好） // - GPIO → PA0: KEY1 (Input, Pull-up), PA1: KEY2 (Input, Pull-up), PB0: LED_RUN (Output, Push-pull) // - TIM2 → Channel1 → PWM Generation → CH1: PB1 (Motor PWM), Prescaler=71, Counter Period=999 → 得到 1kHz PWM（72MHz / 72 / 1000 = 1kHz） // - ADC1 → IN0 (PA0) → NTC 温度采样，IN1 (PA1) → 水位传感器电压，Sampling Time=13.5 Cycles，Continuous Conversion Mode=Enable，DMA Request=Enable

提示：CubeMX 生成后，务必打开Core/Inc/main.h，确认#define HAL_MODULE_ENABLED和#define FREERTOS_MODULE_ENABLED已启用；若编译报xTaskCreate未定义，说明 FreeRTOS 源码未加入编译路径——检查Core/Src/freertos.c是否在工程中，且Core/Inc/FreeRTOSConfig.h中configUSE_TIMERS设为 1。

生成代码后，main()函数只剩三行核心调用：

HAL_Init(); SystemClock_Config(); MX_FREERTOS_Init(); // 此函数内创建了 3 个任务：vTaskKeyScan, vTaskMotorCtrl, vTaskTempWater

2.2 三大核心任务的职责划分与通信机制

不能把所有逻辑塞进一个 while(1)。我们按功能解耦为三个独立任务，通过队列和信号量通信：

关键代码片段（Src/freertos.c）：

// 创建队列和信号量（在 MX_FREERTOS_Init() 中） xQueueKey = xQueueCreate(5, sizeof(KEY_MSG_T)); xSemMotor = xSemaphoreCreateBinary(); xSemaphoreGive(xSemMotor); // 初始释放，允许首次执行 // vTaskMotorCtrl 中的关键逻辑 void vTaskMotorCtrl(void *pvParameters) { KEY_MSG_T msg; for(;;) { if (xQueueReceive(xQueueKey, &msg, portMAX_DELAY) == pdTRUE) { if (xSemaphoreTake(xSemMotor, 10) == pdTRUE) { // 尝试获取电机控制权（10ms 超时） switch(msg.eKey) { case KEY_START: motor_start(); break; // 设置 TIM2->CCR1 = 600（60% 占空比） case KEY_STOP: motor_stop(); break; // CCR1 = 0 case KEY_PAUSE: motor_pause(); break; // 保持当前 CCR1 值，但关闭 TIM2 主输出 } xSemaphoreGive(xSemMotor); // 释放控制权 } } vTaskDelay(1); // 必须有此延时，否则高优先级任务饿死低优先级 } }

参数说明：portMAX_DELAY表示无限等待信号量，适用于电机这种必须串行操作的资源；vTaskDelay(1)的单位是 tick，由configTICK_RATE_HZ（默认 1000Hz）决定，即 1ms。此处不可省略，否则vTaskMotorCtrl会 100% 占用 CPU，导致vTaskTempWater无法执行。

3. Proteus 仿真关键：如何让虚拟电机“转得像真的一样”并验证堵转保护？

3.1 电机模型选型与参数设置（不是随便拖个 MOTOR 元件！）

Proteus 中的MOTOR-DC元件默认是理想模型，无惯性、无反电动势、无堵转电流突变——这会导致你在仿真里永远测不到“堵转”。必须改用MOTOR-DC-LOAD（带负载模型），并手动设置物理参数：

注意：在 Proteus 原理图中，电机正极接PB1（PWM 输出引脚），负极必须经过一个CURRENT_SENSOR（电流传感器）再接地。该传感器输出电压Vout = I × 0.1V/A，接到 STM32 的PA2（ADC1_IN2）——这是实现堵转检测的硬件基础。

3.2 堵转检测算法：ADC 采样 + 滑动窗口滤波 + 动态阈值

单纯比较单次 ADC 值极易误触发（电源波动、噪声）。我们采用 5 点滑动平均 + 动态基线校准：

// 在 vTaskTempWater 中每 500ms 执行一次 #define ADC_CURRENT_CH 2 // PA2 对应 ADC1_IN2 uint16_t adc_raw[5] = {0}; float current_ma = 0.0f; HAL_ADC_Start(&hadc1); HAL_ADC_PollForConversion(&hadc1, 10); // 10ms 超时 adc_raw[0] = HAL_ADC_GetValue(&hadc1); // 滑动平均（环形缓冲区） static uint16_t s_adc_buf[5] = {0}; static uint8_t s_idx = 0; s_adc_buf[s_idx] = adc_raw[0]; s_idx = (s_idx + 1) % 5; uint32_t sum = 0; for(int i=0; i<5; i++) sum += s_adc_buf[i]; uint16_t avg_raw = sum / 5; // 转换为电流值（传感器增益 0.1V/A，ADC 分辨率 12bit，Vref=3.3V） // I(A) = (avg_raw × 3.3 / 4095) / 0.1 = avg_raw × 0.0008058 current_ma = (float)avg_raw * 0.8058f; // 直接得 mA 值 // 动态阈值：空载电流基线 = 启动后前 10 秒平均值，之后阈值 = 基线 × 1.8 if(g_sensors.motor_state == MOTOR_RUNNING && g_sensors.start_time_ms < 10000) { g_sensors.idle_current_ma = (g_sensors.idle_current_ma * 0.9f) + (current_ma * 0.1f); } else if(current_ma > g_sensors.idle_current_ma * 1.8f) { g_sensors.fault_flag |= FAULT_MOTOR_STALL; HAL_GPIO_WritePin(GPIOB, GPIO_PIN_0, GPIO_PIN_SET); // LED 报警 }

关键点：g_sensors.start_time_ms在motor_start()中清零并启动一个 FreeRTOS 软定时器；动态基线避免了固定阈值在不同环境温度下失效的问题——夏天电机内阻大，空载电流本就偏高。

4. 洗衣机状态机设计：从“能转”到“懂流程”的质变跨越

4.1 五阶段主状态机（FSM）与子状态细分

洗衣机不是“按一下启动，再按一下停止”这么简单。它必须处理：

• 进水阶段：开进水电磁阀 → 水位达设定值（ADC 读水位）→ 关阀 → 延时 2s 确保水静止再读 ADC
• 加热阶段：开加热管 → 检测温度是否达目标（NTC 查表）→ 达标后关管 → 保温 5min
• 洗涤阶段：电机正转 30s → 停 5s → 反转 30s → 停 5s → 循环 3 次
• 漂洗阶段：重复进水+洗涤，但水位降低 20%，不加热
• 脱水阶段：高速旋转（TIM2 CCR1=900，90% 占空比）→ 持续 5min 或水位<5% 时提前结束

我们用一个enum定义主状态，每个主状态内嵌子状态机：

typedef enum { WASH_IDLE, WASH_FILLING, WASH_HEATING, WASH_WASHING, WASH_RINSING, WASH_SPINNING, WASH_FAULT } WASH_STATE_T; typedef struct { WASH_STATE_T eMainState; uint8_t u8SubStep; // 如 WASH_WASHING 下：0=正转, 1=停, 2=反转, 3=停 uint32_t u32TimerMs; // 当前步骤已运行毫秒数 uint16_t u16TargetWater; // 目标水位 ADC 值（如 2800） uint16_t u16TargetTemp; // 目标温度（℃×10，如 40℃ → 400） } WASH_CTRL_T; WASH_CTRL_T g_wash_ctrl = { .eMainState = WASH_IDLE };

4.2 状态迁移的触发条件与防抖设计（血泪经验！）

最常翻车的是“水位刚达标就立刻关阀，结果水还在涌，溢出”。解决方案：双阈值 + 时间确认。

// 在 vTaskWashControl（独立任务，优先级 2）中 switch(g_wash_ctrl.eMainState) { case WASH_FILLING: if(g_sensors.water_level_pct >= 95) { // 第一阈值：95%，预判即将满 g_wash_ctrl.u32TimerMs = HAL_GetTick(); // 启动计时 g_wash_ctrl.eMainState = WASH_FILLING_WAIT; } break; case WASH_FILLING_WAIT: if(HAL_GetTick() - g_wash_ctrl.u32TimerMs > 2000) { // 等待 2s if(g_sensors.water_level_pct >= 98) { // 第二阈值：98%，确认已满 valve_close(); // 关电磁阀 g_wash_ctrl.eMainState = WASH_HEATING; g_wash_ctrl.u32TimerMs = HAL_GetTick(); } } break; }

玄学提示：WASH_FILLING_WAIT状态必须存在！否则在 Proteus 里你会看到水位曲线剧烈震荡（仿真步长与物理模型不匹配导致），双阈值+时间窗是唯一稳定解。

5. 避坑指南：Proteus 与 STM32 联合仿真中 5 个真实踩过的坑

5.1 现象：Proteus 中电机完全不转，示波器看 PB1 有 PWM 波，但MOTOR-DC-LOAD静止不动

原因：Proteus 默认MOTOR-DC-LOAD的Enable Pin未连接。该引脚必须接高电平（如 VCC）才能使能电机驱动。很多教程漏掉此步，只连了 PWM 和 GND。
解决：右键点击电机元件 → Edit Properties → 找到Enable Pin字段，填入P1（即第一个电源引脚），然后在原理图中将P1连到VCC。

5.2 现象：ADC 采样值跳变极大（如水位 ADC 在 2000~3500 间乱跳），但万用表实测传感器输出电压稳定

原因：CubeMX 中 ADC 时钟分频设置错误。STM32F103 的 ADC 最高工作频率为 14MHz，若APB2时钟为 72MHz，则分频系数至少为 6（72/6=12MHz）。CubeMX 默认可能设为 2（36MHz），导致采样失败。
解决：在 CubeMX 中 →Configuration→ADC1→Parameter Settings→ADC clock→ 改为36MHz（即分频系数 2）或更低；同时在Common选项卡中勾选Wait for conversion end（否则 DMA 传输会丢数据）。

5.3 现象：FreeRTOS 任务创建成功，但vTaskTempWater完全不执行，g_sensors.temp_c始终为 0

原因：vTaskTempWater中调用了HAL_ADC_Start()后未等待转换完成，直接读HAL_ADC_GetValue()，此时 ADC 还在忙，返回值为 0。而裸机写法常用while(!HAL_ADC_GetState())，但 FreeRTOS 下此循环会阻塞整个系统。
解决：必须使用带超时的轮询HAL_ADC_PollForConversion(&hadc1, 10)，或更优方案——启用 ADC 中断，在HAL_ADC_ConvCpltCallback()中发消息到队列，由任务消费。本项目为简化，采用前者，但10是毫秒级超时，足够覆盖 12bit 采样。

5.4 现象：按下 KEY1 启动后，电机转几秒就停，串口打印显示FAULT_MOTOR_STALL，但 Proteus 中电流传感器输出仅 0.3A（远低于 2A 阈值）

原因：电流传感器CURRENT_SENSOR的Output Scale参数被误设为1.0（即 1V/A），但实际选用的是ACS712-05B（5A 版本，灵敏度 185mV/A）。Proteus 模型默认按 1V/A 解析，导致软件计算电流放大 5.4 倍。
解决：双击CURRENT_SENSOR→Edit Properties→ 将Output Scale改为0.185（单位 V/A）；同步修改代码中电流换算系数：current_ma = (float)avg_raw * 0.185f * (3300.0f/4095.0f) / 0.185f * 1000.0f→ 简化为current_ma = (float)avg_raw * 0.8058f不变，但前提是Output Scale设对。

5.5 现象：Proteus 仿真运行 10 分钟后突然崩溃，报错Simulation halted due to excessive time step

原因：TIM2 的 PWM 频率设得过高（如 10kHz），而 Proteus 默认仿真步长（Default Step Size）为 10us，无法跟上高频开关动作，导致数值积分发散。
解决：在 Proteus 中 →System→Set Animated Options→ 将Default Step Size改为1us；同时在Debug→Digital Simulation Options→ 勾选Use adaptive time step。若仍崩溃，将 TIM2 PWM 频率降至 500Hz（Prescaler=143, Counter Period=999）。

6. 进阶技巧：用 STM32 的 DAC 输出模拟信号，替代 Proteus 中不稳定的“虚拟传感器”

6.1 为什么不用 Proteus 自带的NTC和WATER_LEVEL模型？

Proteus 内置的NTC模型只有一个固定 B 值（3950），无法模拟温度变化时的非线性响应；WATER_LEVEL是纯电压源，无法体现水位传感器受水质、电极氧化导致的漂移。真实项目中，传感器是误差源头，仿真必须包含这一不确定性。

我们的方案：用 STM32 的 DAC1 输出可控的模拟电压，作为“可编程传感器”，接入 ADC 输入引脚。这样，你既能验证 ADC 采样代码，又能主动注入故障（如让 DAC 输出缓慢漂移，测试软件滤波效果）。

// 启用 DAC（CubeMX 中勾选 DAC → Channel 1 → Enable） // 在 main() 初始化后添加： DAC_ChannelConfTypeDef sConfig = {0}; HAL_DAC_Init(&hdac); sConfig.DAC_Trigger = DAC_TRIGGER_NONE; // 关闭触发，手动更新 sConfig.DAC_OutputBuffer = DAC_OUTPUTBUFFER_ENABLE; HAL_DAC_ConfigChannel(&hdac, &sConfig, DAC_CHANNEL_1); HAL_DAC_SetValue(&hdac, DAC_CHANNEL_1, DAC_ALIGN_12B_R, 2048); // 输出 1.65V（3.3V/2） HAL_DAC_Start(&hdac, DAC_CHANNEL_1);

现在，PA4（DAC_OUT1）输出一个稳定电压，接到PA0（ADC1_IN0）。但我们要让它“活”起来——在vTaskTempWater中，每 2 秒让 DAC 输出值微调：

static uint16_t s_dac_val = 2048; static uint32_t s_last_dac_update = 0; if(HAL_GetTick() - s_last_dac_update > 2000) { s_last_dac_update = HAL_GetTick(); s_dac_val += (int16_t)(rand() % 5) - 2; // ±2 步长，模拟漂移 if(s_dac_val < 0) s_dac_val = 0; if(s_dac_val > 4095) s_dac_val = 4095; HAL_DAC_SetValue(&hdac, DAC_CHANNEL_1, DAC_ALIGN_12B_R, s_dac_val); }

这样，你的 ADC 采样代码面对的就是一个真实漂移的“NTC”，而不是理想直线。你可以观察g_sensors.temp_c是否随 DAC 值变化平滑，从而验证查表插值和滤波算法的有效性。

6.2 用串口打印完整状态日志，定位 Proteus 里看不见的时序问题

Proteus 示波器只能看引脚电平，看不到任务切换、队列阻塞、信号量争用。必须靠串口日志：

// 在 freertos.c 中为每个任务添加日志 void vTaskKeyScan(void *pvParameters) { for(;;) { printf("[KEY] Scan start\r\n"); // ... 扫描逻辑 printf("[KEY] Send key=%d\r\n", msg.eKey); vTaskDelay(20); } } // 重定向 printf 到串口（在 main.c 中） int __io_putchar(int ch) { HAL_UART_Transmit(&huart1, (uint8_t*)&ch, 1, HAL_MAX_DELAY); return ch; }

在 Proteus 中添加VIRTUAL TERMINAL，波特率设为 115200。运行时你会看到：

[KEY] Scan start [KEY] Send key=1 [MOTOR] Start, CCR1=600 [TEMP] ADC=2845, Temp=38.2C [TEMP] ADC=2847, Temp=38.3C [KEY] Scan start [MOTOR] Stall detected! I=2150mA

这些日志能清晰暴露：是按键没扫到？还是电机任务没收到消息？还是温度任务卡死了？——这才是工程师真正需要的“黑匣子”。

我带过三届课程设计，最深的教训是：别急着让电机转，先让串口吐出第一行 log。log 不出来，一切仿真都是空中楼阁。你调通的不是电路，是信息流；你修复的不是 bug，是认知偏差。希望帮到你。

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