![](https://csdnimg.cn/release/download_crawler_static/12505212/bg14.jpg)
command. This is called null padding. These nulls formerly were called "fill characters". These nulls are
added just to "waste" time, but it's not all wasted since the terminal is usually kept busy doing something else
while the nulls are being received. It was much used in the past before flow control became popular. To be
efficient, just the right amount of nulls should be added and figuring out this is tedious. It was often done by
trial and error since terminal manuals are of little or no help. If flow control doesn't work right or is not
implemented, padding is one solution. Some of the options to the stty command involve padding.
10.3 Overrunning a Serial Port
One might wonder how overrunning is possible at a serial port since both the sending and receiving serial
ports involved in a transmission of data bytes are set for the same speed (in bits/sec) such as 19,200. The
reason is that although the receiving serial port electronics can handle the incoming flow rate, the
hardware/software that fetches and processes the bytes from the serial port sometimes can't cope with the
high flow rate.
One cause of this is that the serial port's hardware buffer is quite small. Older serial ports had a hardware
buffer size of only one byte (inside the UART chip). If that one received byte of data in the buffer is not
removed (fetched) by CPU instructions before the next byte arrives, that byte is lost (the buffer is overrun).
Newer UART's, namely most 16550's, have 16−byte buffers (but may be set to emulate a one−byte buffer)
and are less likely to overrun. It may be set to issue an interrupt when the number of bytes in its buffer
reaches 1, 4, 8, or 14 bytes. It's the job of another computer chip (usually the main CPU chip for a computer)
to take these incoming bytes out of this small hardware buffer and process them (as well as perform other
tasks).
When contents of this small hardware receive buffer reaches the specified limit (one byte for old UART'S) an
interrupt is issued. Then the computer interrupts what it was doing and software checks to find out what
happened. It finally determines that it needs to fetch a byte (or more) from the serial port's buffer. It takes
these byte(s) and puts them into a larger buffer (also a serial port buffer) that the kernel maintains in main
memory. For the transmit buffer, the serial hardware issues an interrupt when the buffer is empty (or nearly
so) to tell the CPU to put some more bytes into it to send out.
Terminals also have serial ports and buffers similar to the computer. Since the flow rate of bytes to the
terminal is usually much greater than the flow in the reverse direction from the keyboard to the host
computer, it's the terminal that is most likely to suffer overrunning. Of course, if you're using a computer as a
terminal (by emulation), then it is likewise subject to overrunning.
Risky situations where overrunning is more likely are: 1. When another process has disabled interrupts (for a
computer). 2. When the serial port buffer in main (or terminal) memory is about to overflow.
10.4 Stop Sending
When its appears that the receiver is about to be overwhelmed by incoming bytes, it sends a signal to the
sender to stop sending. That is flow control and the flow control signals are always sent in a direction
opposite to the flow of data which they control (although not in the same channel or wire). This signal may
either be a control character (^S = DC3 = Xoff) sent as an ordinary data byte on the data wire (in−band
signalling), or a voltage transition from positive to negative in the dtr−to−cts (or other) signal wire
(out−of−band signalling). Using Xoff is called "software flow control" and using the voltage transition in a
The Linux Text−Terminal−HOWTO
10.3 Overrunning a Serial Port 11