简介：这份资源面向嵌入式开发学习者与智能家居项目实践者，提供一套基于STM32F429的完整系统设计方案，涵盖温湿度检测、红外识人预警、倒车雷达与智能密码锁四大功能模块。项目通过蓝牙与手机通信，可实现环境数据远程查看、超限自动预警、陌生人闯入提醒以及倒车距离实时回传，密码锁部分采用板载按键输入，适合作为课程设计、毕业设计或嵌入式综合练手项目。资源包共159个文件，包含12个c源文件与15个h头文件构成核心驱动逻辑，另有大量d、o、crf等编译中间文件及axf、hex可执行产物，配合uvprojx工程文件与map、lst映射清单，整体约7.44MB，结构完整可直接编译。目前已有1496人学习下载，读者可从中获取完整的工程框架、外设驱动代码与多模块整合思路，便于快速理解STM32F429在智能家居场景下的软硬件协同设计方法。
1. 从一块 F429 开发板到全屋联动：智能家居主控到底该怎么搭
很多人第一次做智能家居主控，都是从一块 STM32F429 开发板开始的。它主频 180MHz、带 FPU、带 LTDC 液晶控制器、带以太网 MAC、带 SDRAM 控制器，这些外设凑在一起，恰好能撑起一个「本地网关 + 触摸屏中控 + 多协议转发」的完整形态。但真正动手之后你会发现，难的不是点灯，而是把传感器采集、继电器控制、屏幕刷新、通信协议、异常恢复这几件事塞进一颗 MCU 里还不互相打架。这篇笔记就围绕「基于 STM32F429 的智能家居系统设计」这个方向，把选型理由、任务划分、关键参数和踩过的坑讲清楚，适合正在做毕设、做原型、或者想把家里几路设备统一管起来的嵌入式开发者。读完你应该能自己搭出一套能跑、能扩展、能排查问题的本地主控。
2. 主控选型与系统分层：为什么是 F429 而不是 F103
2.1 F429 相比 F103 多出来的东西，恰好是智能家居要用的
F103 系列做智能家居不是不行，但一旦你要接 TFT 屏做本地交互，F103 的 SRAM 和总线带宽就会立刻成为瓶颈。F429 的价值在于三点：第一，180MHz 主频加 ART 加速器，跑 FreeRTOS 多任务时余量充足；第二，外扩 SDRAM 后可以给 LTDC 显存和 GUI 缓冲留出独立空间，屏幕刷新不再和主循环抢内存；第三，自带以太网 MAC 和双 CAN，做本地组网时不用再外挂一堆转接芯片。
我一般会把系统分成四层来设计，这样后面加设备不会推倒重来：
| 层级 | 职责 | 典型实现 |
|---|---|---|
| 感知层 | 温湿度、人体、门磁、烟雾采集 | DHT22、HC-SR501、干簧管、MQ-2 |
| 执行层 | 继电器、红外发射、电机 | 光耦隔离继电器、IR LED |
| 主控层 | 任务调度、协议解析、屏幕交互 | STM32F429 + FreeRTOS + LVGL |
| 交互层 | 本地触摸屏、手机端、语音 | LTDC 屏、ESP8266/ESP32 转发 |
分层的好处是，感知层和执行层尽量做成「可替换模块」，主控层只认统一的数据结构。比如温湿度我统一成{dev_id, type, value, timestamp}，后面换传感器只改驱动，不改业务逻辑。
2.2 最小系统搭建：时钟、SDRAM、LTDC 三件事先跑通
在写任何业务代码之前，先把时钟树、SDRAM 和 LTDC 调通。F429 的 SDRAM 时序参数如果配错，表现是屏幕花屏或者随机死机，非常难查。下面是我常用的 SDRAM 初始化片段（以常见的 W9825G6KH 为例）：
// SDRAM 初始化关键参数，F429 接 W9825G6KH 常见配置 void SDRAM_Init(void) { FMC_SDRAM_InitTypeDef init; FMC_SDRAM_TimingTypeDef timing; // 时钟分频：HCLK=180MHz，2 分频后 SDRAM 时钟 90MHz init.SDBank = FMC_SDRAM_BANK1; init.ColumnBitsNumber = FMC_SDRAM_COLUMN_BITS_NUM_9; init.RowBitsNumber = FMC_SDRAM_ROW_BITS_NUM_13; init.MemoryDataWidth = FMC_SDRAM_MEM_BUS_WIDTH_16; init.InternalBankNumber = FMC_SDRAM_INTERN_BANKS_NUM_4; init.CASLatency = FMC_SDRAM_CAS_LATENCY_3; // 90MHz 下用 3 比较稳 init.WriteProtection = FMC_SDRAM_WRITE_PROTECTION_DISABLE; init.SDClockPeriod = FMC_SDRAM_CLOCK_PERIOD_2; init.ReadBurst = FMC_SDRAM_RBURST_ENABLE; init.ReadPipeDelay = FMC_SDRAM_RPIPE_DELAY_0; FMC_SDRAM_Init(FMC_SDRAM_DEVICE, &init); // 时序参数按手册最小值再留一点余量 timing.LoadToActiveDelay = 2; timing.ExitSelfRefreshDelay = 7; timing.SelfRefreshTime = 4; timing.RowCycleDelay = 7; timing.WriteRecoveryTime = 2; timing.RPDelay = 2; timing.RCDDelay = 2; FMC_SDRAM_Timing_Init(FMC_SDRAM_DEVICE, &timing, FMC_SDRAM_BANK1); // 使能时钟并等待稳定 FMC_SDRAM_WriteCRegister(FMC_SDRAM_DEVICE, FMC_SDRAM_CMD_CLK_ENABLE, 0); HAL_Delay(1); FMC_SDRAM_WriteCRegister(FMC_SDRAM_DEVICE, FMC_SDRAM_CMD_PALL, 0); FMC_SDRAM_WriteCRegister(FMC_SDRAM_DEVICE, FMC_SDRAM_CMD_AUTOREFRESH_MODE, 8); FMC_SDRAM_WriteCRegister(FMC_SDRAM_DEVICE, FMC_SDRAM_CMD_LOAD_MODE, 0); FMC_SDRAM_SetAutoRefreshNumber(FMC_SDRAM_DEVICE, 8); FMC_SDRAM_ProgramRefreshRate(FMC_SDRAM_DEVICE, 1386); // 90MHz 下刷新计数 }这段代码里最容易被忽略的是CASLatency和RefreshRate。CAS 设小了会读出错数据，设大了浪费带宽；刷新计数算错，跑几分钟后屏幕开始闪。参数说明：SDClockPeriod选 2 分频是因为 180MHz 直接给 SDRAM 太高，多数板子走线撑不住；ReadPipeDelay用 0 是保守做法，如果读数据不稳定可以试 1 或 2。
LTDC 这边，显存直接指向 SDRAM 的一段地址，层配置里注意WindowX/Y不要超出屏幕分辨率，否则会出现撕裂。屏幕跑通之后，再往上叠 LVGL，任务里只做lv_timer_handler()，不要在中断里刷界面。
3. 多任务划分与通信协议：FreeRTOS 下怎么让采集、控制、屏幕不打架
3.1 任务优先级和栈大小怎么定
智能家居主控的任务不算多，但优先级排错就会出玄学问题。我一般这样分：
| 任务 | 优先级 | 栈大小 | 周期/触发 |
|---|---|---|---|
| 传感器采集 | 3 | 512 | 2s 周期 |
| 控制执行 | 4 | 512 | 事件触发 |
| 通信解析 | 5 | 1024 | 队列触发 |
| 屏幕刷新 | 2 | 2048 | 30ms |
| 看门狗喂狗 | 1 | 256 | 1s |
采集任务优先级不能太高，否则会打断通信解析；屏幕刷新栈要给够，LVGL 内部有递归调用。下面是一个典型的采集任务骨架：
// 传感器采集任务：周期读取，数据入队 void SensorTask(void *argument) { SensorData_t data; for (;;) { // DHT22 读取，失败重试 3 次 if (DHT22_Read(&data.temp, &data.humi) == HAL_OK) { data.dev_id = DEV_DHT22; data.timestamp = xTaskGetTickCount(); // 队列满则丢弃最旧数据，避免阻塞采集 if (xQueueSend(g_sensor_queue, &data, pdMS_TO_TICKS(10)) != pdPASS) { SensorData_t old; xQueueReceive(g_sensor_queue, &old, 0); xQueueSend(g_sensor_queue, &data, 0); } } vTaskDelay(pdMS_TO_TICKS(2000)); } }逻辑说明：采集任务只负责「读 + 入队」，不做任何判断和显示，这样后面换传感器不影响其他任务。参数上，pdMS_TO_TICKS(10)是入队超时，给太长会拖慢采集周期；队列满时丢最旧数据，是防止某次通信卡住导致整个系统雪崩。
3.2 自定义协议帧格式与解析
本地设备之间通信，我一般用一套简单的二进制帧，比 JSON 省 RAM 也省解析时间：
// 帧格式：帧头(2) + 设备ID(1) + 命令(1) + 长度(1) + 数据(N) + 校验(1) typedef struct { uint16_t header; // 0xAA55 uint8_t dev_id; uint8_t cmd; uint8_t len; uint8_t data[32]; uint8_t checksum; // 前面所有字节异或 } Frame_t; // 解析函数：返回 0 成功，-1 失败 int Frame_Parse(uint8_t *buf, uint16_t size, Frame_t *out) { if (size < 6) return -1; if (buf[0] != 0xAA || buf[1] != 0x55) return -1; out->header = 0xAA55; out->dev_id = buf[2]; out->cmd = buf[3]; out->len = buf[4]; if (out->len > 32 || size < 6 + out->len) return -1; memcpy(out->data, &buf[5], out->len); uint8_t sum = 0; for (int i = 0; i < 5 + out->len; i++) sum ^= buf[i]; if (sum != buf[5 + out->len]) return -1; out->checksum = sum; return 0; }参数说明：帧头用0xAA55是为了和常见文本数据区分；长度字段限 32 字节，够放传感器数值和控制指令；校验用异或，实现简单，如果通信环境差可以换成 CRC16。解析时先判长度再判校验，避免越界读。
3.3 屏幕交互与状态同步
屏幕任务不要直接去读传感器队列，而是订阅一份「系统状态快照」。我一般用一个全局结构体加互斥锁：
// 系统状态快照，屏幕只读这份数据 typedef struct { float temp; float humi; uint8_t relay_state[4]; uint8_t online; } SysState_t; SysState_t g_state; SemaphoreHandle_t g_state_mutex; // 更新状态时加锁 void State_Update(SensorData_t *d) { xSemaphoreTake(g_state_mutex, portMAX_DELAY); if (d->dev_id == DEV_DHT22) { g_state.temp = d->temp; g_state.humi = d->humi; } xSemaphoreGive(g_state_mutex); }这样屏幕刷新和采集解耦，LVGL 只负责把g_state画出来。注意锁的持有时间要短，不要在锁里做浮点运算或字符串格式化。
4. 避坑与排查：那些让 F429 智能家居主控翻车的细节
4.1 屏幕花屏、随机死机
现象：上电后屏幕偶尔花屏，跑几分钟后死机，复位后又正常。原因：SDRAM 时序参数偏紧，或者 LTDC 和 SDRAM 抢带宽。解决：先把 SDRAM 时钟降到 90MHz 以下试，CASLatency从 3 改 2 再试；LTDC 层用双缓冲，显存地址对齐到 32 字节；如果还不行，检查 PCB 走线等长。
4.2 继电器动作时 MCU 复位
现象：每次继电器吸合，MCU 就复位或通信中断。原因：继电器线圈反电动势通过电源串扰。解决：继电器线圈并联续流二极管，光耦隔离前后电源分开，MCU 供电加 100uF 和 0.1uF 去耦；软件上继电器动作前后关中断几十微秒，避开最脏的瞬间。
4.3 DHT22 读数偶尔为 0 或 85
现象：温湿度偶尔读到 0 或者 85。原因：DHT22 时序对中断敏感，FreeRTOS 调度或通信中断打断了微秒级延时。解决：读 DHT22 时关调度器vTaskSuspendAll()，读完再开；或者用硬件定时器捕获。85 通常是上电首次读取，丢弃第一次数据即可。
4.4 队列满了之后系统变慢
现象：跑一段时间后屏幕卡顿，采集还在跑。原因：某个任务消费队列慢，队列堆积，内存碎片增加。解决：队列长度按最大突发量设计，消费端加超时；如果数据可以丢，用覆盖式队列；定期用xPortGetFreeHeapSize()看剩余堆，低于 20% 就要查内存泄漏。
4.5 看门狗喂狗位置不对
现象：系统正常但偶尔被看门狗复位。原因：喂狗放在高优先级任务里，低优先级任务卡死时喂狗还在跑。解决：喂狗放在最低优先级任务，并且检查所有关键任务的「心跳标志」，只有全部置位才喂狗。
5. 进阶技巧：把本地主控做成可扩展的网关
5.1 用事件组做任务间同步
当设备变多之后，队列和信号量会显得零散。我习惯用一个事件组来汇总系统状态：
// 事件组位定义 #define EVT_SENSOR_READY (1 << 0) #define EVT_NET_ONLINE (1 << 1) #define EVT_RELAY_CHANGED (1 << 2) EventGroupHandle_t g_events; // 通信任务等待多个事件 void CommTask(void *argument) { EventBits_t bits; for (;;) { bits = xEventGroupWaitBits(g_events, EVT_SENSOR_READY | EVT_NET_ONLINE, pdTRUE, pdTRUE, pdMS_TO_TICKS(1000)); if ((bits & (EVT_SENSOR_READY | EVT_NET_ONLINE)) == (EVT_SENSOR_READY | EVT_NET_ONLINE)) { // 两个条件都满足才上报 Report_To_Cloud(); } } }pdTRUE, pdTRUE表示等待成功后清除标志、并且要求所有位都满足。这样通信任务不用轮询，逻辑也集中。
5.2 参数保存与掉电恢复
智能家居最怕掉电后配置全丢。F429 可以用内部 Flash 模拟 EEPROM，或者外挂 AT24C02。我一般把配置放在 Flash 最后一页，写入前先擦除，写入时做双备份：
| 区域 | 内容 | 大小 |
|---|---|---|
| Config_A | 设备列表、阈值 | 1KB |
| Config_B | Config_A 的镜像 | 1KB |
| Flag | 有效标志和 CRC | 16B |
上电时先读 Flag，CRC 对就加载，不对就切到镜像。写入时先写镜像再写主区，避免写一半掉电。
5.3 用 RTT 或串口做日志分级
调试阶段最有用的是日志。我一般分三级：ERROR 只打异常，INFO 打状态变化，DEBUG 打数据流。用宏控制编译：
#define LOG_LEVEL 2 // 0=ERROR, 1=INFO, 2=DEBUG #if LOG_LEVEL >= 2 #define LOG_DEBUG(fmt, ...) printf("[D]" fmt "\r\n", ##__VA_ARGS__) #else #define LOG_DEBUG(fmt, ...) #endif发布版本把LOG_LEVEL降到 0，省 Flash 也省 CPU。RTT 比串口快，不占 UART，适合实时看任务切换。
5.4 一个我常犯的错
早期我总想把所有功能塞进一个任务，觉得「省栈省切换」。结果一次 DHT22 读失败，整个系统卡住，屏幕也不刷新。后来强制自己按「采集、控制、通信、显示」拆开，每个任务只做一件事，出问题一眼就能定位。现在我的习惯是：新加一个功能，先问它属于哪一层，再决定放哪个任务，绝不在中断里做业务。希望帮到你。
本文还有配套的精品资源，点击获取
