UART通信如何在两个设备之间工作？

Question

在我的一个项目中，我有一台纳米计算机（嵌入式Linux），该计算机通过UART连接到微控制器。

两者都需要自己做一些处理，但是有时纳米计算机需要在UART上发送数据，反之亦然。

我想如果A要与B通信，则B需要监听，对吗？我怎么知道什么时候听，什么时候说话？ 我需要在两个仅负责UART通信的设备中同时并行运行一个特殊线程，而它们却负责其他工作吗？ 如果我错过了一条消息，准备好了时可以读取的缓冲区是否已满？

感谢您的建议。 ：）

Answer 1

'A'和'B'一直在听。您必须启用UART接收中断。
也许此链接将说明基本知识：UART basics

Answer 2

正确连接和初始化的硬件在tx到rx的两侧都有一个tx和rx。因此双方从硬件角度一直在倾听。操作系统可能有一个驱动器和一个一直在累积该输入的缓冲区。但是，如果您没有要求输入数据的软件，那么您将看不到它。如果要（通常通过驱动程序和操作系统），您确实需要一些软件来监视uart，以便可以看到另一端在任何给定时间发送的内容。如果需要的话，您可以在连接的两端进行此操作。

Answer 3

There are two approaches that are used.

In the past, it was common to use hardware flow control. This uses an additional wire in each direction. The sender waits until the wire indicates the receiver is ready. When the receiver is not ready to receive data, it signals the other side. Hardware would buffer at least one byte and, if the buffer was full, signal the other side not to send over this wire.

This is less common today. UARTs are so slow relative to modern hardware and large buffers are so cheap and easy to provide that there is no longer an issue. The sender just fills the receiver's hardware buffer and the receiver empties the hardware buffer periodically. Software would have to ignore the buffer for a long time for it to overflow.

An intermediate solution is to use flow control in the data flow. Generally, two characters are reserved, one to stop the flow and one to resume it. The receiver sends a flow control character to the sender if its buffer is getting close to full and another one if its buffer is getting close to empty. This is really only useful if the data flow doesn't need to handle binary data. This is extremely rare and was traditionally used primarily for connections that had a human on one end. You could also pause the flow if the information was coming faster than you could read it.

Generally, the protocols used are tolerant of overflow and include some form of high-level acknowledgement and/or retransmission as appropriate. One device might wait for the other side to send some kind of response to its command and, if it doesn't get one, retry the command. The protocol is designed not to do anything terrible if a command is received twice since it might be the reply that's lost.