STM32温控开关项目实战：从模块到系统的嵌入式设计思维

最近在整理一些嵌入式项目时，发现一个挺有意思的现象：很多朋友在学完STM32的基础外设后，想动手做个综合性的小项目，第一个想到的往往是“温控开关”。想法很直接——用传感器测温，温度到了就控制继电器开关，再加几个按键调调阈值，听起来一气呵成。

但真做起来，不少人会卡在几个意想不到的地方。比如，DHT11读回来的数据时对时错，继电器吸合瞬间单片机就复位了，按键调阈值时数码管或屏幕显示乱跳，或者程序跑起来总觉得“不跟手”。这些问题，单看每个模块的例程好像都简单，一旦拼成一个系统，各种时序冲突、电源干扰、逻辑耦合就全冒出来了。

这个“STM32温控开关”项目，就是一个典型的从模块练习到系统集成的练手桥。它真正的价值，不在于实现了多复杂的功能，而在于让你亲身体验：如何把几个独立的“零件”（传感器、执行器、人机接口），通过合理的软件架构和硬件设计，组装成一个稳定、可靠、可交互的“产品”。哪怕功能简单，这个过程里对中断、定时器、状态机、电源管理的思考，远比调通一个传感器更有意义。

1. 项目拆解：不只是“读取-比较-输出”那么简单

乍一看，温控开关的逻辑再清晰不过：循环读取DHT11的温度值，与设定的阈值比较，超过则开继电器，低于则关继电器，按键用来修改阈值。如果只写一个main函数里的while(1)循环，似乎百来行代码就能搞定。

但稍微细想，就会发现这种“裸奔”式写法隐藏着诸多问题：

• 阻塞式读取：DHT11是单总线器件，一次通信需要毫秒级时间。如果用阻塞延时等待其响应，在这几毫秒内，单片机无法响应按键、无法更新显示、也无法处理其他逻辑，用户体验会非常“卡”。
• 按键消抖与实时响应：如果按键检测也放在主循环里，由于DHT11的读取是阻塞的，按键可能无法被及时捕获，长按、连按等功能更难实现。
• 继电器干扰：继电器线圈是感性负载，吸合和释放瞬间会产生很大的反向电动势和电流冲击。如果电源设计不当，这个干扰足以导致单片机复位或DHT11通信失败。
• 阈值逻辑：简单的“大于开，小于关”会导致在阈值附近时，继电器频繁动作（抖动），缩短继电器寿命。通常需要引入“回差”（Hysteresis）机制，例如：温度高于28°C开启，直到低于26°C才关闭。

所以，这个项目的核心挑战，从“功能实现”变成了“资源协调与稳定运行”。我们需要一个框架来优雅地管理这些并发的、有不同实时性要求的任务。

2. 系统框架设计：用状态机与定时器剥离耦合

要解决上述问题，一个清晰的分层和分时框架是关键。这里推荐一种在资源有限的单片机中非常实用的架构：基于定时器中断的协同式调度配合有限状态机（FSM）。

2.1 硬件模块与软件任务映射

首先，我们把各个硬件模块抽象成独立的软件任务：

2.2 核心：一个简洁的定时器调度器

我们可以使用一个基本定时器（如TIM2）产生固定的时间节拍（例如1ms或10ms中断）。在这个中断服务函数里，只做一件事：更新一系列的任务计时标志。

// 在定时器中断中（示例为1ms中断） void TIM2_IRQHandler(void) { if (TIM_GetITStatus(TIM2, TIM_IT_Update) != RESET) { TIM_ClearITPendingBit(TIM2, TIM_IT_Update); // 更新任务计时器 if (dht11_timer_cnt > 0) dht11_timer_cnt--; if (key_scan_timer_cnt > 0) key_scan_timer_cnt--; if (display_timer_cnt > 0) display_timer_cnt--; // ... 其他任务计时器 } }

在主循环中，我们不再使用HAL_Delay，而是检查这些计时标志是否归零。归零则执行对应任务，并重新装载计时值。

int main(void) { // 初始化硬件、定时器、任务计时器... while (1) { // 任务调度 if (dht11_timer_cnt == 0) { dht11_task(); // 执行温度采集 dht11_timer_cnt = 2000; // 2秒后再次执行 } if (key_scan_timer_cnt == 0) { key_scan_task(); // 执行按键扫描 key_scan_timer_cnt = 10; // 10ms后再次执行 } if (display_timer_cnt == 0) { display_update_task(); // 更新显示 display_timer_cnt = 200; // 200ms后再次执行 } // ... 其他任务 // 温度控制逻辑（非阻塞式判断） temperature_control_task(); } }

这个框架的好处是：任何任务的执行都不会长时间阻塞主循环。DHT11读取的4ms期间，按键扫描计时器仍在倒计时，时间一到就会被执行，实现了伪“并行”处理。

2.3 DHT11：从“延时等待”到“超时状态机”

DHT11的驱动是新手最容易写出问题的地方。标准的例程充斥着delay_us，非常脆弱。更好的方法是实现一个基于状态机的非阻塞驱动。

1. 将一次完整的读取过程（启动->响应->数据位）划分为多个状态。
2. 每个状态中，检查引脚电平、记录时间，并判断是否超时。
3. 在定时器中断或主循环中快速调用该状态机函数，它根据当前状态执行一步操作，然后立即返回。
4. 读取完成后，通过一个标志位通知主程序数据就绪。

这样，读取DHT11的4ms被拆分成数十个微小的步骤穿插在其他任务中执行，系统响应性极大提升。即使因为干扰导致某次读取超时失败，状态机也可以超时退出并重试，不会卡死整个系统。

2.4 温度控制逻辑：引入回差消除抖动

温度控制不能是简单的比较，需要一个小状态机：

typedef enum { CONTROL_OFF, CONTROL_ON } control_state_t; control_state_t ctrl_state = CONTROL_OFF; float temperature; float threshold_high = 28.0; // 开启阈值 float threshold_low = 26.0; // 关闭阈值（回差2度） void temperature_control_task(void) { switch (ctrl_state) { case CONTROL_OFF: if (temperature > threshold_high) { relay_on(); // 开启继电器（如控制风扇） ctrl_state = CONTROL_ON; } break; case CONTROL_ON: if (temperature < threshold_low) { relay_off(); // 关闭继电器 ctrl_state = CONTROL_OFF; } break; } }

这个简单的状态机确保了继电器不会在阈值点附近疯狂跳动。

3. 硬件设计要点：稳定性的基石

软件框架再好，硬件不可靠也是白搭。对于这个项目，硬件上有三个坑一定要避开。

3.1 电源隔离与滤波

这是导致项目不稳定的头号元凶。继电器动作时，线圈电流突变会在电源线上产生毛刺。

• 必须为继电器单独供电：如果使用5V继电器，最好用一路独立的5V电源（或通过DC-DC模块从总电源隔离出来），不要和单片机的3.3V直接从同一路LDO引出。
• 续流二极管：务必在继电器线圈两端反向并联一个二极管（如1N4007），用于吸收关断时的反向电动势。
• 电源滤波：在单片机电源入口处，增加一个100μF的电解电容（滤低频）和一个0.1μF的瓷片电容（滤高频）。在DHT11的VCC和GND之间，也就近放置一个0.1μF电容。

3.2 信号隔离

如果条件允许，使用光耦或者继电器模块来隔离单片机的控制信号和继电器的线圈驱动电路。即使不隔离，也一定要用三极管或MOS管驱动继电器，绝不能用单片机的IO口直接驱动线圈。

// 正确的驱动方式：IO口 -> 限流电阻 -> NPN三极管基极 // 继电器线圈接在集电极回路中。IO输出高电平，三极管导通，继电器吸合。

3.3 布线与接地

• DHT11的数据线不要靠近继电器的驱动走线。
• 数字地（单片机、DHT11）和功率地（继电器驱动部分）可以单点连接。
• 如果使用LCD屏，其背光电流可能较大，也需注意电源路径。

4. 按键与交互设计：从“能用”到“好用”

4个按键通常定义为：加（+）、减（-）、设置（SET）、确认（OK）。交互逻辑可以这样设计：

1. 待机界面：显示当前温度和阈值。短按SET进入阈值调整模式。
2. 调整模式：光标或特定标识指示当前调整的是“高温阈值”还是“低温阈值”。通过+/-按键调整数值，调整过程实时显示。短按SET在高低阈值间切换，长按SET或按OK保存并退出。

这里的关键是按键任务的分层处理：

• 底层扫描：每10ms扫描一次引脚，完成消抖，输出稳定的“按下”、“释放”、“长按”等事件。
• 中层逻辑：根据当前系统模式（显示模式、设置模式），将按键事件映射为具体的功能命令（如“值增加”、“切换项目”）。
• 高层应用：执行功能命令，更新阈值变量，刷新显示。

这种处理使得按键响应灵敏，逻辑清晰，易于扩展。

5. 从原型到“产品”：还需要考虑什么？

如果你想让这个项目更接近一个真正的产品，而不仅仅是一个实验，下面几点值得思考：

• 参数存储：调整后的阈值掉电不能丢失。需要学习如何使用STM32的内部Flash（EEPROM模拟）或者外挂一个AT24C02这类的小容量EEPROM来存储参数。
• 异常处理：DHT11可能断开或损坏，连续多次读取失败后，系统应该进入“传感器故障”状态，并给出提示（如显示“--”），继电器应进入安全模式（如保持关闭或保持最后状态）。
• 输出保护：如果继电器控制的是加热棒，需要考虑“加热超时”保护。持续开启超过一定时间（如10分钟）后强制关闭，防止温控失效导致事故。
• 通信与监控：可以增加一个USART接口，将温度、状态、阈值等信息打印到串口，方便用电脑监控。更进一步，可以连接蓝牙模块（如HC-05）实现手机监控。

回过头看，这个“温控开关”项目就像一面镜子。它照出的不是你能否调用库函数，而是你能否系统性思考一个嵌入式问题：如何划分任务、如何管理时间、如何设计状态、如何保证硬件稳定、如何设计人机交互。把这些想清楚了，代码不过是水到渠成的表达。下次当你再看到“读取-比较-输出”这类简单描述时，或许就能下意识地去想，它的背后，需要一个怎样的系统来可靠地支撑。