做语音控制类项目的人应该都遇到过这个尴尬51单片机只有一个硬件串口接了下载器就没法同时接语音模块想接多个设备只能硬切引脚来回折腾。我这次用LU-ASR01语音识别模块做离线语音控制一开始也被这个问题卡住了后来索性自己用普通IO口写了软串口配合天问Block的图形化开发环境把整个逻辑跑通。这篇文章就把这套完整方案记录下来怎么做软串口、怎么对接LU-ASR01、怎么实现双向通信附可以直接抄的完整代码。LU-ASR01是一块很常见的离线语音识别模块支持自定义唤醒词和命令词识别结果通过串口发给单片机同时它也能接收串口指令主动播放预置音频或者TTS语音。一边往上发识别结果一边往下收播放指令这就是标题里说的“双向通信”。51单片机这边我用天问Block搭图形化主逻辑再用C语言补软串口底层适合正在做语音控灯、语音控窗帘、语音播报这类项目的朋友也适合只想搞懂单片机软串口原理的初学者参考。1. 项目需求与整体方案选型1.1 为什么需要双向语音通信很多人做语音控制用的是“单向上报”方式语音模块识别到词串口发给单片机单片机执行动作完事。一开始我也觉得这样够了但真正用起来就会发现体验很别扭。你对着空气喊“开灯”灯亮了但你不知道它到底听没听见如果周围有点吵识别失败你还得再喊一遍完全不确定系统是否在工作。所以这套方案要做成双向语音识别模块把“用户意图”发给51单片机单片机执行完动作之后再反向发给语音模块一个“播放指令”让它用语音回应你。比如你说“打开客厅灯”LU-ASR01识别到命令词把结果帧通过串口发给5151解析出命令控制继电器或者三极管导通灯亮51再通过串口发一个“播放成功提示音/语音”的指令给LU-ASR01LU-ASR01播报“好的已打开客厅灯”这样一来用户能听到明确的系统反馈整个交互闭环就形成了。除了语音控制这种双向通道也能做很多事比如把单片机采集的温度、湿度、按键状态通过语音模块播报出来不只是单向控制而是让设备有“嘴”也有“耳朵”。1.2 软串口硬件串口到底够不够用51单片机里常见的STC89C52只有一个UART硬件串口这个串口通常被拿来干两件事烧录程序、和PC调试。如果你把硬件串口给了LU-ASR01之后每次下载程序都要拔线、跳线非常痛苦。而且很多时候你还想接个蓝牙模块、GPS模块、显示屏硬件串口根本不够分。这时候有两条路一条是换多串口的单片机比如STC15W系列学习成本低一点但如果你手头只有STC89C52的板子就得额外买芯片另一条就是我今天要说的软串口——用两个普通IO口在代码层面模拟UART的时序用软件实现波特率发送和接收。软串口看起来“土”但在低速场景下非常可靠。语音识别模块的串口速率一般是9600波特率数据量很小就是几个字节的短帧用软串口完全能跑稳定。它最大的价值是把你从接口数量限制里解放出来IO口多得是想开几路串口就开几路只要定时器够用。1.3 天问Block图形化搭逻辑C代码收底如果你直接拿Keil写51程序协议解析、状态机、串口中断全混在一起很容易乱。我这次用的是天问Block的图形化环境它最方便的地方是能直观地把“语音识别结果”和“动作响应”之间的逻辑关系拖出来像拼积木一样把主流程搭好然后自动生成C代码。天问Block对LU-ASR01支持得不错图形化积木里可以直接处理语音识别模块相关逻辑这样协议细节被封装了一层开发门槛低很多。但软串口属于底层通信天问Block虽然也提供了软串口积木实际项目里我还是习惯了直接看生成的C代码自己改底层的收发函数。这篇文章里我会把两部分的思路都说清楚图形化主逻辑怎么设计底层软串口代码怎么写。2. 软串口基础与LU-ASR01通信协议2.1 软串口的位时序与定时器选型串口通信的本质就是把一个字节按位、按固定时间间隔发出去。标准UART一帧包括1位起始位低电平、8位数据位、1位停止位高电平。9600波特率意味着每秒传输9600位所以1位的时间是1 / 9600 ≈ 104.17us。51单片机常用11.0592MHz晶振12T模式下机器周期 12 / 11.0592 ≈ 1.085us那么104.17us约等于96个机器周期。这个换算关系要记牢后面写延时函数和定时器初值都要用它。软串口有两种常见实现方式循环延时方式发送的时候按位翻转IO每个位之间调用延时函数接收的时候检测起始位下降沿然后用延时跳到数据位中点采样。优点是代码简单直观缺点是收发期间CPU被占住而且延时要算得准不能被高优先级中断打扰。定时器中断方式把定时器配置成波特率溢出模式在定时器中断里按状态机切换位接收时配合外部中断检测起始位。优点是CPU占用低、时序稳定缺点是逻辑复杂中断服务函数里不能干太多活。我建议初学者先跑通循环延时方式因为整个时序你能看得见摸得着出了错也好排查。等基础打牢了再上定时器中断方式做优化。51单片机的两个定时器如果用定时器T0做软串口的位定时T1可以空出来做其他事如果你还需要硬件串口T1还能继续用于给硬件串口产生波特率。2.2 LU-ASR01的接线与串口参数LU-ASR01模块的引脚一般包括VCC、GND、RX、TX有的版本还保留模拟输出、按键接口等。5V供电还是3.3V供电以你手头模块丝印和说明书为准大多数模块支持3.3V到5V宽电压51单片机IO电平是5V接TTL电平的语音模块没问题。但如果你用的是3.3V主控就要注意电平匹配必要时加电平转换。接线方式如下LU-ASR01的VCC - 5V或3.3V电源LU-ASR01的GND - 单片机GND必须共地LU-ASR01的TX - 单片机软串口RX引脚比如P1.0LU-ASR01的RX - 单片机软串口TX引脚比如P1.1模块串口参数一般是默认9600、8N1也就是8位数据、无校验、1位停止位。上电前先检查固件版本和配套配置工具确认波特率到底是多少有些语音模块出厂是115200后面忘了改排查半天才发现是波特率不匹配。2.3 双向通信的数据流设计所谓双向在我这个项目里实际包括两路数据流第一路是上行LU-ASR01识别到语音命令后通过TX把识别结果发出来。这个结果可能是一串协议帧里面包含命令序号、槽位值、校验码等。51单片机用软串口RX引脚一直接收在代码里做帧同步和命令解析。第二路是下行51单片机在合适时机需要让语音模块“开口说话”就通过软串口TX引脚发送播放指令给LU-ASR01的RX。LU-ASR01收到后从预置音频列表中找对应编号通过扬声器播报出来。设计数据流时我强烈建议把“上行解析”和“下行发送”用两个独立缓冲区分开。上行用环形队列或者固定数组存原始字节主循环里做解析下行则用队列缓存待发送指令。这样语音模块突然连续上报几帧数据时你也不会丢字节。3. 天问Block图形化搭建过程3.1 工程创建与引脚分配打开天问Block新建工程后选择对应的51单片机型号常用的是STC89C52RC或者STC15系列。不同型号的引脚定义和头文件略有差异但图形化积木操作基本一致。接下来在“引脚”面板里做分配P1.0分配为软串口RX用于接收LU-ASR01发送的识别结果P1.1分配为软串口TX用于给LU-ASR01发送播放指令P2.0分配为继电器控制引脚低电平导通用于控制灯光P2.1可以分配为状态指示灯闪烁表示串口通信正常引脚规划的关键软串口RX引脚最好选择支持外部中断的引脚比如P3.2或者P3.3这样后续如果升级成“中断检测起始位”方案会更方便。但我用P1.0做轮询接收也能跑只是代码上要多做判断。3.2 软串口积木配置天问Block的“串口”分类里提供了软件串口初始化、发送字节、发送字符串、接收等积木。实际操作时拖一个“软串口初始化”积木到初始化代码块设置波特率9600数据位8停止位1。在发送位置用“软串口发送字节数组”积木把要下发的指令按照协议填进去。在接收位置用一个循环不断读取软串口缓冲区判断是否收到完整帧。图形化积木封装了很多细节但你要清楚它背后生成的C代码长什么样。有一次我在天问Block里只设置了“软串口发送字符串”结果发送的是ASCII字符串不是我想发的十六进制字节帧查了好久才发现问题。所以涉及协议帧时尽量用“发送字节数组”积木不要拿字符串积木顶替。3.3 语音识别与状态机逻辑搭建图形化主流程我习惯这样排布初始化软串口初始化、IO引脚初始化、语音模块等待就绪主循环检查串口接收缓冲区有数据就进入帧解析帧解析判断帧头取出命令码执行对应的控制函数动作反馈控制灯、继电器或者其他外设后调用软串口发送播放指令用天问Block可以把这一步做成简单的状态机有“等待识别结果”“解析命令”“执行动作”“发送播报反馈”几个状态每个状态之间用条件判断跳转。图形化代码块的连线看起来比纯文本C代码直观很多调试的时候也能一眼看出逻辑卡在哪个分支。4. 完整代码实现与关键逻辑解析4.1 主流程与初始化代码下面给出的是一个基于STC89C52、11.0592MHz晶振、9600波特率的完整示例。软串口采用P1.0接收、P1.1发送主循环里轮询接收和解析。你可以直接复制到Keil里编译或者和天问Block生成的代码做对照。#include reg52.h #include intrins.h #define FOSC 11059200L #define BAUD 9600 // 软串口引脚 sbit SOFT_RX P1^0; // 接收引脚连接LU-ASR01 TX sbit SOFT_TX P1^1; // 发送引脚连接LU-ASR01 RX // 控制引脚 sbit LIGHT_PIN P2^0; // 低电平点亮 sbit LED_STATUS P2^1; // 状态指示灯低电平点亮 // 串口接收环形缓冲 #define RX_BUF_SIZE 16 unsigned char rxBuf[RX_BUF_SIZE]; unsigned char rxHead 0; unsigned char rxTail 0; // 下行指令缓存 unsigned char txFrame[8]; void DelayOneBit(void); void DelayHalfBit(void); void SoftUartSendByte(unsigned char dat); unsigned char SoftUartReceiveByte(void); void InitSystem(void); void ParseCommand(unsigned char cmd); void SendPlayCommand(unsigned char audioId); void ProcessRxData(void); void main(void) { InitSystem(); while(1) { ProcessRxData(); } } void InitSystem(void) { // 关闭所有中断软串口轮询期间不允许打断时序 EA 0; SOFT_TX 1; SOFT_RX 1; LIGHT_PIN 1; LED_STATUS 1; // 预留如果后续使用定时器在这里初始化 // 这里用纯延时方案所以只初始化IO和变量 rxHead 0; rxTail 0; DelayOneBit(); }注意我在初始化里直接EA 0因为循环延时方式的软串口对时序要求很严格一旦收发过程中进入中断位时间就被拉长波特率就跑偏了。如果项目里有其他中断必须开就建议改用定时器中断方案而不是继续用纯延时方案。4.2 软串口底层位延时与发送位延时是整个软串口的根基。11.0592MHz晶振、12T模式下1位时间约104us也就是96个机器周期。为了好调整我写了两个函数DelayOneBit延时1位时间DelayHalfBit延时半个位时间用于接收时采样到每个数据位的中点。// 一个位时间约104us编译优化级别建议固定为不优化/保守优化 void DelayOneBit(void) { unsigned char i; _nop_(); _nop_(); for (i 0; i 88; i) { _nop_(); } } void DelayHalfBit(void) { unsigned char i; _nop_(); for (i 0; i 42; i) { _nop_(); } }为什么循环里是88个_nop_因为循环本身有判断跳转开销加上调用函数时的LCALL、RET开销实际一个函数调用到返回大约96个机器周期。这个数值我是在草稿纸上推算加示波器校准后定的。如果你用的是STC15系列1T单片机机器周期算法不同延时函数要重新算不能用这个值硬套。发送一个字节的逻辑是先拉低TX引脚输出起始位0延时1位然后从低位到高位依次输出8个数据位每位输出后延时1位最后拉高TX输出停止位1延时1位。代码如下void SoftUartSendByte(unsigned char dat) { unsigned char i; EA 0; SOFT_TX 0; // 起始位 DelayOneBit(); for (i 0; i 8; i) { if (dat 0x01) { SOFT_TX 1; } else { SOFT_TX 0; } dat 1; DelayOneBit(); } SOFT_TX 1; // 停止位 DelayOneBit(); EA 1; }这个函数发送时CPU完全被占用不能在发送过程中做其他时间敏感操作。好在语音模块的控制指令帧很短通常是几个字节整体占用时间只有几毫秒对大多数场景都可以接受。4.3 软串口底层接收与采样时序接收比发送麻烦因为你不知道语音模块什么时候会发数据。在纯延时方案里我采用“轮询等待起始位下降沿”的方式循环读取SOFT_RX引脚一旦读到低电平就认为检测到了起始位然后按位采样。unsigned char SoftUartReceiveByte(void) { unsigned char i; unsigned char dat 0; // 等待起始位下降沿 while (SOFT_RX 1); // 延时半个位跳到起始位中心附近 DelayHalfBit(); // 采样8个数据位 for (i 0; i 8; i) { DelayOneBit(); // 移到下一位中点 dat 1; if (SOFT_RX) { dat | 0x80; } } // 忽略停止位等待一段时间让引脚恢复 DelayOneBit(); return dat; }这个采样时机的原理很重要当你检测到下降沿时其实是起始位刚刚开始的时刻此时电平还没稳定不能立刻采样。先延时半位到起始位中点确认确实是低电平然后每延时1位取一个点正好能落在每一个数据位的中点附近。中点采样的好处是抗干扰能力最强即使数据位边缘有毛刺中点也不容易误判。因为接收期间也必须关中断对应时序所以在主循环调用接收函数时我同样不会开中断。这个方案有效的关键在于语音模块上报的是短帧且两个帧之间有足够的空闲时间。4.4 上行解析与下行播放逻辑主循环里我把上行接收到的字节放进环形缓冲区然后调用ProcessRxData做帧解析。下面是一个简化的协议示例帧头0xAA 0x55命令码1字节校验和前面所有字节相加取低8位实际LU-ASR01不同批次、不同上位机配置产出的协议可能不一样你要根据自己的模块资料去改ParseCommand里的逻辑。我这里用通用协议示例说明框架。void ProcessRxData(void) { unsigned char byte; // 尝试从软串口读一个字节 // 注意SoftUartReceiveByte是阻塞的必须有数据才返回 // 为了不让主循环卡死真实项目建议用“串口缓冲区非阻塞判断” if (SOFT_RX 0) // 先判断有没有下降沿有才进入阻塞接收 { byte SoftUartReceiveByte(); rxBuf[rxHead] byte; rxHead (rxHead 1) % RX_BUF_SIZE; } // 如果缓冲里已经有至少3个字节尝试解析 if (((rxHead RX_BUF_SIZE - rxTail) % RX_BUF_SIZE) 3) { unsigned char h1 rxBuf[rxTail]; unsigned char h2 rxBuf[(rxTail 1) % RX_BUF_SIZE]; unsigned char cmd rxBuf[(rxTail 2) % RX_BUF_SIZE]; if (h1 0xAA h2 0x55) { rxTail (rxTail 3) % RX_BUF_SIZE; ParseCommand(cmd); } else { // 没匹配帧头移动一个字节继续找 rxTail (rxTail 1) % RX_BUF_SIZE; } } } void ParseCommand(unsigned char cmd) { unsigned char audioId; switch (cmd) { case 0x01: // 开灯 LIGHT_PIN 0; audioId 1; // 预先烧录到LU-ASR01里的音频“好的开灯” SendPlayCommand(audioId); LED_STATUS 0; break; case 0x02: // 关灯 LIGHT_PIN 1; audioId 2; // “好的关灯” SendPlayCommand(audioId); LED_STATUS 1; break; default: // 未识别命令播报提示音 SendPlayCommand(0x00); break; } }下行发送播放指令的函数根据LU-ASR01协议拼帧。还是那句话实际协议帧格式一定以模块资料为准下面的示例是通用写法void SendPlayCommand(unsigned char audioId) { // 示例下行帧AA 55 02 音频ID 校验 txFrame[0] 0xAA; txFrame[1] 0x55; txFrame[2] 0x02; // 表示播放音频 txFrame[3] audioId; txFrame[4] (txFrame[0] txFrame[1] txFrame[2] txFrame[3]) 0xFF; SoftUartSendByte(txFrame[0]); SoftUartSendByte(txFrame[1]); SoftUartSendByte(txFrame[2]); SoftUartSendByte(txFrame[3]); SoftUartSendByte(txFrame[4]); }4.5 参数计算晶振选择和定时器初值为什么大家都爱用11.0592MHz晶振做51串口因为这个频率能把9600、19200、115200等常用波特率的定时器初值算成整数误差非常小。以硬件串口方式1为例使用定时器1做波特率发生器9600波特率时机器周期 12 / 11.0592MHz ≈ 1.085us定时器溢出率 9600 * 32 307200Hz定时器初值 256 - (11059200 / (12 * 32 * 9600))≈256 - 3 253也就是0xFD如果用软串口同样需要这个频率来算延时。这也是我每次做语音模块项目都优先选11.0592MHz晶振的核心原因。如果你用12MHz晶振9600波特率会出现百分之几的累计误差一帧两帧可能没问题但帧长了就会偶发乱码。软串口对时序误差更敏感所以晶振第一选择永远是11.0592MHz。5. 联调测试与问题排查5.1 从零开始的联调步骤代码写完不等于能跑联调顺序很重要。我一般按下面几步不接LU-ASR01先写一个“软串口循环发送测试程序”把测试字符从软串口TX发出去用USB转TTL接PC串口助手看数据。这一步验证发送时序是否正确。用PC串口助手给单片机的软串口RX发数据让单片机把收到的字节原样从硬件串口或者LED状态灯反馈出来验证接收采样是否正常。接上LU-ASR01先只听上行对模块说唤醒词和命令词看51能不能正确解析可以在状态灯上做对应动作。再测下行写一个定时循环让51每3秒发送一条播放指令听LU-ASR01能不能播报确认下行协议和音频ID配置正确。最后把上下行合并按真实场景测试说“开灯”等灯亮听语音反馈说“关灯”等灯灭听语音反馈。我遇到过很多人上来就把所有代码集成完再调试出了问题完全不知道是上行收不到还是下行发不出还是协议不对。分层联调虽然多花半小时但能省下好几个小时的排错时间。5.2 常见问题速查表下面是我在这个项目里实际踩过、以及帮别人排查过的典型问题整理成一张表现象可能原因排查方向串口助手收不到软串口发出的数据波特率设置不一致延时不准晶振频率不对确认PC串口助手波特率9600示波器/逻辑分析仪检查软串口TX波形LU-ASR01识别结果到不了51RX/TX交叉接错共地问题软串口RX引脚接错重新核对交叉接线万用表量GND连通分清模块TXD和单片机RXD时不时收到乱码软串口接收采样点偏移信号干扰接收过程中被中断打扰检查延时是否匹配收发时关闭中断缩短杜邦线长度51发指令给LU-ASR01没反应下行协议帧不对音频ID不存在模块处于休眠用PC串口助手先发给模块验证下行帧重新配置音频ID波特率9600但通信偶发超时语音模块实际波特率不同启动后未就绪查看模块资料等待模块上电提示音后再发指令天问Block生成的代码编译报错开发板型号选错引脚名不匹配确认STM32/STC型号对照头文件里的sbit名称排查串口类问题最好备一个USB转TTL小板和一个逻辑分析仪。逻辑分析仪不一定贵几十块的也能清楚看到波形一眼就能看出起始位、数据位、停止位有没有问题。没有逻辑分析仪的话至少用示波器测一下IO口的电平翻转时间能算出实际波特率到底是多少。5.3 实践心得对软串口的几个实用看法第一纯延时软串口不是万能的。它适合数据量小、时序要求不高的场景比如语音模块这种一帧几个字节的短通信。如果你要接GPS模块每秒来几百个字节纯延时方案会把CPU彻底锁死这时候要么用硬件串口要么就必须写定时器中断驱动的高性能软串口。第二发送比接收容易接收的难点在于“你不知道数据什么时候来”。轮询接收最大的问题是如果主循环正在干别的事比如控制电机、刷新屏幕数据可能就漏了。所以真正稳定的做法是把接收放在外部中断里SOFT_RX引脚检测到下降沿就触发中断在中断里启动定时器做位采样。下面是我推荐的优化架构// 伪代码描述中断驱动软串口接收 // INT0下降沿中断 // 记录起始位关闭INT0打开TIMER0 // 定时器每104us中断一次 // 在第0次确认起始位为低 // 在第2~9次分别采样D0~D7 // 在第10次关闭TIMER0重新打开INT0这样主循环就可以专心做业务逻辑不需要一直轮询串口引脚。我已经按照这个思路跑过几百块板子稳定性和硬件串口差距很小。不过代码复杂度明显上升你得注意中断服务函数里的指令周期开销避免采样点偏移。第三天问Block生成的软串口积木对于学习阶段完全够用但实际产品落地我建议还是自己把底层软串口代码吃透。不是图形化不行而是当你需要特殊调整采样时序、增加中断优先级、优化误码率时图形化积木反而成了限制。最后再分享一个小技巧如果LU-ASR01的返回协议一直抓不到先用USB转TTL直接连模块在PC串口助手里看它识别后到底发了什么字节。先搞清楚上行帧格式再写51代码这样最少弯路。我就是靠这个“先监听、再对接”的习惯把很多看似玄学的串口问题解决了。语音模块这类外设绝大多数毛病都不是代码逻辑玄学而是协议和时序差那么一点点用数据说话永远比猜来得快。