STM32智能家居语音控制系统开源实战：离线语音+Proteus仿真全解析

做智能家居相关项目，很多人第一步就卡在方案选择上：既想要语音控制的新鲜感，又不想投入太多成本，同时还得保证稳定性和可复现性。我这次开源的STM32智能家居语音控制系统，选的就是一条比较务实的路线——主控用STM32F103C8T6，语音识别走离线模块，硬件只保留灯光、风扇、温湿度监测这几个核心场景，全部资料包括代码、原理图和Proteus仿真工程一起打包。目标是让新手拿到手能看懂、能烧录、能复现，同时给有经验的朋友留出二次开发的扩展点。

这套系统的价值不在于“炫”，而在于把语音、传感、执行、显示这四件事用最扎实的方式串在一起。语音不是简单接个模块读几个字，而是通过串口协议把识别结果解析成结构化指令；控制不是无脑置高拉低，而是用状态机管理多路设备的开关模式和联动逻辑；仿真也不是摆个样子，而是可以在没有实物的情况下把串口指令、传感器数据、外设响应完整跑通。接下来我从方案选型开始，把整个设计逻辑、硬件接线、软件实现和调试过程逐一拆开讲。

1. 项目定位与方案选型：为什么这套组合最省心

1.1 语音识别方案：SU-03T 与 LD3320 之争

语音识别是整个系统的门面，选型直接决定体验。常见的离线方案有两种：一个是LD3320，一个是SU-03T（天问的离线语音模块）。LD3320是传统的语音识别芯片，需要自己维护词条、做关键词训练，配置过程繁琐，识别率也比较依赖录音环境；SU-03T则是新一代的离线语音模块，特点是出厂自带语音识别引擎，通过配套的上位机工具可以自由配置唤醒词、命令词和应答语，配置完直接生成固件烧进模块就行。

我最终选了SU-03T，核心原因是它的串口输出格式对单片机非常友好。模块识别到命令后，可以直接通过UART输出我们预设的JSON格式字符串，比如识别“开灯”就输出{"event":"light_on"}，识别“关灯”就输出{"event":"light_off"}。这意味着STM32这边只需要做串口解析，不用处理音频特征、不用跑神经网络，把复杂的语音识别任务完全隔离在模块内部。

SU-03T另一个优势是真正的“离线”。不需要连WiFi、不需要云平台，所有识别都在本地完成，响应速度在200ms以内，隐私性也好。智能家居领域很多人一上来就上云端ASR，但一旦断网整个系统就瘫痪，对于家庭内部这种相对稳定的环境，离线方案反而更可靠。

1.2 主控芯片与传感器搭配：F103C8T6 的性价比逻辑

主控用了STM32F103C8T6，也就是大家俗称的“C8T6蓝色 pill”。这颗芯片虽然已经发布十几年，但至今还是学生项目、DIY爱好者的首选，原因无外乎三个：便宜、资料多、够用。72MHz的主频、64KB Flash、20KB SRAM，对于语音指令解析、传感器读取、屏幕显示、多路GPIO控制这些任务来说绰绰有余。而且Proteus里有非常成熟的F103系列仿真模型，硬件和仿真可以无缝切换。

传感器搭配上，我选了DHT11温湿度传感器作为环境监测模块。坦白说DHT11的精度并不算高（温度±2℃，湿度±5%RH），但在智能家居这个场景下，用户关注的是“大概多少度、要不要开风扇”这个层面的信息，而不是精密仪器的读数。DHT11最大的优点是单总线协议、只需要一根数据线，非常适合用来演示GPIO模拟时序和底层驱动编写。如果你觉得精度不够，硬件电路里我预留了I2C接口，后续可以直接替换成SHT30或者AHT21。

显示部分用的是0.96寸OLED，I2C接口，四根线就能搞定。OLED的好处是自发光、对比度高、显示内容灵活，能同时显示温湿度、设备状态、语音指令提示，比LCD1602省IO口，也比数码管显示的信息量大得多。

1.3 系统整体架构与工作流程

整个系统的数据流是这样的：SU-03T语音模块作为唯一的“输入源”之一，识别到用户的语音命令后，通过串口把结构化指令发给STM32；STM32内部的解析器提取出事件类型，交给状态机处理；状态机根据当前设备状态决定是开灯、关灯、开风扇、关风扇还是切换模式；同时DHT11定时采集环境数据，OLED实时刷新显示。本地按键作为备用输入，防止语音模块偶尔抽风。

我画了一张逻辑框图方便理解（这里不是严格意义的电路图，而是功能模块的关系）：

[SU-03T语音模块] --UART--> [STM32F103C8T6] --GPIO--> [继电器模块] --> [灯光/风扇] [按键输入] --GPIO--> [STM32F103C8T6] --I2C--> [OLED显示屏] [DHT11] --单总线--> [STM32F103C8T6] --UART--> [调试串口/PC]

系统上电后自动进入待机模式，OLED显示当前温度和湿度，此时你说“小智小智”唤醒语音模块，然后说“打开客厅灯”，SU-03T匹配命令词后输出JSON，STM32解析出light_on事件，把继电器1拉高，灯光点亮，OLED状态区同步更新。整个过程不需要联网，从语音到动作的延迟在300ms左右，体验上很跟手。

2. 原理图设计：每一根线都有讲究

原理图这块我花了不少精力，很多人觉得C8T6接线简单，随便飞几根杜邦线就能跑，但实际上要把系统稳定跑起来，供电、电平匹配、隔离保护这些细节一个都不能省。开源文件里用的是KiCad工程，也导出了PDF版方便直接用AD查看。

2.1 最小系统与供电设计

STM32F103C8T6的最小系统包含这几个部分：8MHz主晶振（配两个20pF负载电容）、复位电路（10kΩ上拉电阻加0.1μF电容）、BOOT0下拉到地（确保从Flash启动）、VDDA和VDD引脚就近放置0.1μF去耦电容、VBAT直接接3.3V。这些都是常规操作，但我建议在晶振下方不要铺铜，避免寄生电容影响起振稳定性。

供电方面，系统统一用5V输入，经过AMS1117-3.3稳压得到3.3V给STM32、OLED和语音模块供电。这里有个常见坑：语音模块的峰值电流能达到200mA以上，如果电源纹波太大，模块会出现误唤醒或者识别率下降。所以我在AMS1117前后都加了10μF+0.1μF的滤波电容，5V入口加了一个SS34肖特基二极管做反接保护。继电器部分单独用5V驱动，和逻辑电源在布局上分开走线。

2.2 语音模块串口连接与电平匹配

SU-03T模块的串口电平是3.3V TTL，和STM32可以直接互连，不需要额外的电平转换芯片。接线很简单：SU-03T的TXD接STM32的PA10（USART1_RX），RXD接PA9（USART1_TX），GND共地。

但这里有一个细节很多人容易忽略：SU-03T的TXD在空闲状态是高电平，如果你用的是USB转TTL调试器去单独调试语音模块，部分调试器是5V电平，直接接会损伤模块。稳妥的做法是用3.3V供电的调试器，或者在TXD线上串联一个1kΩ电阻做限流保护。另外，语音模块的喇叭接口一定要接2W/8Ω左右的喇叭，千万别用小蜂鸣器凑合，音量会小到听不清唤醒提示。

2.3 DHT11与OLED的接线细节

DHT11的数据引脚接PB12，数据线和VCC之间必须接一个4.7kΩ到10kΩ的上拉电阻。DHT11用的是单总线协议，总线空闲状态是高电平，主机拉低发起通信时序，如果上拉电阻缺失，通信时序根本没法定起来。

OLED的SCL接PB6（I2C1_SCL），SDA接PB7（I2C1_SDA），VCC和GND接3.3V。OLED模块一般自带I2C上拉电阻，所以板子上不用重复加。如果遇到OLED显示异常，先用I2C扫描程序确认设备地址（0x3C最常见），再用逻辑分析仪看波形，但这两个问题在我开源的项目代码里都有对应的诊断例程。

2.4 继电器驱动：光耦隔离与续流二极管

继电器模块是整个系统中唯一涉及“强电”风险的部分，我在原理图设计时做了双重保护。第一重是光电隔离：MCU的GPIO输出先经过PC817光耦，光耦的输出再驱动三极管（S8050）控制继电器线圈。这样STM32和负载回路之间没有电气连接，即使负载端出问题也不会烧主控。第二重是续流二极管：继电器线圈两端并联1N4007，方向是反向并联，当线圈断电时给感性负载的感生电流提供泄放回路，否则瞬间的反向电动势会直接击穿三极管。

光照控制用的是低电平触发继电器模块还是一体式继电器？我这里用的是高电平触发的裸继电器+驱动电路。如果你买的是市面上常见的低电平触发继电器模块，那逻辑正好相反，需要把代码里GPIO_SetBits改成GPIO_ResetBits，这个在代码注释里我专门标了。

2.5 原理图绘制与PCB布线心得

原理图用KiCad画，各功能模块我用分页图区分：第一页是STM32最小系统，第二页是语音模块和调试串口，第三页是传感器和显示，第四页是继电器驱动和电源。这样别人看工程时能按模块理解，也方便后续增删功能。

PCB布线方面，虽然是双层板，但有几个原则建议遵守：主芯片下方尽量铺完整的地平面；晶振、去耦电容要靠近对应引脚；继电器驱动电路放在板子边缘，和天线（语音模块）拉开距离；强电区和弱电区的间距至少5mm以上。我第一版布局时把继电器和语音模块放得太近，结果每次继电器吸合，语音模块就有概率误触发，后来把继电器挪到板角才解决。

3. 软件实现：从串口解析到状态机控制

代码结构上我分成了几个模块：main.c负责初始化、主循环调度，usart.c负责串口收发和指令解析，dht11.c负责温湿度读取，oled.c负责显示，control.c里是状态机。整个工程用STM32标准外设库编写，没有上HAL，因为标准库的逻辑更直白，适合学习。如果你用CubeMX生成工程，IO配置参考表在项目文档里。

3.1 串口接收与SU-03T命令帧解析

SU-03T通过串口输出的JSON格式可以自定义，我的配置是：唤醒词“小智小智”，命令词包括“打开灯光”“关闭灯光”“打开风扇”“关闭风扇”“查询温湿度”，对应输出light_on、light_off、fan_on、fan_off、query_env这些事件字符串。

串口接收如果用最简单的单字节中断+缓存，逻辑清晰且不会丢数据。我定义了接收缓冲区rx_buffer，接收中断里把字节存进缓冲区，同时检测帧头{和帧尾}，完整收到一帧后置标志位，主循环解析：

uint8_t rx_buffer[64]; uint8_t rx_index = 0; uint8_t frame_ready = 0; void USART1_IRQHandler(void) { if (USART_GetITStatus(USART1, USART_IT_RXNE)) { uint8_t data = USART_ReceiveData(USART1); if (data == '{') { rx_index = 0; rx_buffer[rx_index++] = data; } else if (data == '}' && rx_index > 0) { rx_buffer[rx_index++] = data; rx_buffer[rx_index] = '\0'; rx_index = 0; frame_ready = 1; } else if (rx_index < sizeof(rx_buffer) - 1) { rx_buffer[rx_index++] = data; } } }

解析函数用strstr匹配关键字。这么做不需要引入cJSON库，省Flash资源，对固定格式的指令也足够用：

void parse_command(uint8_t *buf) { if (strstr((char*)buf, "light_on")) { control_set_device(DEVICE_LIGHT, SET_ON); } else if (strstr((char*)buf, "light_off")) { control_set_device(DEVICE_LIGHT, SET_OFF); } else if (strstr((char*)buf, "fan_on")) { control_set_device(DEVICE_FAN, SET_ON); } else if (strstr((char*)buf, "fan_off")) { control_set_device(DEVICE_FAN, SET_OFF); } else if (strstr((char*)buf, "query_env")) { display_show_env(dht11_read_temp(), dht11_read_humi()); } }

3.2 核心控制逻辑：状态机与模式切换

最简单的做法是在主循环里判断指令然后直接置GPIO，但我用了状态机，因为后续加“定时开关”“联动模式”这些功能会更方便。状态定义：

typedef enum { MODE_MANUAL, // 手动模式：语音/按键直接控制 MODE_AUTO // 自动模式：温度高于阈值自动开风扇 } system_mode_t; typedef struct { uint8_t light; // 0-关 1-开 uint8_t fan; // 0-关 1-开 system_mode_t mode; } system_state_t;

control_set_device是状态机入口，它先判断当前模式：手动模式下直接翻转对应位；自动模式下，语音指令只切换灯光，风扇由温度逻辑接管。温度阈值我设成28℃，温度每15秒采样一次，超过阈值且风扇没开就自动开启，低于阈值且风扇没关就自动关闭。

状态机的好处是让“输入来源”和“执行动作”解耦。语音、按键、定时器、温湿度变化都可以调用control_set_device，而真正的GPIO写操作集中在apply_state函数里，每个动作都有明确的日志输出，方便排查问题。

3.3 DHT11时序读取（GPIO模拟）

DHT11驱动是典型的GPIO模拟时序，没有太难的东西，但时序要求严格。完整读一次需要经历这些阶段：主机发送起始信号（拉低至少18ms），释放总线，等待从机响应（从机拉低80μs再拉高80μs），然后连续读40bit数据，高位在前，每bit以50μs低电平开头，26~28μs高电平为0，70μs高电平为1。

代码核心部分：

uint8_t dht11_read_byte(void) { uint8_t val = 0; for (int i = 0; i < 8; i++) { while (dht11_read_pin() == RESET); delay_us(40); if (dht11_read_pin() == SET) { val = (val << 1) | 1; } else { val = (val << 1) | 0; } while (dht11_read_pin() == SET); } return val; }

关键是最后那个while (dht11_read_pin() == SET)，它的作用是等待当前bit的高电平结束，确保下一个bit的低电平时钟信号能被正确识别。如果漏掉这一步，数据位就会错位，读出来的温湿度完全是乱码。

数据位读取完成后，校验位应该等于前四个字节之和的低8位。代码里我会校验，校验失败就直接返回上一次的缓存值，而不是把错误数据显示出来，这个细节对用户体验影响很直接。

3.4 OLED显示与菜单交互

OLED驱动我用的是SSD1306的经典软件I2C实现（也可以用硬件I2C，但靠软件模拟更稳）。主界面布局分三个区域：顶部显示系统状态（灯光、风扇的开关图标），中间大字显示温度，底部显示湿度。

注意SSD1306显存是1KB（128×64 bit），整屏刷新一次在模拟I2C下大概需要30ms。如果频繁全屏刷新，会有轻微的闪烁感。我的做法是只在数据变化时才刷新对应区域，比如温度从25.5变成25.6，只更新数字所在的矩形区域，这样既流畅又减少CPU开销。

按键交互方面，我接了两个轻触按键：KEY1短按切换灯光，KEY2短按切换风扇，KEY1和KEY2同时长按3秒切换自动/手动模式。按键扫描放在定时器中断里做消抖（20ms采样一次），避免在主循环里用delay消抖阻塞其他任务。

3.5 编译与烧录设置

工程编译环境是Keil MDK 5，芯片型号选择STM32F103C8，勾选“Use MicroLIB”，Flash烧录算法选64KB版本。调试器是ST-Link V2，SWD四线接法：SWDIO、SWCLK、GND、3.3V。

有一个编译相关的坑得提醒一下：使用标准外设库时，默认的SystemCoreClock是72MHz，如果你复制了其他工程没有修改系统时钟初始化，串口波特率会漂移。这个项目里我用的是标准库的SystemInit()，外部8MHz晶振经过PLL倍频到72MHz，串口1的波特率配置为115200，和语音模块保持一致。

4. Proteus仿真搭建：没有硬件也能先跑逻辑

这个项目的仿真文件是很多人关注的重点。我必须先说明一个事实：Proteus不支持SU-03T语音模块的仿真模型。所以仿真里的做法是，画一个STM32F103C8T6的最小系统，语音部分用虚拟终端（Virtual Terminal）代替——你在虚拟终端里手动输入{"event":"light_on"}，效果等同语音模块识别后通过串口发数据。

4.1 仿真工程与元件清单

仿真工程在Proteus 8.9及以上版本打开，元件清单包括：STM32F103C8T6、LED-RED（模拟灯光）、LED-GREEN（模拟风扇）、LM016L或LM044L液晶（我用的是LCD1602，OLED在Proteus里仿真效果一般，液晶更直观）、DHT11（Proteus自带的传感器模型，能模拟温湿度输出）、RESISTOR若干、CAPACITOR若干、POT-HG（模拟温度调节）。

DHT11在Proteus里的用法比较特殊，它有三个引脚：VCC、DATA、GND。双击DHT11模型，可以在属性里设定初始温湿度值，也可以通过滑动变阻器给DHT11的某个引脚接不同的电压来模拟温度变化。实际仿真时，我用一个电位器分压，调整电位器DHT11返回的湿度会改变，温度则固定在一个设定值。

4.2 用虚拟串口模拟语音模块

虚拟终端的配置要点：首先要在画布上放置一个VIRTUAL TERMINAL，双击设置波特率115200、8位数据、无校验、1位停止位。然后把虚拟终端的RXD接到STM32的PA9（USART1_TX），TXD接到PA10（USART1_RX）。

仿真时先在虚拟终端里点击一下窗口，让它获得焦点，然后直接输入{"event":"light_on"}（注意大小写），点击回车发送，观察STM32引脚输出：PA1控制的LED点亮，PA0控制的LED保持熄灭。如果发送{"event":"fan_on"}，PA0控制的LED点亮。虚拟终端里显示的内容还会包括STM32发来的日志信息，比如[INFO] light on、[INFO] temp=25.6 humi=60%，方便实时监控。

有一点需要注意：在Proteus里，连到STM32 RX引脚的虚拟终端必须在输入完所有字符后按回车，系统才会把缓冲区内容一次性送出，实际串口模块是一字节一字节发的。这个差异不影响逻辑验证，因为接收中断还是一样地逐字节处理。

4.3 仿真中常见的问题

仿真最容易出问题的就是程序“跑飞”。现象是虚拟终端收不到日志，LED没有任何反应。检查顺序：先确认晶振设置（双击STM32，External Crystal Frequency设为8M）、再确认芯片型号没有选错，最后看代码里的SystemInit是否把时钟超频到Proteus模型不支持的频率。

DHT11仿真经常出现湿度一直显示99%的问题，这是Proteus模型的一个已知限制。解决方法是双击DHT11，在模型属性里调整Humidity项的初始值和范围，有时候需要把Moisture输出引脚重新拖拽一下。另外，仿真里DHT11的数据线也要求有一个上拉电阻（4.7kΩ），没有上拉也会导致时序读取超时。

还有一个通用的提醒：Proteus仿真通过后，不代表硬件一定没问题。仿真验证的是“逻辑正确性”，比如状态机切换、串口协议解析、传感器数据处理流程；但实际硬件的电源纹波、信号干扰、模块兼容性这些问题，仿真一概测不出来。仿真和实体原型的定位是互补关系，不是替代关系。

5. 常见问题与排查技巧实录

5.1 ST-Link无法连接目标芯片

很多人在下载程序时遇到这个报错：error: no stm32 target found! if your product embeds debug authentication。我第一次看到这个报错也懵了一下。这个报错出现在ST-Link尝试通过SWD接口连接目标芯片但没收到有效回应的时候，常见原因有四个：接线错误、目标供电不足、芯片被读保护、SWDIO和SWCLK接反。

排查顺序建议是这样的：先确认ST-Link和板子共地，这是最容易被忽略的；然后用万用表量SWDIO和SWCLK引脚的电压，正常空闲状态是3.3V左右，如果量到0V，多半是引脚虚焊；接着看目标板是否单独供电，ST-Link的3.3V输出能力很弱，只有几百毫安，如果板上同时带了OLED、语音模块和继电器，经常带不动。

如果是芯片被读保护，用ST-Link Utility或者STM32CubeProgrammer执行全片擦除（Full chip erase）可以解除。注意这个操作会清掉Flash里的程序，重新烧录前要确保工程保存完毕。

5.2 语音模块识别率低和乱码

识别率低首先检查供电。SU-03T模块对电源噪声敏感，我曾经在开关继电器时观察到模块误唤醒，原因就是继电器线圈产生的电磁干扰耦合进了电源线。解决方法是继电器驱动改用光耦隔离，同时在语音模块的VCC引脚旁边加一个100μF电解电容+0.1μF陶瓷电容，实测识别率提升明显。

串口乱码则先确认波特率。SU-03T的默认串口波特率在配置软件里可以设置，我设置为115200。如果你收到的数据是一堆“éé*”，基本上STM32的波特率配置和模块不一致。还有一种情况是TX和RX接反了，现象是模块说话正常，但STM32完全收不到任何数据，用示波器或逻辑分析仪看TXD引脚是否有波形输出。

5.3 DHT11读数恒为0

硬件上先检查上拉电阻有没有焊接或者接好，没有上拉DHT11的data线始终为低，读回来的温度肯定是0。软件上检查延时函数精度，如果在GPIO翻转之间加了delay_us，但延时误差太大（比如用了普通循环且编译器优化等级不同），DHT11的时序就乱了。解决方法是把延时函数放进定时器中断基准或者用SysTick做微秒延时，避免编译器优化带来的误差。

还有一点，DHT11上电后需要至少1秒的稳定时间才能开始通信。如果程序一上电就立刻初始化DHT11，读出来往往是0或者错误。我习惯在DHT11初始化函数里先delay_ms(1500)，再执行复位时序，这个问题基本就消失了。

5.4 继电器误动作与干扰

继电器模块的驱动脚如果悬空，GPIO在STM32上电配置阶段会有一个短暂的浮空过程，可能导致继电器误吸合一下。我在GPIO初始化顺序上做了调整：先开启GPIO时钟，配置为推挽输出并默认输出低电平，再初始化其他外设。同时继电器驱动三极管的基极加了一个10kΩ下拉电阻，确保在GPIO没起作用的阶段三极管是截止状态。

另一个实际问题：继电器吸合瞬间，由于感性负载的特性，VCC可能会有小幅跌落，导致STM32复位。解决办法是继电器电源和MCU电源分开，或者至少保证总电源输入端的电解电容容量足够大（我用的是470μF）。如果条件允许，用独立5V电源给继电器供电，共地即可。

5.5 常见问题速查表

6. 扩展思路与个人体悟

6.1 从离线语音到物联网

这套系统的语音部分已经完全离线工作，但智能家居更大的想象空间是“联动”。比如通过ESP8266模块，把STM32接入MQTT服务器，手机端或Home Assistant端就能看到设备状态、远程下发指令。我建议的扩展路径是：在现有串口命令帧的基础上增加一个“网络通道”，ESP8266通过串口和STM32通信，用已有的JSON帧格式扩展事件类型，比如{"event":"remote_on","device":"light"}，这样语音和远程控制共用一套解析逻辑，改动量很小。

6.2 我在实际调试中的几个习惯

做这类项目这些年，我养成了几个习惯，供参考。第一，每个外设驱动都独立写一个自测函数，比如dht11_self_test()会连续读取10次并打印结果，OLED有oled_test()绘制全屏图案，接线验证的时候直接调用这些函数，比反复看代码定位问题快得多。第二，串口日志分级，我用[INFO]、[WARN]、[ERR]三个级别，平时把日志输出全开，排完问题后把串口重定向到调试口，不影响正常功能。第三，每次修改硬件接线，都会同步更新原理图和文档，哪怕只是把一个引脚从PA0改成PB0，否则三个月后回来看项目，你会完全想不起当初为什么这么接。

6.3 开源项目的文档与版本管理建议

既然项目开源了，文档就是用户体验的一部分。我这次组织的文件结构是：/hardware（KiCad工程和PDF原理图）、/firmware（STM32工程）、/simulation（Proteus仿真）、/docs（使用说明和接线表）、/tools（语音模块配置工具和固件备份）。版本管理用Git从第一天就拉起来，目前已经到v1.3，每个版本固定打tag，语音模块的固件配置也作为二进制文件一并入库，这样任何人拿到仓库都能完整复现出和发布者一致的效果。

最后分享一点个人体会：做开源项目，代码本身只占一半的价值，另一半是“别人能不能跑起来”。所以我会刻意把一些坑写进文档，比如继电器模块高低电平触发的差异、DHT11上电稳定时间、Proteus里DHT11模型的已知问题等等。一套开源资料，如果别人拿到能在一个晚上之内点灯并看到温度显示，那这个项目的意义就真正达成了。这套代码我后续还会持续维护，如果大家在复现过程中遇到文档里没写到的问题，欢迎在评论区交流，互相对一下解决思路，很多时候比自己闷头查要高效得多。