这套STM32智能家居语音控制系统的思路其实特别直接你对语音模块说一句“打开客厅灯”模块把这句话翻译成一串串口指令STM32收到指令后翻转对应引脚的电平继电器吸合灯就亮了。整条链路里没有云平台参与没有App转发完全本地运行响应速度能做到说出口就执行。本文就围绕这个项目把硬件选型、语音方案、代码架构、原理图设计、仿真验证以及烧录排错一次性讲透。先说清楚这篇东西适合谁。如果你是刚学完STM32基础外设、想找个完整项目练手的学生或者准备拿嵌入式方向做毕业设计、想做一个“有点复杂度但又不至于失控”的课题再或者你就是想把宿舍的灯光和风扇改成语音控制那这套系统非常合适。它覆盖了一个嵌入式项目最常见的几大模块串口通信、中断接收、状态机解析、GPIO控制、继电器驱动以及原理图和仿真验证。这些东西拆开看都很基础但串成一条完整链路之后你会发现自己对“单片机怎么跟外部模块协作”这件事的理解会上一个台阶。1.1 系统功能边界这套系统的基础功能是语音控制多路电器开关比如客厅灯、卧室灯、风扇、窗帘电机。语音识别模块负责听懂指令通过UART把指令发出去STM32作为决策中心解析指令并驱动继电器。它的核心能力有这几点离线语音识别不需要联网也没有云服务费用支持自定义唤醒词和命令词比如唤醒词“小管家”命令词“打开客厅灯”“关闭风扇”等多路继电器输出扩展性强后续想控制更多设备只需加继电器和GPIO口可选配OLED显示屏显示当前设备状态或者接DHT11温湿度传感器做环境监测语音播报温度项目本身的可玩性很高尤其适合在此基础上继续叠加功能。我见过有人在这个框架上加了烟雾报警联动检测到异常就语音提示并自动断电也有人接了ESP8266模块做了一套MQTT远程手机控制跟语音控制形成双通道。1.2 适合谁不适合谁这套方案的定位很明确它走的是“离线、本地、快速响应”的路线对标的是完全不同的场景。如果你追求的是远程控制——下班路上用手机App提前开空调那需要的是ESP8266/ESP32加云平台或者干脆用Home Assistant这类开源智能家居系统来整合设备。如果你追求的是跟天猫精灵、小爱同学那种自然对话体验问天气、问时间、点歌那必须依赖智能音箱的云端技能本地离线模块做不到。所以这个系统更像是一个嵌入式实践项目它的价值在于让你完整走一遍“传感器输入-主控决策-执行器输出”的开发流程而不是让你去跟商业智能音箱比生态。想清楚这一点你就不会在开发过程中陷入“为什么它不能像天猫精灵那样聪明”的执念。1.3 开源仓库里应该有什么既然项目标题里点明了“代码原理图仿真”一个完整的开源项目就应该给到三样东西smart-home-voice/ ├── firmware/ # STM32固件工程 │ ├── Core/ # 主逻辑含main.c、中断处理、命令解析 │ ├── Drivers/ # 标准外设库或HAL库文件 │ └── MDK-ARM/ # Keil工程文件 ├── hardware/ # 硬件设计 │ ├── schematic.pdf # 原理图PDF │ ├── bom.csv # 物料清单 │ └── PCB文件立创EDA导出 ├── simulation/ │ └── proteus/ # Proteus仿真工程 └── README.md # 接线说明、引脚定义、烧录步骤我的建议是拿到开源项目之后先看README再看原理图最后碰代码这个顺序能帮你少走非常多弯路。很多人一上来就把固件工程里所有文件看一遍结果被一堆启动文件和中间层库绕晕了实际上核心代码就那么几个文件。2. 硬件选型为什么是F103C8T6加SU-03T硬件选型是决定项目难度和鲁棒性的第一步这里我不展开所有可能的方案只讲为什么这个组合最适合做语音控制的“最小可行系统”。2.1 主控芯片的选择逻辑STM32F103C8T6是很多人接触的第一个ARM Cortex-M3芯片72MHz主频64KB Flash20KB RAM片上资源对于本项目来说完全够用甚至有点富余。为什么不用更大资源的芯片因为没必要。这个项目里STM32要做的事情就三件从串口收数据、解析协议、翻转GPIO。这属于非常轻量级的负载CPU占用率可能都不到5%。用F405、F407那些高性能芯片并不会带来体验上的提升只会让功耗变高、Layout更复杂、成本翻倍。真正要关注的其实是Boot引脚和调试接口。C8T6这个封装通常是蓝色Pill开发板或者自制核心板SWD接口只引出四条线SWDIO、SWCLK、3.3V、GND。这四条线在原理图设计时必须优先保证布线短、不绕圈因为后续所有程序下载全靠它。还有一点容易被忽略芯片的VBAT引脚如果不用外部电池建议直接接3.3V不要悬空。悬空可能导致内部RTC和备份寄存器供电不稳前期没什么感觉但项目跑久了容易出现极端情况下的复位异常。2.2 语音识别芯片三条路线语音识别是整个项目中技术含量最高的模块市面上的方案大体有三类方案成本开发难度离线能力延迟推荐度离线语音识别模块SU-03T等20-30元低用官方工具配置命令词即可完全离线低百毫秒级最适合本项目MCUWiFi模组云端语音API40-60元高需要网络协议栈、接口对接、账号申请依赖网络中等与网络质量相关适合进阶扩展智能音箱智能插座较高低但无法体会嵌入式开发过程依赖生态低玩成品偏应用我最终选择了SU-03T这类离线方案核心原因是它把“语音识别”这件事封装成了黑盒子对外只暴露串口这极大地降低了项目的软件开发量。你只需要在PC端配置好唤醒词和命令词烧录进模块之后它就会在识别到指令时通过UART发出预设的数据帧主控的活儿是解析这些帧而不是做语音算法。有人会觉得用现成语音模块显得“技术含量不够”但工程项目的本质是解决问题不是重新发明轮子。你自己从零训练一个语音识别模型嵌入到系统里那不是这个量级项目该干的事。先跑通系统再逐步替换局部模块这才是合理的演进路径。2.3 继电器驱动电路不能省的部分STM32的GPIO输出电流只有几毫安而继电器线圈的驱动电流通常在30-100mA之间所以绝对不能把继电器直接接到GPIO上。标准的驱动方式是用一个NPN三极管做开关级以S8050为例单片机引脚PA0输出高电平经过一个1kΩ电阻接到三极管基极三极管导通继电器线圈得电吸合。发射极接地集电极接继电器线圈的负端线圈正端接5V。线圈两端必须反向并联一个1N4148二极管吸收关断瞬间的感应电动势不然反向尖峰电压非常容易击穿三极管的集电极和发射极。这里的几个关键参数值得展开说。基极电阻的取值有一个原则保证三极管进入饱和区而不是放大区。S8050的电流放大倍数在100倍左右继电器线圈电流按50mA计算那么基极电流至少需要0.5mA。单片机GPIO高电平约3.3V三极管VBE约0.7V那么基极电阻R (3.3 - 0.7) / 0.5mA 5.2kΩ取1kΩ也可以饱和更深驱动更可靠。如果你买的是现成的继电器模块里面通常已经带了三极管驱动电路和光耦隔离那么STM32引脚直接接模块的IN端就行。但需要注意模块是高电平触发还是低电平触发这两个逻辑在代码里是完全相反的不仔细看丝印很容易做出“开关起反作用”的效果。3. 语音识别方案怎么落SU-03T定制与协议选型语音模块选定了接下来就是真正把它用起来。这一节的实操性很强建议你手里有一块模块跟着操作没有的话先把流程记住也行。3.1 SU-03T命令词定制流程SU-03T是安信可推出的一款低成本离线语音识别模块核心卖点是无需联网、可定制唤醒词和命令词。定制流程大概分几步去官网下载语音配置工具在PC上打开新建产品选择“定点唤醒命令词”识别方案录入唤醒词比如“小管家”可以打断唤醒和连续唤醒录入命令词比如“打开客厅灯”“关闭客厅灯”“打开风扇”“关闭风扇”等为每个命令词配置串口输出内容选二进制或ASCII格式生成固件通过USB转TTL工具烧录到SU-03T模块里这里有一个看似不起眼但非常容易踩的坑烧录固件时模块供电必须稳定。建议用5V供电进行烧录因为配置工具和USB转TTL的供电能力都不太强如果模块在烧录途中掉电固件就会写坏表现为上电后无提示音或识别无反应。遇到这个情况重新烧录一次通常能解决。烧录完成后先用串口助手单独测一下模块。把模块的TX接到USB转TTL的RX模块的RX接USB转TTL的TX共地打开串口助手波特率设为115200或9600说唤醒词激活模块然后说命令词看串口助手是否能收到对应的数据。这一步骤在接STM32之前做能把“语音识别问题”和“单片机电平问题”区分开。3.2 为什么我坚持用二进制帧而不是ASCII文本语音模块支持向串口发两种数据格式一种是可读的ASCII字符串比如发“LED_ON”另一种是二进制帧比如发0xAA 0x55 0x01 0x01 0x57。我强烈建议用二进制帧原因很简单可解析性和容错性。ASCII文本串虽然人类看着直观但解析它需要做字符串匹配还得考虑每帧之间的分隔符、大小写、空格等问题。比如“LED_ON”如果因为传输原因变成“LED_ON\r\n”你的代码就要处理车符换行如果因为噪声多了一个字符你的匹配逻辑可能就乱了。而二进制帧有固定的帧头、命令位、数据位、校验位长度固定即使某个字节错了校验和也能发现并丢弃这一帧。从实际调试经验来看家里的空调、电视、WiFi路由器都会产生杂散噪声语音模块到主控之间走线稍微长一点串口线上就可能串入干扰。有校验的二进制帧在这种环境下比ASCII串靠谱得多最多丢帧绝不会误触发。3.3 在线语音API方案对比与后续升级替代如果你不想用现成的离线语音模块想走“ESP8266云端API”路线也可以但这套方案的工作量不是一个量级要申请语音识别服务账号拿到API Key和Secret KeyESP8266要录音并通过HTTP或WebSocket上传音频等云端返回识别文本再解析文本下发控制指令。整个过程涉及WiFi配网、HTTP客户端、JSON解析、Token刷新。识别延迟取决于网络少则几百毫秒多则几秒。从项目演进的角度我建议先跑通离线语音方案把系统框架搭好再考虑把语音识别模块替换成ESP32。ESP32自带的麦克风接口可以采集音频并做简单的本地关键词检测也可以把音频上传到云端识别灵活性比“固定命令词的离线模块”高很多。但那就是另一个项目了不建议在一开始就混合在一起做。4. 固件代码架构语音指令如何变成继电器动作这一部分是整个项目的灵魂。硬件只要照着原理图接线一般不会出大问题真正决定系统稳不稳定的是数据从串口进来之后怎么被解析、怎么被分发到GPIO动作上。4.1 帧协议设计格式、校验与容错我定义了一套简化版协议帧长度固定5字节结构如下字节位置含义示例字节0帧头10xAA字节1帧头20x55字节2命令码0x01表示开客厅灯0x02表示关客厅灯字节3数据位0x01表示通道1字节4校验和前4字节累加后取低8位校验和的计算逻辑校验字节 (0xAA 0x55 命令字节 数据字节) 0xFF。比如“打开客厅灯”的完整帧就是AA 55 01 01 57。为什么校验要这么设计因为累加和是最简单、计算速度最快、又能覆盖绝大多数单比特错误的校验方式。如果追求更强的检错能力可以上CRC16但对于控制灯的指令来说累加和已经足够没必要为多余的复杂度买单。4.2 状态机解析比直接判断数组更稳很多新手拿到串口数据后会这样处理定义一个数组接收整个帧接收完了再比对数组内容。这在低速、近距离、无干扰的场合可能能用但只要一次接收过程中前一个字节错了后续所有字节都会错位而且错位后没法自动恢复。用状态机接收则完全不同。它每收到一个字节只判断“当前在哪个阶段”匹配失败就直接回到帧头等待状态不会卡死typedef enum { ST_WAIT_HEAD1, ST_WAIT_HEAD2, ST_WAIT_CMD, ST_WAIT_DATA, ST_WAIT_CHECK } FrameState; static FrameState frameState ST_WAIT_HEAD1; static uint8_t recvCmd, recvData, recvCheck; void HandleUartByte(uint8_t byte) { switch (frameState) { case ST_WAIT_HEAD1: if (byte 0xAA) { frameState ST_WAIT_HEAD2; } break; case ST_WAIT_HEAD2: if (byte 0x55) { frameState ST_WAIT_CMD; } else { frameState ST_WAIT_HEAD1; } break; case ST_WAIT_CMD: recvCmd byte; frameState ST_WAIT_DATA; break; case ST_WAIT_DATA: recvData byte; frameState ST_WAIT_CHECK; break; case ST_WAIT_CHECK: recvCheck byte; if (recvCheck (uint8_t)(0xAA 0x55 recvCmd recvData)) { HandleVoiceCommand(recvCmd, recvData); } frameState ST_WAIT_HEAD1; break; default: frameState ST_WAIT_HEAD1; break; } }这里要注意一个容易被忽略的容错逻辑在ST_WAIT_HEAD2状态下如果收到的第二个字节不是0x55不能简单丢弃后回到原点而应该把当前字节跟帧头重新比对。为什么因为0xAA可能刚好是前一帧的最后一个字节如果你直接回到ST_WAIT_HEAD1这个0xAA就永远匹配不上了后面的数据会全部错位。异步串口数据流里这是最常见的丢同步场景写状态机的时候一定要处理。在STM32上串口接收建议用中断方式。HAL库提供了一个很有用的回调函数HAL_UART_RxCpltCallback每次收到一个字节就调用一次回调再把句柄重新开启接收void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART1) { HandleUartByte(rxData); HAL_UART_Receive_IT(huart1, rxData, 1); } }中断接收的字节间隔很短一帧5字节可能在几百微秒内就收完了所以状态机切换和回调函数的处理必须快不要在中断里做耗时操作或者更稳妥的方法是先在中断里把字节存入环形缓冲区然后在主循环中取出来解析。4.3 命令表驱动与GPIO动作解析得到命令码之后下一步是执行动作。最直接的做法是写一个switch-case命令码1就开灯1命令码2就关灯1命令码3就开灯2……但如果设备多了这种写法会让代码越来越长每加一路设备就要改一遍逻辑。更好的做法是用命令表驱动模式。定义一个结构体数组每个元素保存命令码和对应要执行的函数指针typedef void (*CommandHandler)(void); typedef struct { uint8_t cmd; CommandHandler handler; } CommandEntry; static void Light1_On(void) { HAL_GPIO_WritePin(LIGHT1_GPIO_Port, LIGHT1_Pin, GPIO_PIN_SET); } static void Light1_Off(void) { HAL_GPIO_WritePin(LIGHT1_GPIO_Port, LIGHT1_Pin, GPIO_PIN_RESET); } static const CommandEntry cmdTable[] { { 0x01, Light1_On }, { 0x02, Light1_Off }, { 0x03, Fan_On }, { 0x04, Fan_Off }, }; void HandleVoiceCommand(uint8_t cmd, uint8_t data) { for (int i 0; i sizeof(cmdTable) / sizeof(cmdTable[0]); i) { if (cmdTable[i].cmd cmd) { cmdTable[i].handler(); return; } } }这种写法的好处是新增一个设备只需要在数组里加一行同时补充对应的GPIO控制函数解析逻辑完全不用动。整个代码的可维护性、可读性都会好很多。GPIO控制时还有一个细节要提如果你买的继电器模块是低电平触发那么GPIO输出逻辑要反过来。比如模块的低电平触发表示“输入低电平继电器吸合”那代码里“开灯”要写GPIO_PIN_RESET“关灯”要写GPIO_PIN_SET。建议把所有控制逻辑封装成Semantic层比如把开灯定义为Application层动作不跟底层GPIO电平直接耦合这样不会因为硬件改了一版就把主逻辑全翻一遍。4.4 工程目录组织与裸机调度这个项目的体量其实不适合直接上FreeRTOS裸机大循环加中断就够了。主循环里做三件事处理环形缓冲区里的串口帧、刷新OLED显示、扫描按键。语音帧解析天然是事件驱动的来一帧处理一帧根本不需要抢占式调度。我见过不少初学者动不动就上RTOS结果任务之间同步、互斥、信号量反而把自己绕晕了。判断是否用RTOS的标准很简单如果你的系统里没有“两个任务必须同时跑”的硬实时需求裸机够用就别上。当后续要同时处理联网、音频、多组传感器时再考虑RTOS那时候你对任务划分的理解也会更清楚。工程的推荐目录结构可以是CubeMX生成的标准结构在Core/Src下面新增voice_protocol.c、command_table.c、app_control.c各模块职责单一。5. 原理图设计的几个关键点最小系统、继电器与电源这一节讲原理图但不会罗列所有连接关系重点讲最容易出错、也最能体现设计功底的几个点。5.1 STM32最小系统的固定画法STM32F103C8T6的最小系统包括电源、时钟、复位、启动模式四部分。电源部分VDD每个引脚就近接100nF去耦电容VDDA建议串一个10Ω磁珠再接3.3VVBAT接3.3V。这里最容易犯的错误是所有去耦电容集中放在一起而不是靠近每个电源引脚。虽然原理图上看不出来区别画PCB的时候就会发现布局很难受。时钟部分8MHz晶振接OSC_IN和OSC_OUT两个引脚各接一个大约20pF的负载电容到地。注意晶振电路要尽可能靠近MCU引脚走线不要过长否则容易起振困难。32.768kHz低速晶振如果不用RTC功能可以不画省两个电容。复位部分NRST引脚接一个10kΩ电阻上拉至3.3V再接一个100nF电容到地构成经典复位电路。电容的作用是上电瞬间拉低NRST完成复位之后慢慢充电达到高电平让芯片进入运行状态。启动模式部分BOOT0引脚通过10kΩ电阻下拉到地保证从Flash启动。BOOT1引脚通常直接接地或悬空即可因为只有系统存储器启动模式才需要BOOT1配合。5.2 继电器驱动与隔离如果你自己画继电器驱动电路前面提到过的NPN三极管方案是最简洁的。如果想用现成的ULN2003达林顿管阵列它可以一路同时驱动多路继电器自带续流二极管集成度更高。项目中我推荐“每路继电器独立驱动”的画法因为故障隔离更好。某一路负载短路烧坏了三极管换一个元件就行比换一片ULN2003便宜也更快。继电器驱动部分要注意的是触点侧。继电器触点控制的是220V市电这属于强电部分画原理图时一定要把强电和弱电的间距拉开铺铜要安全绝缘接线端子要有防触摸设计。如果你没有强电经验建议先用LED或者直流小电机做负载来验证逻辑不要一上来就接220V灯具。5.3 电源树设计3.3V与5V的地怎么走系统的电源输入一般来自USB 5V或者12V适配器。5V进来之后给继电器线圈供电同时通过一颗AMS1117-3.3降至3.3V给MCU和语音模块供电。电源树设计时最关键的规则是3.3V的地和5V的地是同一个地但大电流路径不能穿过MCU的模拟地。具体来说继电器吸合瞬间线圈电流变化很快如果这个大电流回路经过了MCU附近的细地线会在3.3V上产生地弹噪声严重时MCU会复位。解决办法是单点接地所有功率地线先汇聚到电源输入端的GND再从同一个点分出MCU区的信号地。原理图阶段就要标注清楚网络名的层次建议把功率地命名为GND_PWR信号地命名为GND在电源输入处用0Ω电阻或者直接连到同一网络。6. 仿真验证与上电排错先让逻辑跑通再信硬件仿真在这类项目里的价值经常被低估。很多人觉得仿真没什么用直接焊实物调结果代码逻辑有问题时很难分清是硬件问题还是软件问题。反过来先在仿真环境里把协议解析和GPIO动作逻辑跑通上电调试时就能把问题范围锁定在硬件这一层。6.1 Proteus仿真能干什么不能干什么Proteus可以仿真STM32F103C8T6支持GPIO、串口、定时器等常见外设行为。但它没有SU-03T这种语音模块的模型所以常规做法是用Virtual Terminal虚拟终端来模拟语音模块发出串口指令。Proteus仿真最大的坑在于Virtual Terminal发送的是ASCII字符不能直接发送0xAA这种二进制字节你从键盘输入的内容会按ANSI编码解释。所以我提供两种更靠谱的仿真验证方式第一种在固件里加一个“演示模式”。上电后主函数先按顺序填入几帧测试数据交给状态机解析再驱动LED模拟继电器动作。这样仿真里不需要模拟外部输入直接观察串口调试输出和LED翻转结果即可。第二种用Proteus的COMPIM组件搭配虚拟串口工具从真实PC串口发送原始字节。这种方式更接近实际但操作复杂度高一些还得处理虚拟串口配对新手不推荐。仿真通过只能说明代码逻辑没有问题不保证实际硬件上电就能用。仿真环境里不会有接线错误、不会有电平不匹配、不会有EMI干扰。把这层认知放好仿真验证的意义在于提前找逻辑Bug不在于替代实测。6.2 Wokwi在线仿真Wokwi是目前对嵌入式学习者比较友好的在线仿真平台。它支持STM32F103C8T6浏览器里就能搭建电路不需要装Proteus那么大的软件。Wokwi的优势是启动快、界面干净、支持LED和串口监视器。但就我实测的体验它更适合Arduino框架下的快速验证对STM32 HAL库工程的支持并不那么顺滑。如果你用的是寄存器版或者标准外设库Wokwi里跑起来相对容易HAL库工程涉及很多底层初始化和时钟配置容易出兼容问题。实际项目中我更推荐这样组合用Wokwi快速验证协议解析状态机的逻辑速度用Proteus做完整硬件链路的仿真演示最终以上电实测为准。6.3 “no stm32 target found!”排查链路这个报错坑过无数人而且在不同环境下原因完全不同。先给一个通用排查链路按顺序执行基本都能解决步骤检查项处理方法1ST-Link驱动是否正常打开设备管理器看是否有未识别设备或感叹号。有感叹号就重装驱动ST-Link的Virtual COM Port驱动问题也很常见2SWD接线是否正确SWDIO接SWDIO、SWCLK接SWCLK、GND接GND3.3V接3.3V。很多自制核心板丝印标反了接通前后用万用表量一下引脚电压3目标板供电是否正常如果板子没有独立供电ST-Link的3.3V输出电流通常只有几十mA带不动整板就会出现识别失败。给板子单独供电把ST-Link和板子共地即可4芯片是否处于读保护状态用ST-Link Utility的Connect Under Reset功能连接操作路径是Target - Settings - Mode - Connect Under Reset5上述步骤都无效用STM32CubeProgrammer尝试Full Chip Erase如果还不行检查固件里是否配置了SWD引脚复用比如把PA13/PA14当普通GPIO用了我在一次调试中碰到过最隐蔽的情况代码里把SWDIO对应的PA13引脚初始化成了普通推挽输出导致ST-Link连接时引脚被拉死报错就是“no stm32 target found”。解决办法是用Connect Under Reset在芯片复位瞬间擦除固件恢复正常调试接口。还有一个经常被忽略的点你用的ST-Link可能是盗版克隆版固件版本太旧Keil或者STM32CubeProgrammer新版本不认识它。解决方法是升级ST-Link固件或者换一个驱动兼容性更好的调试器。这个问题在国产开发板里特别常见因为很多板载ST-Link其实是用STM32F103模拟的。7. 从零复刻需要准备的所有东西看到这里你已经理解了系统原理和代码逻辑剩下的就是把所有零件买齐、接线、烧录、调试。这一节给出可以直接照做的清单和步骤。7.1 物料清单与预算物料规格参考价格说明STM32F103C8T6开发板蓝色Pill或自制核心板约10元如果用自制的需要额外买芯片约4-6元语音识别模块SU-03T约25元含咪头和扬声器接口继电器模块5V单路或多路模块每路约3-5元注意高/低电平触发USB转TTLCH340约5元烧录语音模块和查看调试信息用ST-Link V2下载调试器约15元烧录STM32用杜邦线公对公、公对母若干约5元调试阶段免焊接电源USB 5V电源或充电器现成给整板供电负载演示设备LED灯条、小风扇现成不建议新手直接接220V灯具其他面包板、电阻、导线约10元S8050、1N4148、1k电阻等总预算在80到100元之间这比买一套完整开发套件便宜而且你还能完全理解每个模块的作用。7.2 参考接线表这是标准的接线配置各硬件之间的连接关系如下SU-03T模块TXD - STM32 USART1_RXPA10SU-03T模块RXD - STM32 USART1_TXPA9SU-03T模块GND - STM32 GND继电器模块IN1 - STM32 PA0继电器模块IN2 - STM32 PA1继电器模块VCC和GND - 5V和GNDST-Link SWDIO - STM32 SWDIOPA13ST-Link SWCLK - STM32 SWCLKPA14ST-Link GND - STM32 GND如果语音模块和STM32之间电压域不同建议都控制在3.3V。SU-03T是支持3.3V供电的最好不要一边3.3V一边5V否则RX/TX之间还要加电平转换电路增加不少麻烦。7.3 建议的调试顺序和我踩过的坑调试顺序决定了你能不能在半小时内定位问题还是花费整个下午跟错误较劲。我的建议是分层调试自底向上第一步先给STM32烧一个最简单的LED闪烁程序验证开发板、ST-Link、Keil工程链路完整。这里很多新手第一次就卡住了因为下载器和板子根本连不通。第二步把串口打印调通。刚才的LED闪烁程序里加一段USART初始化每500ms向串口助手打印一个“Hello”验证串口通信链路完好。这一步注意USB转TTL的RX接STM32的TXTX接STM32的RX两个GND必须相连。第三步把语音模块接上。先用USB转TTL单独测SU-03T确认它能在语音触发时发出正确的串口帧。把模块输出的帧内容记录下来跟代码里配置的命令码比对防止模块端配置跟固件端协议不一致。第四步语音模块接回STM32发指令看串口调试信息能否正常解析。这一步不要接继电器减少变量。我看到串口正确打印出解析结果后再接继电器。第五步接继电器和负载做整机联调。这套流程的核心思路是每次只引入一个不确定因素。如果你跳过第一二步直接把整套系统接起来一旦出现问题你可能要在驱动、接线、串口、协议、继电器电路之间反复排查效率非常低。最后分享一个非常个人的经验这个项目真正难的点从来不是某个引脚怎么接、某句话怎么识别而是你怎样把一个简单的功能拆分成清晰的层次——硬件层、驱动层、协议层、应用层。跑通这套语音控制链路之后你已经掌握了嵌入式项目里最通用的分层设计思路后续不管接什么新传感器还是新屏幕都只是往这个框架里添砖加瓦而已。