What is a handshake signal? What is a handshake protocol?

The RS-232 mode allows simple connections to three lines: Tx, Rx, and ground. However, for data transmission, both parties must use the same baud rate for data at regular intervals. Although this method is sufficient for most applications, the use of this method is limited when the receiver is overloaded. In this case, the serial handshake function is required. In this section we discuss three of the most common RS-232 handshakes: Software handshakes, hardware handshakes, and Xmodem.

A. Software handshake: The first handshake we discuss is software handshake. It is usually used when the actual data is a control character, similar to the use of command strings by using the export function. The required line is still three: Tx, Rx, and ground line, because the control characters are no different from common characters in the transmission line, the SetXModem function allows or disables the use of two control characters, XON and OXFF. These characters are sent by the receiver during communication, causing the sender to pause.
For example, assume that the sender sends data at a high baud rate. During transmission, the receiver finds that the input buffer is full because the CPU is busy with other work. To temporarily stop transmission, the receiver sends XOFF. The typical value is decimal 19, that is, hexadecimal 13, until the input buffer is empty. Once the receiver is ready to receive the message, it sends XON, the typical value is decimal 17, that is, hexadecimal 11, continue communication. When the input buffer is half full, LabWindows sends XOFF. In addition, if the XOFF transmission is interrupted, LabWindows will send XOFF when the buffer reaches 75% and 90%. Obviously, the sender must follow this Code to ensure that the transmission continues.

B. Hardware handshake: The second is hardware handshake. Like the Tx and Rx lines, the RTS/CTS and DTR/DSR work together, one as the output and the other as the input. The first line is RTS (Request to Send) and CTS (Clear to Send ). When the receiver is ready to receive data, it is set to a high RTS line, indicating that it is ready. If the sender is also ready, it is set to a high CTS, indicating that it is about to send data. Another line is DTR (Data Terminal Ready) and DSR (Data Set Ready ). These are mainly used for Modem communication. Enable the serial port to communicate with the Modem. For example, when the Modem is ready to receive data from the PC, it is set to a high DTR line, indicating that the connection to the telephone line has been established. When the DSR line is set to high, the PC starts to send data. A simple rule is that DTR/DSR is used to indicate that the system is ready for communication, while RTS/CTS is used to transmit a single data packet.

In LabWindows, The SetCTSMode function enables or disables the use of hardware handshakes. If the CTS mode is enabled, LabWindows uses the following rules:
When the PC sends data:
The RS-232 library must detect the high CTS line before sending data.

When the PC receives data:
If the port is opened and the input queue has no time to receive data, the library function is set to high-priority (RTS) and DTR.
If the input queue is 90% full, the library function is set to lower the RTS, but the DTR remains high.
If the port queue is almost empty, the crying count is high, but the DRT remains high.
If the port is disabled, the library function is set to lower the values of RTS and DTR.

C. XModem handshake: the handshake discussed at the end is called the XModem file transfer protocol. This Protocol is very common in Modem communication. Although it is usually used in Modem communication, the XModem protocol can be used directly in other devices that follow this protocol. In LabWindows, the actual XModem application hides users. As long as the PC and other devices use the XModem protocol, use the XModem function of LabWindows during file transfer. The functions are XModemConfig, XModemSend, and XModemReceive.

XModem uses the following protocols: start_of_data, end_of_data, neg_ack, wait_delay, start_delay, max_tries, and packet_size. These parameters need to be determined by both parties. The standard XModem has a standard definition: however, you can use the XModemConfig function to modify these parameters to meet specific needs. The usage of these parameters is determined by the neg_ack character sent by the receiver. This notification sender prepares to receive data. It starts sending an attempt. There is a timeout parameter start_delay. When the timeout attempt exceeds the number of max_ties attempts, or the sender stops trying to receive the start_of_data sent by the receiver. If start_of_data is received from the sender, the receiver reads the subsequent information packet. The package contains the number of packages and the number of packages as the actual packet size for error verification, packet_size, and the sum of the values for further error checks. After reading data, the Receiver calls wait_delay and wants the sender to send a response. If the sender does not receive a response, it resends the packet until it receives the response or exceeds the maximum number of resends max_tries. If no response is received, the sender notifies the user that data transmission fails.
Because the data must be sent in pack_size bytes by package, when the last packet is sent, if the data is not full, the ASCII Code NULL (0) bytes will be entered. As a result, more data is received than the original data. Do not use XON/XOFF in the case of XModem, because the number of XModem senders sending packets is likely to be increased to the value of the XON/OFF control character, resulting in communication failure.