Advantech ARK-3400, User Manual, Page: 77 / 87

65 ARK-3400 User Manual
Appendix C
A
pplication
Notes
between the two devices which reduces the bandwidth. The reduction of bandwidth is
in most cases however not so astonishing that it is a reason to not use it.
Two bytes have been predefined in the ASCII character set to be used with software
flow control. These bytes are named XOFF and XON, because they can stop and
restart transmitting. The byte value of XOFF is 19, it can be simulated by pressing
Ctrl-S on the keyboard. XON has the value 17 assigned which is equivalent to Ctrl-Q.
Using software flow control is easy. If sending of characters must be postponed, the
character XOFF is sent on the line, to restart the communication again XON is used.
Sending the XOFF character only stops the communication in the direction of the
device which issued the XOFF.
This method has a few disadvantages. One is already discussed: using bytes on the
communication channel takes up some bandwidth. One other reason is more severe.
Handshaking is mostly used to prevent an overrun of the receiver buffer, the buffer in
memory used to store the recently received bytes. If an overrun occurs, this affects
the way new incoming characters on the communication channel are handled. In the
worst case where software has been designed badly, these characters are thrown
away without checking them. If such a character is XOFF or XON, the flow of com-
munication can be severely damaged. The sender will continuously supply new infor-
mation if the XOFF is lost, or never send new information if no XON was received.
This also holds for communication lines where signal quality is bad. What happens if
the XOFF or XON message is not received clearly because of noise on the line? Spe-
cial precaution is also necessary that the information sent does not contain the XON
or XOFF characters as information bytes.
Therefore, serial communication using software flow control is only acceptable when
communication speeds are not too high, and the probability that buffer overruns or
data damage occur are minimal.
C.1.3 Hardware flow control
Hardware flow control is superior compared to software flow control using the XON
and XOFF characters. The main problem is, that an extra investment is needed.
Extra lines are necessary in the communication cable to carry the handshaking infor-
mation.
Hardware flow control is sometimes referred to as RTS / CTS flow control. This term
mentions the extra input and outputs used on the serial device to perform this type of
handshaking. RTS / CTS in its original outlook is used for handshaking between a
computer and a device connected to it such as a modem.
First, the computer sets its RTS line to signal the device that some information is
present. The device checks if there is room to receive the information and if so, it sets
the CTS line to start the transfer. When using a null modem connection, this is some-
what different. There are two ways to handle this type of handshaking in that sitiua-
tion.
One is, where the RTS of each side is connected with the CTS side of the other. In
that way, the communication protocol differs somewhat from the original one. The
RTS output of computer A signals computer B that A is capable of receiving informa-
tion, rather than a request for sending information as in the original configuration.
This type of communication can be performed with a null modem cable for full hand-
shaking. Although using this cable is not completely compatible with the original way
hardware flow control was designed, if software is properly designed for it, it can
achieve the highest possible speed because no overhead is present for requesting
on the RTS line and answering on the CTS line.
In the second situation of null modem communication with hardware flow control, the
software side looks quite similar to the original use of the handshaking lines. The
CTS and RTS lines of one device are connected directly to each other. This means,