The principal advantage of software flow control is the reduction in the number of
electrical conductors between sender and receiver. Given a
common ground, only two signals are needed, one to send and the other to receive. Hardware flow control requires additional wires between the two devices. It also requires specific hardware implementation, which had more significant costs in earlier days of computing (i.e., 1960s and 70s). However, software flow control is not without its problems. The most important drawback is that software flow control is less reliable. Sending XOFF requires at least one character time to transmit, and may be queued behind already-transmitted data still in buffers. Hardware signals may be asserted almost instantaneously, and out-of-order. As the name "software flow control" implies, flow control using this method is
usually implemented in software (or
firmware), which can cause further delays in XOFF response. These delays can lead to data corruption due to
buffer overruns. Hardware flow control, on the other hand, is typically under the direct control of the transmitting
UART, which is able to cease transmission immediately, without the intervention of higher levels. To handle the latency caused by builtin
FIFOs, more advanced UARTs, like the 16950, provide "on-chip" software flow control. UARTs that lack such support, like the
16550, may suffer from buffer overruns when using software flow control, although this can be somewhat mitigated by disabling the UART's FIFO. Finally, since the XOFF/XON codes are sent in-band, they cannot appear in the data being transmitted without being mistaken for flow control commands. Any data containing the XOFF/XON codes thus must be encoded in some manner for proper transmission, with corresponding overhead. This is frequently done with some kind of
escape sequence. For printing devices that directly interpret ASCII codes, this is not a large problem, because the XON and XOFF codes use
ASCII "device control" code numbers. == Applications ==