8051 UART，串行接收字节答案

【问题标题】：8051 UART, Receiving bytes serially8051 UART，串行接收字节
【发布时间】：2012-08-10 11:37:41
【问题描述】：

我必须从计算机 (VB.NET) 将文件逐字节发送到串行连接的 AT89s52。
每个发送的字节在微控制器中都有一些工作需要一些时间。
这是我的 C 代码中与接收字节相关的部分：

SCON = 0x50;
TMOD = 0x20; // timer 1, mode 2, 8-bit reload
TH1  = 0xFD; // reload value for 9600 baud
TR1  = 1;
TI   = 1;

again:

        while(RI!=0)
        {
            P1=SBUF;          // show data on led's
            RI=0;
            receivedBytes++;
        }

        if (key1==0)
        {
            goto exitreceive; // break receiving
        }

        show_lcd_received_bytes(receivedBytes); 
        // here is one more loop 
        // with different duration for every byte
        goto again;

这是用于发送字节的 VB.NET 代码：

    For a As Integer = 1 To 10
        For t As Integer = 0 To 255
            SerialPort1.Write(Chr(t))
        Next t
    Next a

问题是 mC 在收到每个字节后都有一些工作要做，而 VB.NET 不知道这一点并且发送字节太快，所以在 mC 中只完成了所有字节的一部分（大约 10%）。我可以在 VB loop ant 中加入“Sleep(20)”，然后事情就可以工作了，但是我浪费了很多时间，因为每个字节都需要不同的时间来处理，这将是不可接受的缓慢通信。

现在，我的问题是 8051 是否可以在 UART 上设置一些繁忙状态，VB 可以在发送之前读取这些状态以决定是否发送字节。或者如何以其他方式设置所描述的此类通信？我也尝试在 mC 端接收带有串行中断的字节，结果相同。

硬件肯定没问题，因为我可以很好地将数据发送到计算机（如预期的那样）。

【问题讨论】：

通讯正常时为什么要降低波特率？
当你因为微控制器跟不上而丢失90%的数据时，你通常不会说“通信正常”。
在这种情况下，波特率不是数据丢失的原因，而是通信控制丢失的原因。这样，对于某些 mC 中的操作，150 bps 的速度可能会太高，而对于某些 19k，则可以接受。是的，通过将数据从 mC 发送到计算机可以看到，通信正常进行。
您的计算机不会有跟不上的问题，它的计算能力比您的 uC 高出几个数量级。还有一个带有 FIFO 的 UART。以及出色的中断处理程序。因此，看到从 uC 到计算机没有数据丢失并不意味着什么，问题恰恰相反。
如果你不想降低波特率，那么中断处理程序是最重要的，你不能强迫对方足够快地停止发送。你需要一个协议。一个简单的方法是您接受命令并在完成命令后发回一些东西。我想你已经知道了，真正的问题还不清楚。

标签： vb.net serial-port microcontroller 8051

【解决方案1】：

您的问题是架构问题。不要尝试在处理字节 Rx 的中断中对接收到的数据进行处理。让你的字节 Rx 中断只将接收到的字节复制到一个单独的 Rx 数据缓冲区，并有一个后台任务来执行传入数据的实际处理而不阻塞 Rx 中断处理程序。如果由于整体吞吐量问题而无法跟上，那么 RTS/CTS 流控制是合适的机制。例如，当您的 Rx 缓冲区已满 90% 时，取消断言流控制信号以暂停发送端。

【讨论】：

是的，我注意到了。但是我已经将 MAX232 用于 TX/RX 我有两个 I/O 对免费用于实现 RTS/CTS 信号。我是这个领域的新手，所以我想也许 8051 UART 已经有一些用于握手数据流的机制。现在事情有点清楚了。谢谢。

【解决方案2】：

正如@TJD 提到的，硬件流控制可用于在微型计算机处理接收到的字节时阻止 PC 发送字符。过去，我通过使用可用端口线作为输出来实现硬件流。输出需要连接到 TTL 到 RS-232 驱动器（如果您当前使用的是 RS-232，您可能有额外的驱动器可用）。如果您使用 USB 虚拟串行端口或 RS-422/485，则需要实现软件流控制。通常会发送一个 control-S 来告诉 PC 停止发送，并发送一个 control-Q 来继续。为了充分利用流控制，您很可能还需要实现一个完全中断驱动的 FIFO 来接收/发送字符。

如果您想了解有关硬件流控制的更多信息，请查看http://electronics.stackexchange.com。

【讨论】：

感谢杰夫的建议。在我的板上，我有免费的资源来进行 TTL/RS232 转换，（幸运的是）这两个信号完全一样。

【解决方案3】：

过去的爆炸，我记得使用接线盒来调试这种东西的串行线路跟踪器。

通过串行通信，如果您使用了所有引脚/线，则通过 RTS（准备发送）和 DTR（数据终端就绪）进行流控制，用于在可以发送更多数据时发出信号。您是否可以控制您通过 C 编码的设备中的内容？在 VB.NET 中，有用于接收这些信号的事件，或者可以使用 SerialPort 对象上的属性来查询它们。

【讨论】：

好吧，tcarvin，我可以控制那个设备，但我不知道它是否支持设置 RTS 和 DTR 位以及如何设置它。实际上，这正是我对一些有经验的 8051 用户提出的最初问题。

【解决方案4】：

这些答案中有很多都建议使用硬件流控制，但您也可以选择通过使用软件流控制来增强传输以更加健壮。目前，您的通信能力很强，但如果您开始运行更高的波特率或更长的距离，甚至只是连接嘈杂，则可能会接收到不正确的字符，或者可能会丢失字符。

您可以在完成任何设置为发生的操作后添加一个简单的两字节 ACK 序列。它可能看起来像这样：

主机发送命令字节：设备回显命令字节：设备执行所需的任何操作设备发送 ACK/NAK 字节（基于结果）：

这将允许您在主机端查看通信是否中断。回显的字符可能与发送的内容不匹配，这会提醒您注意问题。此外，如果主机在某个超时时间内没有接收到字符，主机可以尝试重新传输。最后，ACK/NAK 为您提供了返回状态的选项，但最重要的是它会让主机知道您已经完成了操作，并且它可以发送另一个命令。

这可以扩展为包含校验和，从而为设备提供一种验证接收到的命令是否有效的方法（与命令字节一起发送的简单逻辑逆就足够了）。

此解决方案的优点是它不需要额外的线路或任何一端都支持 UART 来进行硬件流控制。

【讨论】：