What's the difference between DTR/DSR and RTS/CTS hardware flow control? When is each one used? Why do we need more than one kind of hardware flow control? 🙂
The difference between DTR/DSR and RTS/CTS flow control
protocolsserial-port
Related Solutions
TCP
is a connection oriented stream over an IP network. It guarantees that all sent packets will reach the destination in the correct order. This imply the use of acknowledgement packets sent back to the sender, and automatic retransmission, causing additional delays and a general less efficient transmission than UDP
.
UDP
is a connection-less protocol. Communication is datagram oriented. The integrity is guaranteed only on the single datagram. Datagrams reach destination and can arrive out of order or don't arrive at all. It is more efficient than TCP
because it uses non ACK. It's generally used for real time communication, where a little percentage of packet loss rate is preferable to the overhead of a TCP
connection.
In certain situations UDP
is used because it allows broadcast packet transmission. This is sometimes fundamental in cases like DHCP
protocol, because the client machine hasn't still received an IP
address (this is the DHCP
negotiaton protocol purpose) and there won't be any way to establish a TCP
stream without the IP
address itself.
Tera Term has an entire scripting language called Tera Term Language (TTL). You can find all the commands on their website. The question is how do you execute a command?
Tera Term will execute commands from a TTL file. Create a text file with your one command, or any number of commands, and save the file with a .TTL extension.
In Tera Term click the "Control" menu, then select "Macro". This will allow you to navigate to your TTL file.
There are example TTL files in the Tera Term installation directory.
Also, a side detail I didn't see explained anywhere else: it is perfectly ok to change any of the serial port settings, without needing to disconnect and reconnect. You will need to rerun your macros, however. In my case, if I changed from 9600 baud to 115,200 baud, I would need to rerun my script to enable DTR and RTS.
My TTL file looks like this:
; enable dtr
setdtr 1
; clear rts
setrts 0
; now clear dtr, so that the system will reset and see rts clear
setdtr 0
Best Answer
There are multiple ways of doing things because there were never any protocols built into the standards. You use whatever ad-hoc "standard" your equipment implements.
Just based on the names, RTS/CTS would seem to be a natural fit. However, it's backwards from the needs that developed over time. These signals were created at a time when a terminal would batch-send a screen full of data, but the receiver might not be ready, thus the need for flow control. Later the problem would be reversed, as the terminal couldn't keep up with data coming from the host, but the RTS/CTS signals go the wrong direction - the interface isn't orthogonal, and there's no corresponding signals going the other way. Equipment makers adapted as best they could, including using the DTR and DSR signals.
EDIT
To add a bit more detail, its a two level hierarchy so "officially" both must happen for communication to take place. The behavior is defined in the original CCITT (now ITU-T) standard V.28.
The DCE is a modem connecting between the terminal and telephone network. In the telephone network was another piece of equipment which split off to the data network, eg. X.25.
The modem has three states: Powered off, Ready (Data Set Ready is true), and connected (Data Carrier Detect)
The terminal can't do anything until the modem is connected.
When the terminal wants to send data, it raises RTS and the modem grants the request with CTS. The modem lowers CTS when its internal buffer is full.
So nostalgic!