The method used by RS-232 for communication allows for a simple connection of three lines: Tx, Rx, and Ground. However, for the data to be transmitted, both sides have to be clocking the data at the same baud rate. Even though this method is sufficient for most applications, it is limited in being able to respond to problems such as the receiver getting overloaded. This is where serial handshaking can help. Three of the most popular forms of handshaking with RS-232 are software handshaking, hardware handshaking, and Xmodem.
Software Handshaking
This method uses data bytes as control characters, similar to the way GPIB uses command strings. The necessary lines are still the simple three-line set of Tx, Rx, and ground since the control characters are sent over the transmission line like regular data. The function SetXMode allows the user to enable or disable the use of two control characters, XON and XOFF. These characters are sent by the receiver of the data to pause the transmitter during communication.
The biggest drawback to this method is also the most important fact to keep in mind: decimal 17 and 19 are now unavailable for data values. In ASCII transmissions this typically does not matter since these values are non-character values; however, if the data is transmitted via binary, it is very likely these values could be transmitted as data and the transmission would fail.
Hardware Handshaking
This method uses actual hardware lines. Like the Tx and Rx lines, the RTS/CTS and DTR/DSR lines work together. One is the output and the other is the input.
The first set of lines are RTS (Request to Send) and CTS (Clear to Send). When a receiver is ready for data, it asserts the RTS line indicating it is ready to receive data. This is read by the sender at the CTS input, indicating it is clear to send the data.
The next set of lines are DTR (Data Terminal Ready) and DSR (Data Set Ready). These lines are used mainly for modem communication. They allow the serial port and the modem to communicate their status. For example, when the modem is ready for data to be sent from the PC, it will assert the DTR line indicating that a connection has been made across the phone line. This is read in through the DSR line and the PC can begin to send data. The general rule of thumb is the DTR/DSR lines are used to indicate the system is ready for communication and the RTS/CTS lines are used for individual packets of data.
In LabWindows, the function SetCTSMode enables or disables the use of hardware handshaking. If the CTS mode is enabled, LabWindows employs the following rules: When the PC sends data:
The RS-232 library must detect that its CTS line is high before sending data.
When the PC receives data:
If the port is opened and the input queue has room for data, the library raises RTS and DTR.
If the port input queue is 90% full, the library lowers RTS and leaves DTR high.
If the port input queue is nearly empty, the library raises RTS and leaves DTR high.
If the port is closed, the library lowers RTS and DTR. XModem Handshaking
Although this protocol is very common in modem communication, the XModem protocol can be used directly between other devices if they both follow the protocol. In LabWindows, the actual implementation of XModem is hidden from the user. As long as the PC is connected to another device using XModem protocol, the LabWindows’ XModem functions can be used to transfer files from one site to another. The functions are XModemConfig, XModemSend, and XModemReceive.
XModem uses a protocol based on the following parameters: start_of_data, end_of_trans, neg_ack, ack, wait_delay, start_delay, max_tries, packet_size. These parameters need to be agreed upon by both sides, and standard XModem has a standard definition of these; however, they can be modified through the XModemConfig function in LabWindows to meet any requirement. The way that these parameters are used in XModem is by having the neg_ack character sent by the receiver. This tells the sender that it is ready to receive data. It will try again with start_delay time in-between each try until either it reaches max_tries or receives start_of_data from the sender. If it reaches max_tries it will inform the user that it was unable to communicate with the sender. If it does receive start_of_data from the sender, it will read the packet of information that follows. This packet contains the packet number, the complement of the packet number as an error check, the actual data packet of packet_size bytes, and a checksum on the data for more error checking. After reading the data, the receiver will call wait_delay and then send ack back to the sender. If the sender does not receive ack, it will re-send the data packet max_tries or until it receives ack. If it never receives the ack, it informs the user that it has failed to transfer the file.
Since the data must be sent in packets of packet_size bytes, when the last packet is sent, if there is not enough data to fill the packet, the data packet is padded with ASCII NUL (0) bytes. This can cause the received file to be larger than the original. It is also important to remember not to use XON/XOFF with the XModem protocol since the packet number from the XModem transfer is very likely to increment to the XON/OFF control character values, which would cause a breakdown in communication. |
