1. Hardware Flow Control Serial Port Cable
2. Serial Flow Control
3. Hardware Flow Control Serial Port Number
4. Linux Serial Port Hardware Flow Control

The arduino hardware and serial software uses no serial data flow control at all. You could using external hardware and or software in your sketch to implement some forms of flow control. ControlHandShake A bitmask that specifies the control lines that the serial port uses for flow control. This member is set to zero or to the bitwise-OR or one or more of the following flags. No control is used for the handshake. RequestToSend RequestToSend RequestToSend RequestToSend: 2: Request-to-Send (RTS) hardware flow control is used. RTS signals that data is available for transmission. If the input buffer becomes full, the RTS line will be set to false. The RTS line will be set to true when more room becomes available in the.

I'm trying to determine the difference when I open serial port with hardware handshake and none handshake. It seems that in both cases I have to control RTS/CTS signals (just tested it with one COM device). So what the difference between opening serial port.

In computing, a serial port is a serial communication interface through which information transfers in or out one bit at a time (in contrast to a parallel port).^[1] Throughout most of the history of personal computers, data was transferred through serial ports to devices such as modems, terminals, and various peripherals.

While such interfaces as Ethernet, FireWire, and USB all send data as a serial stream, the term serial port usually identifies hardware compliant to the RS-232 standard or similar and intended to interface with a modem or with a similar communication device.

Modern computers without serial ports may require USB-to-serial converters to allow compatibility with RS-232 serial devices. Serial ports are still used in applications such as industrial automation systems, scientific instruments, point of sale systems and some industrial and consumer products. Server computers may use a serial port as a control console for diagnostics. Network equipment (such as routers and switches) often use serial console for configuration. Serial ports are still used in these areas as they are simple, cheap and their console functions are highly standardized and widespread. A serial port requires very little supporting software from the host system.

• 1Hardware
• 3Settings

Hardware[edit]

Some computers, such as the IBM PC, use an integrated circuit called a UART. This IC converts characters to and from asynchronous serial form, implementing the timing and framing of data in hardware. Very low-cost systems, such as some early home computers, would instead use the CPU to send the data through an output pin, using the bit banging technique. Before large-scale integration (LSI) UART integrated circuits were common, a minicomputer would have a serial port made of multiple small-scale integrated circuits to implement shift registers, logic gates, counters, and all the other logic for a serial port.

Early home computers often had proprietary serial ports with pinouts and voltage levels incompatible with RS-232. Inter-operation with RS-232 devices may be impossible as the serial port cannot withstand the voltage levels produced and may have other differences that 'lock in' the user to products of a particular manufacturer.

Low-cost processors now allow higher-speed, but more complex, serial communication standards such as USB and FireWire to replace RS-232. These make it possible to connect devices that would not have operated feasibly over slower serial connections, such as mass storage, sound, and video devices.

Many personal computer motherboards still have at least one serial port, even if accessible only through a pin header. Small-form-factor systems and laptops may omit RS-232 connector ports to conserve space, but the electronics are still there. RS-232 has been standard for so long that the circuits needed to control a serial port became very cheap and often exist on a single chip, sometimes also with circuitry for a parallel port.

DTE and DCE[edit]

The individual signals on a serial port are unidirectional and when connecting two devices the outputs of one device must be connected to the inputs of the other. Devices are divided into two categories data terminal equipment (DTE) and data circuit-terminating equipment (DCE). A line that is an output on a DTE device is an input on a DCE device and vice versa so a DCE device can be connected to a DTE device with a straight wired cable. Conventionally, computers and terminals are DTE while modems and peripherals are DCE.

If it is necessary to connect two DTE devices (or two DCE devices but that is more unusual) a cross-over null modem, in the form of either an adapter or a cable, must be used.

Male and female[edit]

Generally, serial port connectors are gendered, only allowing connectors to mate with a connector of the opposite gender. With D-subminiature connectors, the male connectors have protruding pins, and female connectors have corresponding round sockets.^[2] Either type of connector can be mounted on equipment or a panel; or terminate a cable.

Connectors mounted on DTE are likely to be male, and those mounted on DCE are likely to be female (with the cable connectors being the opposite). However, this is far from universal; for instance, most serial printers have a female DB25 connector, but they are DTEs.^[3]

Connectors[edit]

While the RS-232 standard originally specified a 25-pin D-type connector, many designers of personal computers chose to implement only a subset of the full standard: they traded off compatibility with the standard against the use of less costly and more compact connectors (in particular the DE-9 version used by the original IBM PC-AT). The desire to supply serial interface cards with two ports required that IBM reduce the size of the connector to fit onto a single card back panel. A DE-9 connector also fits onto a card with a second DB-25 connector. Starting around the time of the introduction of the IBM PC-AT, serial ports were commonly built with a 9-pin connector to save cost and space. However, presence of a 9-pin D-subminiature connector is not sufficient to indicate the connection is in fact a serial port, since this connector is also used for video, joysticks, and other purposes.

Some miniaturized electronics, particularly graphing calculators and hand-held amateur and two-way radio equipment, have serial ports using a phone connector, usually the smaller 2.5 or 3.5 mm connectors and use the most basic 3-wire interface.

Many models of Macintosh favor the related RS-422 standard, mostly using German mini-DIN connectors, except in the earliest models. The Macintosh included a standard set of two ports for connection to a printer and a modem, but some PowerBook laptops had only one combined port to save space.

Since most devices do not use all of the 20 signals that are defined by the standard, smaller connectors are often used. For example, the 9-pin DE-9 connector is used by most IBM-compatible PCs since the IBM PC AT, and has been standardized as TIA-574. More recently, modular connectors have been used. Most common are 8P8C connectors, for which the EIA/TIA-561 standard defines a pinout, while the 'Yost Serial Device Wiring Standard'^[4] invented by Dave Yost (and popularized by the Unix System Administration Handbook) is common on Unix computers and newer devices from Cisco Systems. 10P10C connectors can be found on some devices as well. Digital Equipment Corporation defined their own DECconnect connection system which is based on the Modified Modular Jack (MMJ) connector. This is a 6-pin modular jack where the key is offset from the center position. As with the Yost standard, DECconnect uses a symmetrical pin layout which enables the direct connection between two DTEs. Another common connector is the DH10 header connector common on motherboards and add-in cards which is usually converted via a cable to the more standard 9-pin DE-9 connector (and frequently mounted on a free slot plate or other part of the housing).

Pinouts[edit]

The following table lists commonly used RS-232 signals and pin assignments.^[5]

The signal ground is a common return for the other connections; it appears on two pins in the Yost standard but is the same signal. The DB-25 connector includes a second 'protective ground' on pin 1, which is intended to be connected by each device to its own frame ground or similar. Connecting this to pin 7 (signal reference ground) is a common practice but not recommended.

Note that EIA/TIA 561 combines DSR and RI,^[10][11] and the Yost standard combines DSR and DCD.

Powered serial port[edit]

Some serial ports on motherboards or add-in cards provide jumpers that select whether pin 1 of the DE-9 connector connects to DCD or a power supply voltage, and whether pin 9 of the DE-9 connector connects to RI or a power supply voltage. The power supply voltage can be +5V, +12V, +9V, or ground. (Selection varies by vendor.) The power is intended for use by point-of-sale equipment. Makers include Dell^[12], HP, and others^[13] (This is not an official standard.)

Hardware abstraction[edit]

Operating systems usually create symbolic names for the serial ports of a computer, rather than requiring programs to refer to them by hardware address.

Unix-like operating systems usually label the serial port devices /dev/tty*. TTY is a common trademark-free abbreviation for teletype, a device commonly attached to early computers' serial ports, and * represents a string identifying the specific port; the syntax of that string depends on the operating system and the device. On Linux, 8250/16550 UART hardware serial ports are named /dev/ttyS*, USB adapters appear as /dev/ttyUSB* and various types of virtual serial ports do not necessarily have names starting with tty.

The DOS and Windows environments refer to serial ports as COM ports: COM1, COM2,.etc. Ports numbered greater than COM9 should be referred to using the .COM10 syntax.^[14]

Common applications for serial ports[edit]

The RS-232 standard is used by many specialized and custom-built devices. This list includes some of the more common devices that are connected to the serial port on a PC. Some of these such as modems and serial mice are falling into disuse while others are readily available.

Serial ports are very common on most types of microcontroller, where they can be used to communicate with a PC or other serial devices.

• Dial-up modems
• Configuration and management of networking equipment such as routers, switches, firewalls, load balancers
• GPS receivers (typically NMEA 0183 at 4,800 bit/s)
• Bar code scanners and other point of sale devices
• LED and LCD text displays
• Satellite phones, low-speed satellite modems and other satellite based transceiver devices
• Flat-screen (LCD and Plasma) monitors to control screen functions by external computer, other AV components or remotes
• Test and measuring equipment such as digital multimeters and weighing systems
• Updating firmware on various consumer devices.
• Hobbyist programming and debugging MCU's
• Stenography or Stenotype machines
• Software debuggers that run on a second computer
• Industrial field buses
• Computer terminal, teletype
• Older digital cameras
• Networking (Macintosh AppleTalk using RS-422 at 230.4 kbit/s)
• Older GSMmobile phones
• IDEhard drive^[15][16]repair^[17][18]

Since the control signals for a serial port can be easily turned on and off by a switch, some applications used the control lines of a serial port to monitor external devices, without exchanging serial data. A common commercial application of this principle was for some models of uninterruptible power supply which used the control lines to signal loss of power, low battery, and other status information. At least some Morse code training software used a code key connected to the serial port, to simulate actual code use. The status bits of the serial port could be sampled very rapidly and at predictable times, making it possible for the software to decipher Morse code.

Settings[edit]

Many settings are required for serial connections used for asynchronous start-stop communication, to select speed, number of data bits per character, parity, and number of stop bits per character. In modern serial ports using a UART integrated circuit, all settings are usually software-controlled; hardware from the 1980s and earlier may require setting switches or jumpers on a circuit board. One of the simplifications made in such serial bus standards as Ethernet, FireWire, and USB is that many of those parameters have fixed values so that users cannot and need not change the configuration; the speed is either fixed or automatically negotiated. Often if the settings are entered incorrectly the connection will not be dropped; however, any data sent will be received on the other end as nonsense.

Speed[edit]

Serial ports use two-level (binary) signaling, so the data rate in bits per second is equal to the symbol rate in baud. A standard series of rates is based on multiples of the rates for electromechanical teleprinters; some serial ports allow many arbitrary rates to be selected. The port speed and device speed must match. The capability to set a bit rate does not imply that a working connection will result. Not all bit rates are possible with all serial ports. Some special-purpose protocols such as MIDI for musical instrument control, use serial data rates other than the teleprinter series. Some serial port systems can automatically detect the bit rate.

The speed includes bits for framing (stop bits, parity, etc.) and so the effective data rate is lower than the bit transmission rate. For example, with 8-N-1 character framing only 80% of the bits are available for data (for every eight bits of data, two more framing bits are sent).

Bit rates commonly supported include 75, 110, 300, 1200, 2400, 4800, 9600, 19200, 38400, 57600 and 115200 bit/s.^[20]

Crystal oscillators with a frequency of 1.843200 MHz are sold specifically for this purpose. This is 16 times the fastest bit rate and the serial port circuit can easily divide this down to lower frequencies as required.

Data bits[edit]

The number of data bits in each character can be 5 (for Baudot code), 6 (rarely used), 7 (for true ASCII), 8 (for most kinds of data, as this size matches the size of a byte), or 9 (rarely used). 8 data bits are almost universally used in newer applications. 5 or 7 bits generally only make sense with older equipment such as teleprinters.

Most serial communications designs send the data bits within each byte LSB (least significant bit) first. This standard is also referred to as 'little endian.' Also possible, but rarely used, is 'big endian' or MSB (most significant bit) first serial communications; this was used, for example, by the IBM 2741 printing terminal. (See Bit numbering for more about bit ordering.) The order of bits is not usually configurable within the serial port interface. To communicate with systems that require a different bit ordering than the local default, local software can re-order the bits within each byte just before sending and just after receiving.

Parity[edit]

Parity is a method of detecting errors in transmission. When parity is used with a serial port, an extra data bit is sent with each data character, arranged so that the number of 1 bits in each character, including the parity bit, is always odd or always even. If a byte is received with the wrong number of 1s, then it must have been corrupted. However, an even number of errors can pass the parity check.

Electromechanical teleprinters were arranged to print a special character when received data contained a parity error, to allow detection of messages damaged by line noise. A single parity bit does not allow implementation of error correction on each character, and communication protocols working over serial data links will have higher-level mechanisms to ensure data validity and request retransmission of data that has been incorrectly received.

The parity bit in each character can be set to one of the following:

• None (N) means that no parity bit is sent at all.
• Odd (O) means that parity bit is set so that the number of 'logical ones' must be odd.
• Even (E) means that parity bit is set so that the number of 'logical ones' must be even.
• Mark (M) parity means that the parity bit is always set to the mark signal condition (logical 1).
• Space (S) parity always sends the parity bit in the space signal condition (logical 0).

Aside from uncommon applications that use the last bit (usually the 9th) for some form of addressing or special signaling, mark or space parity is uncommon, as it adds no error detection information. Odd parity is more useful than even, since it ensures that at least one state transition occurs in each character, which makes it more reliable. The most common parity setting, however, is 'none', with error detection handled by a communication protocol.

Stop bits[edit]

Stop bits sent at the end of every character allow the receiving signal hardware to detect the end of a character and to resynchronise with the character stream. Electronic devices usually use one stop bit. If slow electromechanical teleprinters are used, one-and-one half or two stop bits are required.

Conventional notation[edit]

The data/parity/stop (D/P/S) conventional notation specifies the framing of a serial connection. The most common usage on microcomputers is 8/N/1 (8N1). This specifies 8 data bits, no parity, 1 stop bit. In this notation, the parity bit is not included in the data bits. 7/E/1 (7E1) means that an even parity bit is added to the 7 data bits for a total of 8 bits between the start and stop bits. If a receiver of a 7/E/1 stream is expecting an 8/N/1 stream, half the possible bytes will be interpreted as having the high bit set.

Flow control[edit]

In many circumstances a transmitter might be able to send data faster than the receiver is able to process it. To cope with this, serial lines often incorporate a 'handshaking' method, usually distinguished between hardware and software handshaking.

Hardware handshaking is done with extra signals, often the RS-232 RTS/CTS or DTR/DSR signal circuits. Generally, the RTS and CTS are turned off and on from alternate ends to control data flow, for instance when a buffer is almost full. DTR and DSR are usually on all the time and, per the RS-232 standard and its successors, are used to signal from each end that the other equipment is actually present and powered-up. However, manufacturers have over the years built many devices that implemented non-standard variations on the standard, for example, printers that use DTR as flow control.

Software handshaking is done for example with ASCIIcontrol charactersXON/XOFF to control the flow of data. The XON and XOFF characters are sent by the receiver to the sender to control when the sender will send data, that is, these characters go in the opposite direction to the data being sent. The circuit starts in the 'sending allowed' state. When the receiver's buffers approach capacity, the receiver sends the XOFF character to tell the sender to stop sending data. Later, after the receiver has emptied its buffers, it sends an XON character to tell the sender to resume transmission. It is an example of in-band signaling, where control information is sent over the same channel as its data.

The advantage of hardware handshaking is that it can be extremely fast; it doesn't impose any particular meaning such as ASCII on the transferred data; and it is stateless. Its disadvantage is that it requires more hardware and cabling, and these must be compatible at both ends.

The advantage of software handshaking is that it can be done with absent or incompatible hardware handshaking circuits and cabling. The disadvantage, common to all in-band control signaling, is that it introduces complexities in ensuring that a) control messages get through even when data messages are blocked, and b) data can never be mistaken for control signals. The former is normally dealt with by the operating system or device driver; the latter normally by ensuring that control codes are 'escaped' (such as in the Kermit protocol) or omitted by design (such as in ANSI terminal control).

If no handshaking is employed, an overrun receiver might simply fail to receive data from the transmitter. Approaches for preventing this include reducing the speed of the connection so that the receiver can always keep up; increasing the size of buffers so it can keep up averaged over a longer time; using delays after time-consuming operations (e.g. in termcap) or employing a mechanism to resend data which has been corrupted (e.g. TCP).

'Virtual' serial ports[edit]

A virtual serial port is an emulation of the standard serial port. This port is created by software which enable extra serial ports in an operating system without additional hardware installation (such as expansion cards, etc.). It is possible to create a large number of virtual serial ports in a PC. The only limitation is the amount of resources, such as operating memory and computing power, needed to emulate many serial ports at the same time.

Virtual serial ports emulate all hardware serial port functionality, including baud rate, data bits, parity bits, stop bits, etc. Additionally, they allow controlling the data flow, emulating all signal lines (DTR, DSR, CTS, RTS, DCD, and RI) and customizing pinout. Virtual serial ports are common with Bluetooth and are the standard way of receiving data from Bluetooth-equipped GPS modules.

Virtual serial port emulation can be useful in case there is a lack of available physical serial ports or they do not meet the current requirements. For instance, virtual serial ports can share data between several applications from one GPS device connected to a serial port. Another option is to communicate with any other serial devices via internet or LAN as if they are locally connected to computer (serial over LAN/serial-over-Ethernet technology). Two computers or applications can communicate through an emulated serial port link. Virtual serial port emulators are available for many operating systems including MacOS, Linux, NetBSD and other Unix-like operating systems, and various mobile and desktop versions of Microsoft Windows.

See also[edit]

• ITU-T/CCITT V.24 [de]
• ITU-T/CCITT V.28 [de]

References[edit]

1. ^Webopedia (2003-09-03). 'What is serial port? - A Word Definition From the Webopedia Computer Dictionary'. Webopedia.com. Retrieved 2009-08-07.
2. ^'Serial Cable Connection Guide'. CISCO. 2006-08-01. Retrieved 2016-01-31.
3. ^'RS232 - DTE and DCE connectors'. Lantronix. 2006-03-29. Retrieved 2016-01-31.
4. ^Yost Serial Device Wiring Standard
5. ^Ögren, Joakim. 'Serial (PC 9)'.
6. ^ ^abCyclom-Y Installation Manual, page 38, retrieved on 29 November 2008^{[permanent dead link]}
7. ^'RJ-45 8-Pin to Modem (ALTPIN option)'. Digiftp.digi.com. Retrieved 2014-02-08.
8. ^National Instruments Serial Quick Reference Guide, February 2007
9. ^'RJ-45 10-Pin Plug to DB-25 Modem Cable'. Digiftp.digi.com. Retrieved 2014-02-08.
10. ^Hardware Book RS-232D
11. ^RS-232D EIA/TIA-561 RJ45 Pinout
12. ^'OptiPlex XE Powered Serial Port Configuration'(PDF).
13. ^'Powered Serial Cards - Brainboxes'.
14. ^'HOWTO: Specify Serial Ports Larger than COM9'. Microsoft support. Retrieved 2013-10-26.
15. ^'Paul's 8051 Code Library, IDE Hard Drive Interface'. Pjrc.com. 2005-02-24. Retrieved 2014-02-08.
16. ^'IDE Hard Disk experiments'. Hem.passagen.se. 2004-02-15. Archived from the original on 2004-04-15. Retrieved 2014-02-08.
17. ^'The Solution for Seagate 7200.11 HDDs - Hard Drive and Removable Media issues - MSFN Forum'. Msfn.org. Retrieved 2014-02-08.
18. ^'Fixing a Seagate 7200.11 Hard Drive'. Sites.google.com. Retrieved 2014-02-08.
19. ^'SERIAL_COMMPROP structure'. Microsoft. 2018-04-22. Retrieved 2019-09-28.
20. ^ ^ab'DCB Structure'. Windows Dev Center. Microsoft. 2018-12-04. Retrieved 2019-09-28.
21. ^'PC16550D Universal Asynchronous Receiver/Transmitter With FIFOs'(PDF). Texas Instruments. May 2015. Retrieved September 25, 2019.
22. ^'BACnet MS/TP Overview Manual'(PDF). Neptronic. Retrieved September 26, 2019.
23. ^'MultiModem ZBA'(PDF). Multi-Tech Systems, Inc. January 2019. Retrieved September 26, 2019.
24. ^'Courier 56K Business Modem: User Guide: Controlling Data Rates'. USRobotics. 2007. Retrieved September 26, 2019.

Further reading[edit]

• Serial Port Complete: COM Ports, USB Virtual COM Ports, and Ports for Embedded Systems; 2nd Edition; Jan Axelson; Lakeview Research; 380 pages; 2007; ISBN978-1-931-44806-2.

External links[edit]

Flow control (= handshaking = pacing) is to prevent too fast of aflow of bytes from overrunning a terminal, computer, modem or otherdevice. Overrunning is when a device can't process what it isreceiving quickly enough and thus loses bytes and/or makes otherserious errors. What flow control does is to halt the flow of bytesuntil the terminal (for example) is ready for some more bytes. Flowcontrol sends its signal to halt the flow in a direction opposite tothe flow of bytes it wants to stop. Flow control must both be set atthe terminal and at the computer.

There are 2 types of flow control: hardware and software (Xon/Xoff orDC1/DC3). Hardware flow control uses dedicated signal wires such asRTS/CTS or DTR/DSR while software flow control signals by sending DC1or DC3 control bytes in the normal data wires. For hardware flowcontrol, the cable must be correctly wired.

The flow of data bytes in the cable between 2 serial ports isbi-directional so there are 2 different flows (and wires) to consider:

1. Byte flow from the computer to the terminal
2. Byte flow from the terminal keyboard to the computer.

You might ask: 'Why not send at a speed slow enough so that thedevice will not be overrun and then flow control is not needed?' Thisis possible but it's usually significantly slower than sending fasterand using flow control. One reason for this is that one can't justset the serial port baud rate at any desired speed such as 14,500,since only a discrete number of choices are available. The bestchoice is to select a rate that is a little higher than the device cankeep up with but then use flow control to make things work right.

If one decides to not use flow control, then the speed must be set lowenough to cope with the worst case situation. For a terminal, this iswhen one sends escape sequences to it to do complex tasks that take moretime than normal. In the case of a modem (with data compression butno flow control) the speed from the computer to the modem must be slowenough so that this same speed is usable on the phone line, since inthe worst case the data is random and can't be compressed. If onefailed to use flow control, the speed (with data compression turnedon) would be no faster than without using any compression at all.

Buffers are of some help in handling worst case situations of shortduration. The buffer stores bytes that come in too fast to beprocessed at once, and saves them for processing later.

Another way to handle a 'worst case' situation (without using flowcontrol or buffers) is to add a bunch of nulls (bytes of value zero) toescape sequences. Sometimes DEL's are used instead provided they haveno other function. See Recognize Del.

The escape sequence starts the terminal doing something, and while theterminal is busy doing it, it receives a bunch of nulls which itignores. When it gets the last null, it has completed its task and isready for the next command. /epson-aculaser-cx11nf-drivers-downloads.html. This is called null padding. These nullsformerly were called 'fill characters'. These nulls are added just to'waste' time, but it's not all wasted since the terminal is usuallykept busy doing something else while the nulls are being received. Itwas much used in the past before flow control became popular. To beefficient, just the right amount of nulls should be added and figuringout this is tedious. It was often done by trial and error sinceterminal manuals are of little or no help. If flow control doesn'twork right or is not implemented, padding is one solution. Some ofthe options to the stty command involve padding.

One might wonder how overrunning is possible at a serial portsince both the sending and receiving serial ports involved in atransmission of data bytes are set for the same speed (in bits/sec)such as 19,200. The reason is that although the receiving serial portelectronics can handle the incoming flow rate, the hardware/softwarethat fetches and processes the bytes from the serial port sometimescan't cope with the high flow rate.

One cause of this is that the serial port's hardware buffer isquite small. Older serial ports had a hardware buffer size of onlyone byte (inside the UART chip). If that one received byte of data inthe buffer is not removed (fetched) by CPU instructions before thenext byte arrives, that byte is lost (the buffer is overrun). NewerUART's, namely most 16550's, have 16-byte buffers (but may be set toemulate a one-byte buffer) and are less likely to overrun. It may beset to issue an interrupt when the number of bytes in its bufferreaches 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 incomingbytes out of this small hardware buffer and process them (as well asperform other tasks).

When contents of this small hardware receive buffer reaches thespecified limit (one byte for old UART'S) an interrupt is issued.Then the computer interrupts what it was doing and software checks tofind out what happened. It finally determines that it needs to fetcha byte (or more) from the serial port's buffer. It takes thesebyte(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 (ornearly 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 greaterthan the flow in the reverse direction from the keyboard to the hostcomputer, 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. Whenanother process has disabled interrupts (for a computer). 2. When theserial port buffer in main (or terminal) memory is about to overflow.

When its appears that the receiver is about to be overwhelmed byincoming bytes, it sends a signal to the sender to stop sending. Thatis flow control and the flow control signals are always sent in adirection opposite to the flow of data which they control (althoughnot in the same channel or wire). This signal may either be a controlcharacter (^S = DC3 = Xoff) sent as an ordinary data byte on the datawire (in-band signalling), or a voltage transition from positive tonegative in the dtr-to-cts (or other) signal wire (out-of-bandsignalling). Using Xoff is called 'software flow control' and usingthe voltage transition in a dedicated signal wire (inside the cable)is called hardware flow control.

With terminals, the most common case of 'stop sending' is wherethe terminal can't keep up with the characters being sent to it and itissues a 'stop' to the PC. Another case of this is where someonepresses control-S. Much less common is the opposite case where the PCcan't keep up with your typing speed and tells the terminal to stopsending. The terminal 'locks' its keyboard and a message or lightshould inform you of this. Anything you type at a locked keyboard isignored. When the PC catches up on it's work, then the keyboardshould unlock. When it doesn't, there is likely some sort of deadlockgoing on.

Another type of keyboard lock happens when a certain escape sequence(or just the ^O control character for Wyse 60) is sent to theterminal. While the previous type of lock is done by the serialdriver, this type of lock is done by the hardware of a real terminal.It's a catch-22 situation if this happens since you can't type anycommands to escape out of this lock. Going into setup and resettingmight work (but it failed on my Wyse 60 and I had to cycle power toescape). One could also send an 'unlock keyboard' escape sequencefrom another terminal.

The term 'locked' is also sometimes used for the common case of wherethe computer is told to stop sending to a terminal. The keyboard isnot locked so that whatever you type goes to the computer. Since thecomputer can't send anything back to you, characters you type don'tdisplay on the screen and it may seem like the keyboard is locked.Scrolling is locked (scroll lock) but the keyboard is not locked.

When the receiver has caught up with its processing and is readyto receive more data bytes it signals the sender. For software flowcontrol this signal is the control character ^Q = DC1 = Xon which issent on the regular data line. For hardware flow control the voltagein a signal line goes from negative (negated) to positive (asserted).If a terminal is told to resume sending the keyboard is then unlockedand ready to use.

Some older terminals have no hardware flow control while othersused a wide assortment of different pins on the serial port for this.For a list of various pins and their names see Standard Null Modem Cable Pin-out. Themost popular pin to use seems to be the DTR pin (or both the DTR pinand the DSR pin).

RTS/CTS, DTR, and DTR/DSR Flow Control

Linux PC's use RTS/CTS flow control, but DTR/DSR flow control(used by some terminals) behaves similarly. DTR flow control (in onedirection only and also used by some terminals) is only the DTR partof DTR/DSR flow control.

RTS/CTS uses the pins RTS and CTS on the serial (EIA-232) connector.RTS means 'Request To Send'. When this pin stays asserted (positivevoltage) at the receiver it means: keep sending data to me. If RTS isnegated (voltage goes negative) it negates 'Request To Send' whichmeans: request not to send to me (stop sending). When the receiver isready for more input, it asserts RTS requesting the other side toresume sending. For computers and terminals (both DTE type equipment)the RTS pin sends the flow control signal to the CTS pin (Clear ToSend) on the other end of the cable. That is, the RTS pin on one endof the cable is connected to the CTS pin at the other end.

For a modem (DCE equipment) it's a different scheme since the modem'sRTS pin receives the signal and its CTS pin sends. While this mayseem confusing, there are valid historical reasons for this which aretoo involved to discuss here.

Terminals usually have either DTR or DTR/DSR flow control. DTR flowcontrol is the same as DTR/DSR flow control but it's only one-way andthe DSR pin is not used. For DTR/DSR flow control at a terminal, theDTR signal is like the signal sent from the RTS pin and the DSR pin isjust like the CTS pin.

Connecting up DTR or DTR/DSR Flow Control

Some terminals use only DTR flow control. This is only one-wayflow control to keep the terminal from being overrun. It doesn'tprotect the computer from someone typing too fast for the computer tohandle it. In a standard file-transfer serial cable the DTR pin atthe terminal is connected to the DSR pin at the computer. But Linuxdoesn't support DTR/DSR flow control (although drivers for somemultiport boards may support DTR/DSR flow control.) A way around thisproblem is to simply wire the DTR pin at the terminal to connect tothe CTS pin at the computer and set RTS/CTS flow control (sttycrtscts). The fact that it's only one way will not affect anything solong as the host doesn't get overwhelmed by your typing speed and dropRTS in a vain attempt to lock your keyboard. See Keyboard Lock. For DTR/DSR flow control (ifyour terminal supports this two-way flow control) you do the above.But you also connect the DSR pin at the terminal to the RTS pin at thecomputer. Then you are protected if you type too fast.

Hardware Flow Control Serial Port Cable

Old RTS/CTS handshaking is different

What is confusing is that there is the original use of RTS whereit means about the opposite of the previous explanation above. Thisoriginal meaning is: I Request To Send to you. This request wasintended to be sent from a terminal (or computer) to a modem which, ifit decided to grant the request, would send back an asserted CTS fromits CTS pin to the CTS pin of the computer: You are Cleared To Send tome. Note that in contrast to the modern RTS/CTS bi-directional flowcontrol, this only protects the flow in one direction: from thecomputer (or terminal) to the modem.

For older terminals, RTS may have this meaning and goes high when theterminal has data to send out. The above use is a form of flowcontrol since if the modem wants the computer to stop sending it dropsCTS (connected to CTS at the computer) and the computer stops sending.

Reverse Channel

Old hard-copy terminals may have a reverse channel pin (such aspin 19) which behaves like the RTS pin in RTS/CTS flow control. Thispin but will also be negated if paper or ribbon runs out. It's oftenfeasible to connect this pin to the CTS pin of the host computer.There may be a dip switch to set the polarity of this signal.

Some think that hardware flow control is done by hardware butonly a small part of it is done by hardware. Most of it is actuallydone by your operating system software. UART chips and associatedhardware usually know nothing at all about hardware flow control.When a hardware flow control signal is received (due to the signalwire flipping polarity) the hardware gives an electrical interruptsignal to the CPU. However, the hardware has no idea what thisinterrupt means. The CPU stops what it was doing and jumps to a tablein main memory that tells the CPU where to go to find a program whichwill find out what happened and determine what to do about it. Inthis case this program stops the outgoing flow of bytes.

Serial Flow Control

But even before this program stops the flow, it was already stopped bythe interrupt which interrupted the work of the CPU. This is onereason why hardware flow control stops the flow faster. It doesn'tneed to wait for a program to do it. But if that program didn'tcommand that the flow be stopped, the flow would resume oncethat program exited. So the program is essential to stop the floweven though it is not the first to actually stop the flow. After theinterrupt happens any bytes (up to 16) which were already in theserial port's hardware transmit buffer will still get transmitted. Soeven with hardware flow control the flow doesn't instantly stop.

Hardware Flow Control Serial Port Number

Using software flow control requires that each incoming byte bechecked to see if it's an 'off' byte. These bytes are delayed bypassing thru the 16-byte receive buffer. If the 'off' byte was thefirst byte into this buffer, there could be a wait while 15 more byteswere received. Then the 16 bytes would get read and the 'off' bytefound. This extra delay doesn't happen with hardware flow control.

This is also software flow control and requires a device driverthat knows about it. Bytes are sent in packets (via the async serialport) with each packet terminated by an ETX (End of Text) controlcharacter. When the terminal gets an ETX it waits till it is ready toreceive the next packet and then returns an ACK (Acknowledge). Whenthe computer gets the ACK, it then send the next packet. And so on.This is not supported by Linux ?? Some HP terminals use the samescheme but use ENQ instead of ETX.

Linux Serial Port Hardware Flow Control