hi
1 Can anybody explain me please how hardware handshake work in RS232?
2 I assume new laptop dont have this capability? -
3 if that's true the selection for hardware control as shown below is not valid and should not be even visible- is this correct?

4 if my laptop had true rs232 port it will still depend on the driver whether hardware handshake will work - is it correct?
5 if hardware hanshake is used (with selection as shown below DTR/RTS) does it mean that signals RTS/CTS are not needed in that scenario?
6 Can signals DTR/RTS be monitored by software or are they not accessible for monitoring?

Sorry for so many questions but i find rs232 simple and confusing the same time - depending what level i try to understand that

Regards

 

Wikipedia has a pretty good explanation of handshaking. The complexities of communication over telephone lines through modems (recognizing a dial tone, ring indicator, carrier detect, dialing, hook pick-up) and the limitations on buffer size in an era of costly memory is why handshaking exists. I still see devices with half duplex RS--232 with only the Tx, Rx and ground and no handshaking because the expected data file transfer sizes are well within the buffer size in today's devices where memory is cheap. Note Wikipedia's statement on RTS/CTS vs DTR/DSR, "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." Lots of variation in RS-232 implementation over the years.

Here's Wikipedia's blurb:
------------------------------------------------
Flow control
Flow control is used in circumstances where 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 ASCII control characters XON/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).
===========================

 

Jan Axelson explains handshaking (from her book Serial Port Complete, 2nd edition)

With flow control, a transmitting computer can indicate when it has data to send, and a receiving computer can indicate when it’s ready to receive data. The computers in a serial link should use flow control unless the receive buffers are large enough to hold all of the data that might arrive before the receiving computer can read the data from the buffer.

In a common form of hardware flow control, the receiver sets a dedicated line to a defined state when ready to receive data. The transmitting computer checks the state of the line before sending data. If the line isn’t in the expected state, the transmitting computer waits. Flow control in both directions requires a line for each direction.

Flow control is sometimes called handshaking. However, a full handshake requires 2-way communication: the transmitting computer indicates that it has data to send, and the receiving computer indicates when it is ready to receive the data.

The RS-232 specification assigns names to flow-control signals. On a PC, the input signal is Clear To Send (CTS) and the output signal is Request to Send (RTS). (The names reflect an alternate usage of the lines to implement a full handshake.) A cable that connects two PCs must connect each RTS output to the other computer’s CTS input. A positive RS-232 voltage means ready to
receive and a negative voltage means not ready.

Microcontrollers typically don’t have dedicated CTS and RTS lines. Device firmware can use any spare port pins for flow control. Source code can use the names RTS and CTS or use names such as flow_control_in and flow_control_out to eliminate confusion about which signal is the input and which is the output.

Two additional RS-232 flow-control signals are Data Terminal Ready (DTR) and Data Set Ready (DSR). These lines were defined as a means for providing information about the status of a phone line or other communication channel on a modem that connects via RS-232 to a computer or terminal. On PCs, DTR is an output and DSR is an input. Microcontrollers typically don’t have dedicated DTR and DSR lines. Spare port pins with firmware support can provide these signals when needed. Chapter 5 has more about RS-232 signals.

Some links can use software flow control, where a receiving computer sends an Xon code to indicate that the computer is ready to receive and sends an Xoff code to tell the transmitter to stop sending. This method works only when sending data such as plain English text or another encoding that doesn’t use the Xon and Xoff codes in other data. The Xon code point is typically 11h (Control+Q), and Xoff is 13h (Control+S). Some software drivers enable selecting different codes.

A link can use hardware and software flow-control methods at the same time. The transmitting computer sends data only if the remote computer’s CTS line is high and the transmitting computer hasn’t received an Xoff.