51单片机软串口对接LU-ASR01语音模块：实现双向通信完整方案

做语音控制类项目的人，应该都遇到过这个尴尬：51单片机只有一个硬件串口，接了下载器就没法同时接语音模块，想接多个设备只能硬切引脚来回折腾。我这次用LU-ASR01语音识别模块做离线语音控制，一开始也被这个问题卡住了，后来索性自己用普通IO口写了软串口，配合天问Block的图形化开发环境把整个逻辑跑通。这篇文章就把这套完整方案记录下来：怎么做软串口、怎么对接LU-ASR01、怎么实现双向通信，附可以直接抄的完整代码。

LU-ASR01是一块很常见的离线语音识别模块，支持自定义唤醒词和命令词，识别结果通过串口发给单片机；同时它也能接收串口指令，主动播放预置音频或者TTS语音。一边往上发识别结果，一边往下收播放指令，这就是标题里说的“双向通信”。51单片机这边，我用天问Block搭图形化主逻辑，再用C语言补软串口底层，适合正在做语音控灯、语音控窗帘、语音播报这类项目的朋友，也适合只想搞懂单片机软串口原理的初学者参考。

1. 项目需求与整体方案选型

1.1 为什么需要双向语音通信

很多人做语音控制，用的是“单向上报”方式：语音模块识别到词，串口发给单片机，单片机执行动作，完事。一开始我也觉得这样够了，但真正用起来就会发现体验很别扭。你对着空气喊“开灯”，灯亮了，但你不知道它到底听没听见；如果周围有点吵，识别失败，你还得再喊一遍，完全不确定系统是否在工作。

所以这套方案要做成双向：语音识别模块把“用户意图”发给51单片机，单片机执行完动作之后，再反向发给语音模块一个“播放指令”，让它用语音回应你。比如：

• 你说“打开客厅灯”
• LU-ASR01识别到命令词，把结果帧通过串口发给51
• 51解析出命令，控制继电器或者三极管导通，灯亮
• 51再通过串口发一个“播放成功提示音/语音”的指令给LU-ASR01
• LU-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个机器周期。这个换算关系要记牢，后面写延时函数和定时器初值都要用它。

软串口有两种常见实现方式：

1. 循环延时方式：发送的时候按位翻转IO，每个位之间调用延时函数；接收的时候检测起始位下降沿，然后用延时跳到数据位中点采样。优点是代码简单直观；缺点是收发期间CPU被占住，而且延时要算得准，不能被高优先级中断打扰。

2. 定时器中断方式：把定时器配置成波特率溢出模式，在定时器中断里按状态机切换位；接收时配合外部中断检测起始位。优点是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.0）
• LU-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的“串口”分类里提供了软件串口初始化、发送字节、发送字符串、接收等积木。实际操作时：

1. 拖一个“软串口初始化”积木到初始化代码块，设置波特率9600，数据位8，停止位1。
2. 在发送位置，用“软串口发送字节数组”积木，把要下发的指令按照协议填进去。
3. 在接收位置，用一个循环不断读取软串口缓冲区，判断是否收到完整帧。

图形化积木封装了很多细节，但你要清楚它背后生成的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 从零开始的联调步骤

代码写完不等于能跑，联调顺序很重要。我一般按下面几步：

1. 不接LU-ASR01，先写一个“软串口循环发送测试程序”，把测试字符从软串口TX发出去，用USB转TTL接PC串口助手看数据。这一步验证发送时序是否正确。
2. 用PC串口助手给单片机的软串口RX发数据，让单片机把收到的字节原样从硬件串口或者LED状态灯反馈出来，验证接收采样是否正常。
3. 接上LU-ASR01，先只听上行：对模块说唤醒词和命令词，看51能不能正确解析，可以在状态灯上做对应动作。
4. 再测下行：写一个定时循环，让51每3秒发送一条播放指令，听LU-ASR01能不能播报，确认下行协议和音频ID配置正确。
5. 最后把上下行合并，按真实场景测试：说“开灯”，等灯亮，听语音反馈；说“关灯”，等灯灭，听语音反馈。

我遇到过很多人上来就把所有代码集成完再调试，出了问题完全不知道是上行收不到，还是下行发不出，还是协议不对。分层联调虽然多花半小时，但能省下好几个小时的排错时间。

5.2 常见问题速查表

下面是我在这个项目里实际踩过、以及帮别人排查过的典型问题，整理成一张表：

排查串口类问题，最好备一个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代码，这样最少弯路。我就是靠这个“先监听、再对接”的习惯，把很多看似玄学的串口问题解决了。语音模块这类外设，绝大多数毛病都不是代码逻辑玄学，而是协议和时序差那么一点点，用数据说话永远比猜来得快。