Software flow control is a method of flow control used in computer data links, especially RS-232 serial. It uses special codes, transmitted in-band, over the primary communications channel. These codes are generally called XOFF and XON (from "transmit off" and "transmit on", respectively). Thus, "software flow control" is sometimes called "XON/XOFF flow control". This is in contrast to flow control via dedicated out-of-band signals — "hardware flow control" — such as RS-232 RTS/CTS.
YouTube Encyclopedic
-
1/3Views:23 60710 24611 252
-
Control Flow Graphs - Georgia Tech - Software Development Process
-
Computer Networks: Flow Control
-
Core java || Java flow control statements part -1
Transcription
Let's look at the code for PrintSum in a slightly different way by making something explicit. If we go through the code, we can see that the, the code does something in that case, if the result greater then zero, does something else if the result is not greater than zero but is less than zero, and otherwise in the case in which neither of these two conditions is true. Nothing really happens. So we're going to make that explicit, we're going to say here, otherwise do nothing, which is exactly our problem, the code does nothing, in this case where it should do something. So now, let's look again in our test cases, let's consider the first one, and I'm going to go a little faster in this case, because we already saw what happens If we execute the first test case, we get to this point, we execute this statement, and then we just jump to the end, as we saw. Now we, if we execute the second test case, we do the same, we get to the else statement, the condition for the if is true, and therefore we execute this statement. And we never reached this point for either of the test cases. So how can we express this? In order to do that, I'm going to introduce a very useful concept. The concept of control flow graphs. The control flow graphs is just a representation for the code that is very convenient when we run our reason about the code and its structure. And it's a fairly simple one that represents statement with notes and the flow of control within the code with edges. So here's an example of control flow graph for this code. There is the entry point of the code right here, then our statement in which we assign the result of A plus B to variable result. Our if statement and as you can see the if statement it's got two branches coming out of it, because based on the outcome of this predicate we will go one way or the other. In fact normally what we do, we will label this edges accordingly. So for example, here we will say that this is the label to be executed when the predicate is true. And this is the label that is executed when the predicate is false. Now, at this point, similar thing, statement five which corresponds with this one, we have another if statement and if that statement is true, then we get to this point and if it's false, we get to this point. So as you can see, this graph represents my code, in a much more intuitive way, because I can see right away where the control flows, while I execute the code. So we're going to use this representation to introduce further coverage criteria.
Representation
For systems using the ASCII character code, XOFF is generally represented using a character or byte with decimal value 19; XON with value 17.
The ASCII standard does not reserve any control characters for use as XON/XOFF specifically. However, it does provide four generic "device control" characters (DC1 through DC4). The Teletype Model 33 ASR adopted two of these, DC3 and DC1, for use as XOFF and XON, respectively. This usage was copied by others, and is now a de facto standard. The keyboard equivalents of Ctrl+S for XOFF, and Ctrl+Q for XON, also derive from this usage.
| Code | Meaning | ASCII | Dec | Hex | Keyboard |
|---|---|---|---|---|---|
| XOFF | Pause transmission | DC3 | 19 | 13 | Ctrl+S |
| XON | Resume transmission | DC1 | 17 | 11 | Ctrl+Q |
Mechanism
When one end of a data link is unable to accept any more data (or approaching that point), it sends XOFF to the other end. The other end receives the XOFF code, and suspends transmission. Once the first end is ready to accept data again, it sends XON, and the other end resumes transmission.
For example, one may imagine a computer sending data to a slow printer. Since the computer is faster at sending data than the printer can print it, the printer falls behind and approaches a situation where it would be overwhelmed by the data. The printer reacts to this situation by sending XOFF to the computer, which temporarily stops sending data. When the printer is again ready to receive more data, it sends XON to the computer, which starts sending data again.
XOFF/XON can be employed in both directions, for example, two teleprinters connected to each other.
Comparison with hardware flow control
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.
| Type | Data integrity | Low cost | Out of Band |
|---|---|---|---|
| Hardware flow control | Most reliable | No | Yes |
| On-chip software f.c. | Good | Some | No |
| Software f.c. (FIFO disabled) | Good, but slow | Yes | No |
| Software f.c. (FIFO enabled) | Unreliable | Yes | No |
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.[1] 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.[1]
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
Software flow control is used extensively by low-speed devices, especially older printers and dumb terminals, to indicate they are temporarily unable to accept more data. Typically, this is due to a combination of limited output rate and any buffers being full. Some terminal control packages, such as termcap, employ "padding" (short delays using millisecond granularity[2]) to allow such equipment sufficient time to perform the requested actions without the need to assert XOFF.
XOFF/XON are still sometimes used manually by computer operators, to pause and restart output which otherwise would scroll off the display too quickly.
Terminal emulator software generally implements XOFF/XON support as a basic function. This generally includes the system console on modern Unix and Linux machines, as well as GUI emulators such as xterm and the Win32 console.
Robust XON is a technique to restart communication, just in case it was stopped by an accidentally received XOFF. The receiving unit sends periodic XON characters when it can receive data, and the line is idle. One common use is by serial printers (like HP LaserJet II) to indicate they are online and ready to receive data. The XON is sent every 1 to 30 seconds depending on the printer's firmware design.
See also
References
- ^ a b Yang, Casper (2009). The Secrets of Flow Control in Serial Communication (PDF). Moxa Tech Note (1.0 ed.). Moxa Technical Writing Center (published September 30, 2009). Archived from the original (PDF) on Aug 4, 2022. Retrieved Aug 4, 2022.
- ^ "The Termcap Library - Describe Padding". www.gnu.org.
- "HP LaserJet IIP and IIP Plus Printers - Control Panel Keys and Menus". Hewlett-Packard. Archived from the original on May 9, 2006.
This page was last edited on 29 December 2023, at 16:25