STM32离线语音控制智能家居实战：从原理图到Proteus仿真与实物调试

不用怀疑，这个项目的开源价值就在于：它不是那种只跑个流水灯的教学例程，也不是PPT里画饼的“演示Demo”，而是一套真正能落地到家里的智能家居语音控制系统。主控用的还是经典得不能再经典的STM32F103C8T6，外挂离线语音识别模块，配合继电器组控制灯光和家电，全程不需要联网、不需要手机App、不需要云端服务器。我把它拆成“代码 + 原理图 + 仿真”三件套，从零开始讲清楚每一块是怎么设计的、为什么这么设计，以及在Proteus仿真和实物调试中各踩过哪些坑。

这套方案适合谁？如果你是电子类/嵌入式方向的在校生，正在为毕业设计找一套有完整工程文件、能讲清楚原理的项目，那这篇就是照着抄作业级别的参考；如果你是刚入门STM32的爱好者，想搞明白“语音控制”到底是怎么从麦克风声音变成继电器动作的，这篇也会用大白话把链路讲透。

废话不多说，直接开整。整个工程的核心设计思路，我先把话撂在这——能离线就别联网，能用串口就别折腾协议栈，能用现成模块就别自己堆料。这套“三个能”原则贯穿了整个项目从选型到调通的每一步。

1. 方案选型复盘：为什么是F103C8T6 + 离线语音模块这个组合

很多人一听到“语音控制智能家居”，第一反应就是上ESP32 + 讯飞在线识别SDK，或者搞个树莓派跑离线唤醒。但我在实际做这个项目时，反而选了最朴素的一套组合，而且用完之后我觉得这对组合在“教学价值”和“工程稳定性”上是最平衡的。

1.1 主控芯片选择背后的逻辑

STM32F103C8T6这颗芯片，网上叫它“蓝丸”或者“C8T6小板”，48引脚、64KB Flash、20KB RAM，放在2025年看性能并不算强，但它有一个其他芯片给不了的优势：生态资料密度极高，踩坑成本极低。

• 库函数和HAL库的例程多到发指，不管是寄存器操作还是标准外设库，随便一搜就是全套；
• 3.3V供电、内部8MHz晶振经过PLL倍频到72MHz，跑语音模块的串口解析和继电器逻辑绰绰有余；
• 市面上几乎所有仿真工具（Proteus、Wokwi、SimulIDE）都原生支持F103C8T6的模型，这对我们后面做仿真验证至关重要。

说得直白一点，用F103C8T6做这个项目，几乎等于把“毕业设计答辩被老师问倒”的风险降到最低，因为它的每一个外设（USART、GPIO、定时器、I2C）你都能找到大量现成资料来佐证设计思路。

有人可能会问，为什么不用ESP32？理由其实很直接：这个项目不需要联网能力。一旦引入Wi-Fi和云端语音识别，项目的复杂度会瞬间上升一个量级，你要处理网络重连、音频流上传、JSON解析、Token鉴权……这些对学习STM32本身没有帮助，反而会淹没掉“主控调度 + 外设控制”这条主线。

1.2 语音识别方案：离线语音模块的三大优势

我用的是LD3320离线语音识别模块的进阶版本——SU-03T离线语音模块，它和传统LD3320最大的区别在于：不需要你手动训练声学模型，直接用串口AT指令配置唤醒词和命令词，然后模块内部就完成了识别和响应，通过串口把识别结果以特定帧格式发给STM32。

举个实际配置例子，我在模块后台配置了如下命令词表：

这套方案比LD3320优势明显：

1. 离线识别，词条自定。SU-03T支持最多50条命令词，不需要联网，识别准确率在安静环境下能到95%以上；
2. 串口直出结果，主控零负担。语音识别这种重活、累活，模块自己干完了，STM32只负责在串口中断里收几个字节再解析，压力小得可以忽略不计；
3. 价格便宜，开发周期短。一个SU-03T模块零售价大概在20元到30元之间，而同样支持离线命令词的硬件方案动辄上百元。

当然它也有局限，比如不支持自定义唤醒词以外的连续对话、识别距离一般在3到5米、对近似的词容易误触发。但这些局限放在“智能家居灯光/风扇控制”这个场景里完全可以接受，毕竟没有人会站在5米外喊“开灯”还要保证99%准确。

1.3 硬件架构总览：从麦克风到继电器，信号是怎么流起来的

整个系统的信息流其实特别简单，我在设计原理图时也是按这条链路展开的：

声音 → SU-03T模块麦克风 → 模块内离线识别 → 串口TX发送指令帧 → STM32F103C8T6的USART1_RX → 主控解析指令帧 → GPIO输出高/低电平 → ULN2003达林顿管驱动 → 继电器线圈吸合/释放 → 220V交流回路通/断 → 灯具/风扇得电/失电

这张图的精妙之处在于：语音识别边界和功率驱动边界彻底分离了。语音识别模块工作在3.3V逻辑域，继电器输出侧控制220V强电，中间靠ULN2003把STM32 GPIO的电流能力放大，再靠继电器的物理隔离把强弱电分开。这个设计不仅是安全的，而且逻辑层次清晰，出问题好排查。

具体到引脚分配，我用了这组映射：

后面所有代码逻辑，都是围绕着这张引脚映射表展开的。

2. 原理图设计要点：电源、驱动、隔离，一个都不能省

原理图部分我尽量不堆砌“行业套话”，就讲几个我在画图时真正反复斟酌过的节点。这些节点在Proteus仿真里看着不起眼，真到了实物焊接和调试阶段，全部会成为决定成败的细节。

2.1 电源树设计：3.3V逻辑域和5V驱动域的分与合

系统里存在两个电压域，这是新手最容易忽略的：

• 3.3V域：STM32的VDD、SU-03T模块的VCC、复位电路、Boot配置引脚；
• 5V域：继电器线圈供电、ULN2003驱动级供电（COM引脚）。

我在原理图里的设计是：外部输入统一用5V直流，经一个AMS1117-3.3把5V降到3.3V供给逻辑域，而不是让两个电压域各自为政。这么做的原因是：

1. 外部电源适配器（手机充电器、5V开关电源）大多输出5V，可以直接用；
2. AMS1117-3.3最大输出电流1A，STM32工作电流约50mA，SU-03T瞬间峰值电流（语音识别时）约100mA，加上其他外围，余量充足；
3. 继电器线圈标称5V，和外部输入电压同域，不需要额外的DC-DC升压电路。

这里有个非常关键的坑，我在第一版原理图里踩过：继电器线圈是感性负载，断电瞬间会产生反向电动势（也就是俗称的“反峰电压”），这个反峰如果直接怼到STM32的GPIO或电源上，轻则系统重启，重则烧芯片。所以必须在每个继电器线圈两端并联一个续流二极管（1N4007即可，注意方向：阴极接正极，阳极接负极），让线圈断电时电流从二极管续流泄放掉。这个细节Proteus仿真不一定体现得出来（毕竟仿真模型对感性负载的瞬态特性模拟有限），但实物板如果省了这四个二极管，基本等着炸。

2.2 语音模块串口连接中的电平匹配细节

SU-03T模块的逻辑电平是3.3V TTL，STM32F103的GPIO也是3.3V TTL，两者直连理论上没问题。但实际设计时，我仍然加了两个1kΩ串联电阻在TX和RX线上，作用有二：

• 限流保护：万一模块端或主控端的IO损坏短路，1kΩ电阻能把短路电流限制在3.3mA以内，不至于烧毁另一端的引脚；
• 信号振铃抑制：串口通信频率不高（我用的9600波特率，属于低速信号），串联电阻可以略微降低信号边沿的过冲，尤其是在杜邦线连接较长（超过10cm）的时候，能明显减少数据帧误码。

有人会问，为什么不用光耦做串口隔离？我的看法是：语音模块和主控都在同一个3.3V逻辑域，共地，没有隔离需求。光耦用在串口上是画蛇添足，还白白增加功耗和信号延迟。只有强弱电交界处才需要隔离设计，这一点思路要清晰。

2.3 继电器驱动电路：ULN2003比三极管阵列强在哪

驱动继电器有很多种做法：直接用NPN三极管（如S8050）、用ULN2003达林顿管阵列、用MOS管。我最终选了ULN2003，没有别的原因，就是省心、耐造、逻辑简单。

ULN2003内部是7路达林顿管，每路能承受最大500mA的灌电流，而5V继电器线圈的吸合电流一般在70mA到100mA之间，余量充足。更重要的是：

• ULN2003自带续流二极管（内部集成），虽然我外部还是加了1N4007双保险，但即使外部忘焊，芯片内部结构也能保护前级电路；
• 输入兼容TTL电平，STM32的GPIO直接推3.3V就能让它完全导通；
• 一片搞定两路继电器，剩下几路还能留作备用，后期想扩展窗帘电机、加湿器，引脚和驱动能力都现成。

接线方式是：STM32的PB0、PB1分别接ULN2003的1B、2B输入脚，ULN2003的1C、2C输出脚接继电器线圈的负极，线圈正极接5V。注意这里必须是“灌电流”接法：电流从5V→线圈→ULN2003的C脚→内部达林顿管→GND，而不是继电器线圈一端接GND、一端接ULN2003输出。接反了继电器永远不吸合，这是新手经常犯的错。

3. 代码架构：状态机驱动的串口指令解析与执行

代码部分我直接用标准外设库（Standard Peripheral Library）写的，没用HAL库。原因很私人的——这个项目核心逻辑不到500行，用标准库能把每一个寄存器的操作看得明明白白，对学习和讲解来说更友好。你要用HAL库也能跑，但下面的分析思路完全通用。

工程文件结构如下：

SmartHome/ ├── Core/ │ ├── main.c │ ├── stm32f10x_it.c │ └── system_stm32f10x.c ├── Hardware/ │ ├── uart_driver.c/h // 串口1驱动，接收语音模块数据 │ ├── relay_driver.c/h // 继电器控制 │ ├── led_status.c/h // 状态指示 │ └── key_scan.c/h // 按键扫描（备用控制） ├── App/ │ ├── cmd_parser.c/h // 指令解析状态机 │ └── device_manager.c/h // 设备执行管理 └── MDK-ARM/

3.1 串口接收：为什么不能用简单的阻塞接收

语音识别模块通过串口往STM32发数据，数据是不定长帧，以FD开头，00 01是设备ID，00 01/00 00是开关状态。在这里，最忌讳的做法就是裸奔一个HAL_UART_Receive或者标准库的USART_ReceiveData在那死等，因为语音识别模块什么时候发数据完全随机，你阻塞等待，主循环里其他逻辑全部卡死。

正确做法是串口中断接收 + 队列缓存。我在uart_driver.c中定义了一个环形缓冲区：

#define RX_BUFFER_SIZE 64 volatile uint8_t rx_buffer[RX_BUFFER_SIZE]; volatile uint8_t rx_head = 0; volatile uint8_t rx_tail = 0; void USART1_IRQHandler(void) { if (USART_GetITStatus(USART1, USART_IT_RXNE) != RESET) { uint8_t data = USART_ReceiveData(USART1); uint8_t next = (rx_head + 1) % RX_BUFFER_SIZE; if (next != rx_tail) // 缓冲区未满 { rx_buffer[rx_head] = data; rx_head = next; } // 缓冲区满了就丢包，不处理 } }

这样设计的好处是：语音模块哪怕连续发10条指令，也不会因为主循环在处理继电器动作而丢帧。主循环只需要在空闲时检查rx_head != rx_tail，然后逐字节取出解析即可。

我这套环形缓冲区代码看着简单，但它解决的是一个很本质的问题：外设随机事件和主控顺序执行的矛盾。中断负责“接住”数据，主循环负责“消化”数据，两者通过队列解耦。你以后做任何带串口通信的嵌入式项目，这个模式都能直接复用。

3.2 指令解析状态机：从字节流到有效动作的完整链路

拿到串口字节流之后，下一步就是解析。我用的方法是一个经典的四状态状态机，状态转移条件非常直观：

typedef enum { WAIT_HEAD_1, // 等待第1个帧头 FD WAIT_HEAD_2, // 等待第2个帧头 00 WAIT_DEV_ID, // 等待设备ID WAIT_CMD // 等待命令数据 } ParserState; static ParserState state = WAIT_HEAD_1; static uint8_t recv_dev_id = 0; static uint8_t recv_cmd = 0; void CmdParser_Process(uint8_t byte) { switch (state) { case WAIT_HEAD_1: if (byte == 0xFD) state = WAIT_HEAD_2; break; case WAIT_HEAD_2: if (byte == 0x00) state = WAIT_DEV_ID; else state = WAIT_HEAD_1; // 帧头校验失败，回到初始 break; case WAIT_DEV_ID: recv_dev_id = byte; state = WAIT_CMD; break; case WAIT_CMD: recv_cmd = byte; CmdParser_Execute(recv_dev_id, recv_cmd); // 执行动作 state = WAIT_HEAD_1; // 回到初始，等待下一帧 break; default: state = WAIT_HEAD_1; break; } }

这段逻辑的核心价值在于容错。如果语音模块因为供电波动发出了一帧错误数据，比如帧头不是FD 00，状态机会自动回到WAIT_HEAD_1重新同步，绝不会把错位的数据当成有效指令执行。这在真实项目中非常重要——一套家居系统如果因为一帧损坏数据就误开电器，用户对你的信任度瞬间归零。

3.3 指令执行层：GPIO操作与设备状态管理

解析出设备ID和命令之后，就进入设备管理层。我刻意把执行动作和指令解析拆成两个模块，这样以后新增设备（比如加一路窗帘控制）只需要改device_manager.c，解析部分完全不用动。

void CmdParser_Execute(uint8_t dev_id, uint8_t cmd) { switch (dev_id) { case 0x01: // 电灯 Relay_SetLight(cmd == 0x01); break; case 0x02: // 风扇 Relay_SetFan(cmd == 0x01); break; case 0x03: // 场景模式 if (cmd == 0x01) // 卧室模式：开灯、关风扇 { Relay_SetLight(1); Relay_SetFan(0); } else // 睡眠模式：关灯、关风扇 { Relay_SetLight(0); Relay_SetFan(0); } break; default: break; } } void Relay_SetLight(uint8_t on) { if (on) { GPIO_SetBits(GPIOB, GPIO_Pin_0); LED_Status_Set(LED_ON); } else { GPIO_ResetBits(GPIOB, GPIO_Pin_0); LED_Status_Set(LED_OFF); } printf("Light: %s\r\n", on ? "ON" : "OFF"); }

你注意我在每个动作后面都留了一条串口打印，方便调试时在PC上用串口助手观察系统到底执行了什么。这个习惯强烈建议保留，调试日志是嵌入式项目里性价比最高的“仪器”，比逻辑分析仪还常用。

3.4 定时器加入去抖和超时机制：让系统更抗干扰

代码里还有一个容易被忽略的模块：TIM2定时器做按键扫描去抖和语音指令超时检测。语音识别模块虽然离线识别准，但人说话总有停顿，如果用户在说“打开电灯”中途顿了一下，模块可能把“打开”和“电灯”识别成两条独立指令，产生误动作。我的处理是在设备管理层加了一个短指令过滤窗口：

// 200ms窗口内如果收到两条语义相同的指令，只执行最后一条 #define CMD_WINDOW_MS 200 static uint32_t last_cmd_time = 0; static uint8_t last_dev_id = 0; int CmdParser_ShouldExecute(uint8_t dev_id, uint8_t cmd) { uint32_t now = TIM_GetCounter(TIM2) / 10; // 假设TIM2每10ms中断一次 if (now - last_cmd_time < CMD_WINDOW_MS && dev_id == last_dev_id) { // 窗口内的重复指令，丢弃 return 0; } last_cmd_time = now; last_dev_id = dev_id; return 1; }

这个功能听起来“高级”，但本质只是一个时间戳判断，很好理解。它在实际使用中很管用——把“语音误触发”这个智能家居最大的体验痛点从代码层面抑制住了。

4. Proteus仿真搭建：没有实物也能完整验证全部逻辑

原理图和代码聊完了，接下来是仿真部分。我这里用的是Proteus 8.13，仿真文件里包含F103C8T6、虚拟串口、LED指示灯（代替继电器和灯）、一个用来模拟语音模块输出的“信号源”。

4.1 如何用Proteus模拟语音模块的随机指令输入

Proteus里当然没有SU-03T的模型，但这不妨碍我们验证主控逻辑。我用的是Proteus的Virtual Terminal + 串口模型：在仿真图上放置一个COMPIM串口模型，把它和STM32的PA9/PA10交叉相连，然后在COMPIM属性里配置和实际硬件一样的9600波特率。这样，PC上的串口助手往虚拟串口发任何数据，STM32仿真模型都能收到，逻辑和实物完全一致。

我在调试时的操作流程是：

1. 打开VSPD（Virtual Serial Port Driver）创建一对虚拟串口，比如COM3和COM4；
2. Proteus里的COMPIM选COM3；
3. PC上的串口助手打开COM4；
4. 串口助手里手动发送FD 00 01 00 01，观察仿真板上PB0连接的LED灯是否点亮。

这一步跑通了，就说明代码的串口接收和指令执行逻辑是对的。后续想要更逼真的效果，可以写个小脚本每隔几秒自动发送一条随机指令，模拟真人语音指令到来的节奏。

4.2 仿真与实物的核心差异：哪些验证了也没用，哪些必须靠仿真

这里我要说点掏心窝的话：Proteus仿真对这个项目的作用边界，必须心里有数。

说得直白一点，Proteus适合验证的是：

• 代码逻辑是否跑得通（串口收发的字节流、状态机的跳转、GPIO输出的电平变化）；
• 引脚映射是否有冲突（比如不小心把PB0和PB1都用成复用功能，仿真会直接报错）；
• 时序是否合理（比如继电器动作间隔过短，可以通过LED闪烁频率看出来）。

Proteus不适合也根本验证不了的是：

• 强弱电隔离的实际效果（仿真里的继电器模型不会真的被220V打火）；
• 语音识别的准确率（仿真里根本没有麦克风）；
• 电源纹波、信号完整性、电磁干扰（这些是模拟域问题，Proteus的数字仿真模型覆盖不了）。

所以我的结论是：仿真用来“验逻辑”，实物用来“验工程”，两者是接力关系，不是替代关系。你在仿真上跑通了，不等于焊完板子就能用；但你在仿真上跑不通，实物一定跑不通。用这个心态去做，就不会对仿真工具产生不切实际的期待。

4.3 仿真文件里的F103C8T6配置：晶振、时钟、调试接口

还有一个仿真细节值得单独提醒：Proteus里的STM32模型默认时钟配置和你的Keil工程可能不一致。Keil工程里如果你是通过SystemInit()把系统时钟配置到了72MHz，那仿真模型里也必须给STM32模型设置相应的外部晶振频率（通常填8MHz），否则串口波特率会发生分频误差，导致收发乱码。

具体操作用的是Proteus里双击STM32芯片模型，在“Clock Frequency”属性里填8000000（8MHz），并且确保你的代码里RCC_PLLConfig(RCC_PLLSource_HSE_Div1, RCC_PLLMul_9)是正确的。这个坑我见过很多人卡了一下午——代码逻辑跟答案一样，就是串口收不到正确数据，最后发现是仿真模型的时钟频率和代码里的PLL倍频系数对不上。

5. 系统联调与实测：从“仿真跑通”到“实物稳跑”的九个关键点

仿真再漂亮，最终还是要落到实物。我在调这个项目的过程中，把遇到的问题和解决思路整理成了一份“排障清单”，每次有读者来问问题，我基本都能对号入座。

5.1 供电、接线、模块配置的“老三样”问题

如果实物上电后系统完全没反应，先不要怀疑代码，按优先级查这三处：

• 电源电压和电流是否足够。SU-03T语音识别瞬间电流能到150mA左右，两个继电器同时吸合需要额外200mA，再加上STM32和LED，整个系统峰值电流保守估计在400mA以上。市面上很多劣质USB线压降极大，5V进去到板端可能只剩4.2V，AMS1117输出3.3V会掉到3.0V以下，STM32直接跑飞。实测下来，强烈建议用12V/1A以上电源适配器接板载稳压，或者至少用质量过关的USB线配5V/2A适配器。
• 语音模块有没有完成唤醒配置。SU-03T第一次使用必须先通过配套的PC工具烧录词条配置，否则上电只会播放默认提示音，不会对任何命令词响应。很多人拿到模块直接接线，以为和STC89C52那种单片机一样上电就能跑，结果自然是什么反应都没有。
• 串口TX/RX有没有接反。这个错误老手也会犯。记住一条铁律：模块的TX接主控的RX，模块的RX接主控的TX。用万用表量一下模块空闲时的TX引脚电压，如果稳定在3.3V左右，说明模块供电正常；如果量出来是0V，大概率模块没启动或已经损坏。

5.2 继电器误动作与GPIO上电默认状态

这个坑非常隐蔽，而且是“仿真完全不存在、实物必现”的典型。STM32的GPIO在上电复位瞬间，所有引脚都是浮空输入状态，在这个短暂窗口内PB0/PB1的电平是不确定的。如果继电器驱动电路是高电平吸合，而这个浮空电平恰好被ULN2003识别为高，继电器就会在上电瞬间“啪”地吸合一下，甚至直接保持吸合。

解决办法是在代码初始化的最早阶段（main()一进来，SystemInit()之后立刻）就把PB0、PB1强制拉低：

void Relay_Init(void) { GPIO_InitTypeDef GPIO_InitStructure; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB, ENABLE); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0 | GPIO_Pin_1; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOB, &GPIO_InitStructure); GPIO_ResetBits(GPIOB, GPIO_Pin_0); GPIO_ResetBits(GPIOB, GPIO_Pin_1); }

还有一点，GPIO外接的继电器驱动级最好选用“低电平吸合”的接法（继电器线圈一端接5V，另一端接ULN2003输出，控制端给高电平时驱动管导通、线圈才有电流），这样即使上电瞬间GPIO浮空成高阻，ULN2003输入端没有可靠高电平也不会导通，继电器不会乱动。我后来已经把新版本的原理图改成这种“安全默认”设计。

5.3 语音识别距离和唤醒词调优建议

系统跑通之后，你第一个想干的事肯定是在家里实际喊两声试试。这时候会遇到几个体验问题：

• 识别距离不够。SU-03T模块本身用的是板载麦克风，虽然灵敏度不错，但我实测在安静客厅，正对模块3米内识别率才有保障，超过3米或者有电视声音干扰，识别率会明显下降。如果你对识别距离有更高要求，可以考虑外接带前置放大器的麦克风阵列，或者把模块放在房间中央靠上的位置，避开遮挡。
• 唤醒词误触发。我最初配置的唤醒词是“你好小智”，结果发现家里人说“你好”或者“小智”的时候，模块也会被唤醒，而且会错误地拾取后面的语句。后来我换成了“小智管家”这种四音节唤醒词，误触发率明显下降。唤醒词尽量选四个字、声调起伏明显的词，不要选日常高频词汇，这条经验对任何离线语音模块都适用。
• 命令词不要过于相似。比如“打开电灯”和“打开电风扇”里面都有“打开电”，模块容易出现歧义。我在配置命令词表时就把“打开电风扇”改成了“风扇打开”，把“打开电灯”改成了“灯光打开”，识别准确率一下子就从85%提到了95%以上。

5.4 程序升级与调试的接法预留

最后一个建议可能有点“过来人”的感觉，但真的很值：在原理图阶段就预留好SWD调试接口和USART1的扩展排针。SWD只需要SWDIO、SWCLK、GND三个引脚，占用极少，但有了它你就可以随时用ST-Link连上去烧录和单步调试；USART1扩展排针则可以让你在不干扰语音模块通信的情况下，临时接一个USB转TTL模块到PC上看日志。

我见过太多人画PCB时图省事，把调试接口全砍了，结果程序跑飞一次就得吹下芯片重新烧，调试效率低到怀疑人生。嵌入式开发里，调试接口的优先级应该和电源接口平起平坐。

6. 源码和工程文件的使用说明：拿到手怎么跑起来

工程包里的文件结构、每个文件的职责、以及从下载到跑通整个流程，我这里做一个收尾式的梳理。这部分内容适合当你已经看完前面的原理、准备动手复现时，直接照着操作。

1. 解压工程包，确认目录结构包含Hardware、App、Core、MDK-ARM四个文件夹；
2. 用Keil MDK（我用的版本是5.36，兼容5.20以上）打开MDK-ARM/SmartHome.uvprojx；
3. 在Options for Target里确认芯片型号是STM32F103C8，并在Debug选项卡里选择你的调试器（ST-Link或J-Link）；
4. 如果使用ST-Link，在Settings里把Flash Download勾选“Reset and Run”，这样烧录完自动复位运行；
5. 编译，零警告零错误之后，连接ST-Link和单片机，点击下载；
6. 打开串口助手，连接你的USB转TTL模块到PA9/PA10，波特率9600；
7. 给语音模块烧录好命令词表（用模块配套工具），上电唤醒后喊“小智管家”；
8. 听到模块回应后，说“灯光打开”，观察串口助手应该收到FD 00 01 00 01，同时继电器1吸合、灯亮；
9. 全部验证通过，再把系统集成到你准备好的220V灯具和风扇回路里。

我在工程包根目录还放了一个README.md，里面写了每个文件的作用和当前已知的注意事项，你拿到手可以先花十分钟过一遍再动手。

我个人在实际操作中的体会是，这个项目最值得研究的地方反而不是语音识别本身，而是**“一个外设事件驱动的系统，如何用可靠的状态机架构去响应”**。语音模块只是提供了一个“触发源”，真正体现嵌入式开发功底的，是那套串口环形缓冲区、命令解析状态机、指令执行管理层的分层设计。这套设计模式你吃透了，以后做任何带通信功能的嵌入式项目——不管是蓝牙遥控、Wi-Fi控制还是CAN总线设备——都能直接平移过去。

最后再分享一个小技巧：如果你在做实物调试时手头没有5V继电器，可以用LED灯和蜂鸣器先顶上，代码不用改任何一行，因为驱动的是同一个GPIO。等你把逻辑层面全部验证完了，再把继电器和220V负载接上去，这样既安全又高效。先小功率验证逻辑，再大功率验证工程，这套节奏能让你少走一半弯路。