“Due to the limitation of cables, we generally do not use hardware flow control in ordinary control communication, but use software flow control. Generally, software flow control is realized through XON/XOFF. The common method is: when the amount of data in the input buffer of the receiving end exceeds the set high bit, it sends an XOFF character (19 in decimal or Control-S, the device programming manual should describe in detail) to the data sending end, and the sending end receives Stop sending data immediately after the XOFF character;
In RS232, CTS and RTS originally had a clear meaning, but since HAYES launched SmartModem, it has been a bit confusing, but now this meaning is mainstream, and major chip manufacturers control UART The flow control of the device is basically explained by HAYES MODEM flow control.
In RS232, RTS and CTS are used for direction switching in half-duplex mode, which is not explained in this article;
If the UART has only two signals, RX and TX, the flow control can only be done by soft flow control; if there are four signals of RX, TX, CTS, and RTS, it is mostly a UART that supports hard flow control; if there are RX, TX, If there are six signals of CTS, RTS, DTR and DSR, the possibility of RS232 standard is relatively high.
SIMCOM’s explanation of RTS/CTS:
(Pay attention to whether the difference is whether the serial port supports RTS/CTS with hard flow control. Don’t look at it for the benefit. When debugging hardware flow control with Rockchip, I was confused by this non-mainstream explanation.)
RTS is the input terminal of the module, which is used by the MCU to notify the module whether the MCU is ready and whether the module can send information to the MCU. The effective level of RTS is low.
CTS is the output terminal of the module, which is used for the module to notify the MCU whether the module is ready and whether the MCU can send information to the module. The effective level of CTS is low.
RTS and CTS in HAYES Modem are used for hardware flow control. Now usually the meaning of RTC and CTS of UART refers to the latter, that is, it is used for hard flow control.
Hard flow-controlled RTS, CTS:
(Now use RTS/CTS for serial port, you must see the content, because MTK/)
RTS (Require ToSend, send request) is an output signal, which is used to indicate that the device is ready to receive data. The low level is active, and the low level indicates that the device can receive data.
CTS (Clear ToSend, send permission) is the input signal, which is used to judge whether data can be sent to the other party. The low level is valid, and the low level indicates that the device can send data to the other party.
Someone here translates CTS as Send Allow, which I think is better than clear to send. Because the CTS is the function of the other party’s RTS to control whether the own party’s CTS is allowed to send.
An example of using AP and MODEM to send and receive serial data using flow control:
CTS is the input
RTS is output
The CTS of the AP is connected to the RTS of the MODEM; the CTS of the MODEM is connected to the RTS of the AP.
On default startup:
AP’s CTS is high
AP’s RTS is low
MODEM’s CTS is high but can easily be pulled low
MODEM’s RTS is low
When sleeping by default
MODEM’s CTS is high but can easily be pulled low
MODEM’s RTS is high
Among them, when CTS measured the voltage with a voltmeter, it was found that it was a high level during the first 200ms of measurement, and then the voltage value continued to drop and became a low level, which means that the CTS should be high when it is suspended, and the high level is only a high level. Just a certain amount of positive charge.
I don’t know why the specification should write that CTS is high by default when designing the chip. CTS is only an input terminal, and no default value is needed. And when the flow control is turned on, it is possible to communicate with three wires (RXD/TXD/GND) without connecting CTS and RTS, which means that when RTS/CTS is not connected, CTS is low level. Why is the actual use inconsistent with the chip specification? It may be interfered with the low level by the metal cover of the casing. After all, the module I use, CTS is so close to the metal protection cover of low level, and CTS is an input port, there is no pull-up or pull-down level capability.
The flow control between AP and MODEM communicates like this:
When the AP serial port is available, pull down the AP-RTS, the MODEM-CTS detects that the AP-RTS is low, and knows that the AP serial port is ready to send data;
When the AP serial port is unavailable, pull up AP-RTS high, MODEM-CTS detects that AP-RTS is high, know that the AP serial port is not ready, it will not put data.
The same is true for the interaction when the MODEM serial port is available and unavailable.
Without serial controller, RTS and CTS functions can be realized by using interrupts and common IO ports.
RTS is implemented with GPIO, the serial port is ready (no data to send, waiting to receive) pull low level, the serial port is busy ( own data to send) pull high level
CTS is implemented with interrupts. When a low level is detected, the serial port data is sent out. When a high level is detected, the serial port data is retained until a low level is detected.
Here are excerpts from useful references online:
Assuming that A and B communicate with each other, the RTS of the A device is connected to the CTS of the B device; the CTS of the A device is connected to the RTS of the B device.
The former signal controls the transmission of the B device, and the latter signal controls the transmission of the A device. For the transmission of the B device (the A device receives), if the A device receives the buffer is almost full, it sends an RTS signal (RTS is pulled high, the RTS is invalid, and the other party is told to stop sending), and the B device is notified to stop sending, and the B device passes the CTS detection. When this signal is reached, stop sending; after a period of time, when the receiving buffer of device A is free, it sends an RTS signal (RTS is pulled low, RTS is valid, request to send), instructing device B to start sending data. A device sends (B device receives) similar.
The above functions can also be implemented by inserting Xoff (special character) and Xon (another special character) signals in the data stream. Once the A device receives the Xoff sent by the B device, it will stop sending immediately; on the contrary, if it receives the Xon sent by the B device, it will resume sending data to the B device. In the same way, the B device is also similar, so as to achieve speed matching between the sender and the receiver.
Half-duplex direction switching: RS232 uses DTR (Date Terminal Ready, data terminal ready) and DSR (Data Set Ready, data device ready) for main control, similar to the above RTS and CTS. For DTE (Date Terminal Equipment, data terminal equipment) and DCE (Data circuitEquipment) of half-duplex communication, the default direction is DTE receiving and DCE sending. If the DTE wants to send data, it must send the RTS signal to request the data to be sent. After receiving the DCE, if it is idle, it will send a CTS to respond to the RTS signal, indicating a response request, so that the communication direction becomes DTE->TCE, and the RTS and CTS signals must always be maintained. It can be seen from this that although CTS and TRS also have a meaning of flow control (for example, CTS is not sent, DTE cannot send data), but they are mainly used for direction switching.
The role of flow control in serial communication
The “stream” mentioned here, of course, refers to the data stream. When data is transmitted between two serial ports, the phenomenon of data loss often occurs, or the processing speed of the two computers is different. The incoming data will be lost. Now we transmit data through MODEM on the network, this problem is particularly prominent. Flow control can solve this problem. When the data at the receiving end cannot be processed, it will send a “no longer receive” signal, and the sending end will stop sending until it receives the “can continue to send” signal before sending data. Therefore, flow control can control the process of data transmission and prevent data loss. Two kinds of flow control commonly used in PC are hardware flow control (including RTS/CTS, DTR/CTS, etc.) and software flow control XON/XOFF (continue/stop), which are explained below.
hardware flow control
Commonly used hardware flow control are RTS/CTS flow control and DTR/DSR (Data Terminal Ready/Data Set Ready) flow control.
The hardware flow control must be connected to the corresponding cable. When using RTS/CTS (request to send/clear to send) flow control, the RTS and CTS lines at both ends of the communication should be connected correspondingly. Data terminal equipment (such as a computer) uses RTS to connect. A data communication device, such as a modem, uses the CTS to start and pause data flow from a computer. The process of this hardware handshake is as follows: we set a high-order flag (can be 75% of the buffer size) and a low-order flag (can be 25% of the buffer size) according to the buffer size of the receiver during programming. When the amount of data in the area reaches a high level, we set the CTS line to a low level at the receiving end (send logic 0). When the program at the sending end detects that the CTS is low, it stops sending data until the amount of data in the receiving end buffer is low. low to set CTS high. RTS is used to indicate whether the receiving device is ready to receive data.
Commonly used flow control is also DTR/DSR (Data Terminal Ready/Data Set Ready). We won’t go into details here. Due to the diversity of flow control, I personally think that when flow control is used in software, it should be explained in detail, how to wire it, and how to apply it.
software flow control
Due to the limitation of cables, we generally do not use hardware flow control in ordinary control communication, but use software flow control. Generally, software flow control is realized through XON/XOFF. The common method is: when the amount of data in the input buffer of the receiving end exceeds the set high bit, it sends an XOFF character (19 in decimal or Control-S, the device programming manual should describe in detail) to the data sending end, and the sending end receives After the XOFF character, it stops sending data immediately; when the amount of data in the input buffer of the receiver is lower than the set low bit, it sends an XON character (decimal 17 or Control-Q) to the data sender, and the sender receives the XON character. Data will be sent immediately after that. Generally, what characters are sent can be found from the source program of the device.
It should be noted that if the transmission is binary data, the flag characters may also appear in the data stream and cause misoperation. This is a defect of software flow control, but hardware flow control will not have this problem.
1. What is the relationship between UART and RS232?
UART (Universal Asynchronization Receviver/Transmite) can be viewed as a software interface protocol, including RS232, RS485, RS422 and other interface standard specifications and bus standard specifications. These standards specify the electrical characteristics of the interface (such as level), transmission rate, The connection characteristics, etc., actually belong to the concept of the physical layer in the communication network, and have no direct relationship with the communication protocol. The communication protocol generally belongs to the concept of the link layer, that is, the link layer.
So what is the relationship between RS232 and TTL uart? Both are uart protocols, as mentioned above, only the electrical characteristics such as levels are different.
2. UART is full-duplex communication, why do you need RTS and CTS to control the direction?
RTS and CTS are not needed in uart full-duplex communication, they are only used in half-duplex communication, such as RS485.
3. In many chip manuals, uart supports IrDA (infrared) and RS485 mode. What is the concept of supporting RS485 mode?
In the SAM4S chip manual, the RS485 mode is described as follows:
While operating in RS485 mode, the USART behaves as though in Async or Sync mode and configuration of all the parameters is possible.
The difference is that the RTS pin is driven high when the transmitter is operating.
The RTS pin is controlled by the TXEMPTY bit.
That is to say, in the RS485 mode, the difference from the normal mode is that when the transmission is in progress, the RTS pin is pulled high. Once the transmission is over (TXEMPTY is set), the RTS pin is pulled low to notify the other party that data can be sent, thus completing the hardware automatic flow. control.
Figure 1 below is the connection diagram of RS485 mode of SAM4S, and Figure 2 is the connection diagram of RS485 mode of i.MX6.
4. In general, what are the levels of the serial port start bit and stop bit?
The start bit is usually low for synchronization; the stop bit is high for the end of the frame.