第三十讲：综合实战——智能家居控制系统
好，终于到了这门课的收官之战。
前面二十多讲，我们拆解了模块化编程的各个要点。从头文件设计、接口隔离，到状态机、回调函数，再到内存管理和分层架构。说实话，这些知识点单独拎出来都不难。但真正考验人的，是怎么把它们揉在一起，做成一个能跑、能维护、能扩展的系统。
这一讲，我们就拿「智能家居控制系统」来练手。我当年在创业公司带团队时，就做过类似的项目。那会儿踩的坑，今天一并讲给你听。
一、需求分析——先搞清楚要做什么
做项目最怕什么？最怕需求不清就开始写代码。我见过太多人，上来就撸主控逻辑，结果写到一半发现「哦，原来还要支持远程控制」，然后回头改架构，改得想吐。
智能家居控制系统的核心需求，其实就三条：
- 本地控制：按键、触摸屏、红外遥控，这些是基础操作
- 传感器采集：温度、湿度、光照、人体红外，数据要能读上来
- 执行器控制：继电器（开关灯）、电机（窗帘）、蜂鸣器（报警）
嗯，听起来不复杂对吧？但别忘了，还有几个非功能性需求：
- 可扩展性：今天接3个传感器，明天可能要接8个，代码不能大改
- 可维护性：半年后换个人来维护，不能看不懂
- 实时性：按键按下去，灯要立刻亮，不能有半秒延迟
核心原则：需求分析阶段，我建议你多花30%的时间。因为后面改需求的成本，是前面的10倍。
二、模块划分——怎么切才合理？
模块划分这件事，说白了就是「高内聚、低耦合」。但具体怎么切？我个人的习惯是：按功能领域切，不按硬件外设切。
什么意思？举个例子：
- ❌ 错误做法：一个模块叫「GPIO模块」，里面既管按键又管LED还管继电器
- ✅ 正确做法：分成「按键模块」「LED模块」「继电器模块」，各管各的
为什么？因为GPIO只是一个物理接口，它不代表功能。你想想看，按键和继电器虽然都用GPIO，但它们的逻辑完全不同。按键要消抖、要检测长按短按；继电器只要开和关。混在一起，代码会乱成一锅粥。
我们这个智能家居系统，我建议分成以下几层：
| 层级 | 模块 | 职责 |
|---|---|---|
| 应用层 | app_main | 系统初始化、主循环调度 |
| 业务层 | scene_mgr | 场景管理（回家模式、离家模式） |
| 业务层 | alarm_mgr | 报警逻辑（温湿度超限、非法闯入） |
| 驱动层 | sensor_drv | 传感器数据读取（DHT11、BH1750） |
| 驱动层 | actuator_drv | 执行器控制（继电器、步进电机） |
| 硬件抽象层 | hal_gpio | GPIO读写封装，屏蔽芯片差异 |
| 硬件抽象层 | hal_timer | 定时器服务，提供软件定时器 |
你看，每一层只做一件事。驱动层不关心业务逻辑，业务层不关心硬件细节。这就是分层的好处。
三、接口设计——模块之间怎么说话？
模块划分好了，接下来就是接口设计。接口设计得好，模块之间就像拼乐高；设计得不好，就像用502胶水粘起来的——拆都拆不掉。
我总结了几条接口设计的原则：
- 接口要小：一个函数只做一件事。比如
sensor_read_temperature()就只读温度，别在里面顺便把LED也点亮了 - 参数要少：超过3个参数，就要考虑用结构体了
- 返回值要明确：成功返回0，失败返回负的错误码。别搞什么「返回0表示成功，返回1表示失败，返回2表示超时」——这种设计让人抓狂
来看一个具体的接口设计示例：
/* sensor_drv.h */
#ifndef SENSOR_DRV_H
#define SENSOR_DRV_H
#include <stdint.h>
/* 传感器数据类型 */
typedef struct {
float temperature; /* 温度，单位：摄氏度 */
float humidity; /* 湿度，单位：百分比 */
uint16_t lux; /* 光照强度，单位：lux */
} sensor_data_t;
/* 传感器错误码 */
#define SENSOR_OK 0
#define SENSOR_ERR_BUS -1 /* 总线错误 */
#define SENSOR_ERR_CRC -2 /* 校验错误 */
#define SENSOR_ERR_TIMEOUT -3 /* 超时 */
/* 接口函数 */
int sensor_init(void);
int sensor_read_all(sensor_data_t *data);
int sensor_read_temperature(float *temp);
int sensor_read_humidity(float *hum);
int sensor_read_lux(uint16_t *lux);
#endif /* SENSOR_DRV_H */小技巧：接口头文件里只放调用者需要知道的东西。内部实现的宏、静态函数、私有结构体，统统放到 .c 文件里。这叫「信息隐藏」。
四、代码实现——把设计落地
好，理论说完了，咱们动手写代码。
先看主循环。主循环的设计，我建议用「事件驱动」的方式。别搞一个大while循环里轮询所有东西，那样CPU占用高，而且不好扩展。
/* app_main.c */
#include "sensor_drv.h"
#include "actuator_drv.h"
#include "scene_mgr.h"
#include "alarm_mgr.h"
#include "hal_timer.h"
int main(void)
{
/* 初始化所有模块 */
hal_timer_init();
sensor_init();
actuator_init();
scene_init();
alarm_init();
/* 注册一个1秒的定时器，用于传感器采集 */
timer_id_t timer_sensor = hal_timer_register(1000, sensor_task, TIMER_REPEAT);
hal_timer_start(timer_sensor);
/* 注册一个500ms的定时器，用于按键扫描 */
timer_id_t timer_key = hal_timer_register(500, key_scan_task, TIMER_REPEAT);
hal_timer_start(timer_key);
/* 主循环：只处理事件，不做轮询 */
while (1) {
event_t evt;
if (event_queue_get(&evt, 100)) { /* 等待100ms */
event_dispatch(&evt);
}
}
return 0;
}你看，主循环非常干净。所有的定时任务都在中断或软定时器里触发，主循环只负责分发事件。这样做的好处是：你想加一个新功能，只需要注册一个新的定时器和对应的事件处理函数，主循环一行代码都不用改。
我曾经在一个项目里，用这种方式把主循环从300行缩减到了30行。那感觉，就像把一团乱麻理成了整齐的线缆。
五、测试与部署——别让Bug上线
代码写完了，是不是就完事了？当然不是。测试这一步，我建议你至少花和写代码一样多的时间。
嵌入式系统的测试，我一般分三步走：
- 单元测试：每个模块单独测。比如 sensor_drv 能不能正确读到数据？边界情况（传感器断开、数据异常）有没有处理？
- 集成测试：把几个模块拼起来测。比如按键按下后，场景管理器能不能正确切换模式？报警触发后，执行器能不能正确响应？
- 系统测试：整机跑起来，模拟真实场景。比如连续运行72小时，看有没有内存泄漏、看响应时间是否达标
注意：测试的时候，一定要覆盖异常情况。我见过最惨的案例——某个同事只测了正常流程，结果产品上线后，用户把传感器线拔了，系统直接死机。原因就是代码里没有做空指针检查。
部署的时候，有几点要特别注意：
- 版本号管理：每次发布都要打tag，方便回滚
- 配置参数分离：阈值、延时、IO口映射这些，放到配置文件中，不要硬编码
- 日志输出：保留调试日志的接口，但正式发布时关掉详细日志，只保留错误日志
六、知识体系总览
下面这张图，是我对这个智能家居控制系统整体架构的理解。你可以把它当作一个「地图」，写代码的时候对照着看，不容易迷路。
从这张图可以看得很清楚：每一层只依赖它的下一层，绝不跨层调用。比如业务层只能调驱动层，不能直接操作HAL。这样做的好处是——哪天你要换MCU，只需要重写HAL层，上面的代码基本不用动。
七、写在最后
这一讲的内容量不小。从需求分析到模块划分，从接口设计到代码实现，再到测试部署，我们完整走了一遍智能家居控制系统的开发流程。
说实话，模块化编程这件事，光看是学不会的。你得动手写，写完了再重构，重构完了再写。我当年也是从「一个main.c写2000行」的阶段过来的。后来慢慢学会了拆分、学会了抽象、学会了接口设计。
如果你现在正在做一个嵌入式项目，不妨试试今天讲的这套方法。先从分层开始，把代码拆成app、业务、驱动、HAL四层。然后定义好接口，让每一层只通过接口通信。最后用事件驱动的方式组织主循环。
相信我，等你做完这个重构，你会爱上模块化编程的。
公众号:蓝海资料掘金营，微信deep3321