【整理】串列埠(RS232/RS485等)通訊中RTS/CTS,DTR/DSR的含義詳解
【背景】
之前就折騰過很多關於RTS/CTS,DTR/DSR的內容：
【整理】HART協議中串列埠配置和Handshake（RTS/CTS等）
但是至今還是覺得，沒有徹底明白，還有有一點點迷惑。
現在重新去整理相關知識。
【折騰過程】
1.參考：
What is the difference between DTR/DSR and RTS/CTS flow control?
先貼出縮寫的含義：
- DTR – Data Terminal Ready
- DSR – Data Set Ready
- RTS – Request To Send
- CTS – Clear To Send
對應的相關的其他術語還有：
- DCE：Data Communication Equipment，可以理解為：資料的發起發
- DTE：Data Terminal Equipment，可以理解為：資料的接收方
然後瞭解到：
The difference between them is that they use different pins. Seriously, that’s it. The reason they both exist is that RTS/CTS wasn’t supposed to ever be a flow control mechanism, originally; it was for half-duplex modems to coordinate who was sending and who was receiving. RTS and CTS got misused for flow control so often that it became standard.
RTS/CTS和DTR/DSR，是用的物理引腳是不同的；
而關於DTR/DSR和RTS/CTS共存（沒有統一隻使用單個的一組硬體引腳（要麼用RTS/CTS，要麼用DTR/DSR）去實現流控制）的原因是：
背景是：
最開始先出現的RTS/CTS，但是設計出RTS/CTS的初衷，即原先的目的，就不是把RTS/CTS去用來當做流控制的
-> 而是用來：去協調兩個半雙工（工作模式下的）的貓modem之間的通訊
-> 不至於讓兩個半雙工的modem，在通訊時，互相掐架，互相搶佔資料通道，互相同時要麼都要傳送資料，要麼都要接受資料，由此而容易導致混亂和（總線上的）資料異常
-> 但是結果，（被設計用於協調兩個兩個半雙工的modem之間的通訊的）RTS/CTS，結果被大家誤用，誤當做（後來大量出現和使用的，全雙工的串列埠等裝置中的）流控制
-> 即，對於都是全雙工的兩個串列埠來說：
計算機（上面的串列埠） <-> （開發板或其他裝置上面的）串列埠
分別對應著的概念是：
DCE <-> DTE
此處，分別叫做：
資料傳送方 <-> 資料接收方
此處，暫且叫做：
串列埠A <-> 串列埠B
此時就是：
A打算髮送資料到B中
A設定RTS（Request To Send），表示：請求傳送（資料到對方）
此時：
- 正常情況下，資料接收方，B不忙的時候，即不是busy的狀態，則：
- B去設定對應的CTS（Clear To Send）：
- 兩種理解，不確定是哪種：
- 清除（傳送者A之前的設定的RTS），表示可以接受資料了
- Clear表示OK，清楚，明白，意思是明白對方的意思了，表示對方可以傳送資料了
- -> 傳送者A，就可以直接去傳送資料給B了，B也就可以去接受資料，處理收到的資料了；
- 偶爾特殊的時候，處於忙的狀態，即busy，比如忙著處理上次傳送的資料呢，所以沒空理會你這次還要發的資料：
- 那麼此時就是：不去設定對應的CTS，表示自己忙，來不及處理你將要傳送的資料
- -> 資料傳送者A，見狀，就繼續檢測CTS，直到（資料接受者B，忙清了自己手上的活，有空接受資料了，然後）CTS被接受者B去設定對應的CTS，表示可以接受資料了，然後A才去傳送資料給B
2.參考：
中，又進一步瞭解到：
DTR/DSR，主要是用來做：
建立連結
即：
資料傳送和接受之前，先要建立A和B的連線
這時候，才用到DTR/DSR
3.參考：
RS232 serial null modem cable wiring
目前來說：
還是沒有完全明白作者解釋的幾種連線方式。
我們目前所常見的，遇到的，都是DB9的兩個埠，直接相接。
感覺應該是：
Null modem with partial handshaking
即：
A的RTS，CTS，分別接B的CTS，RTS
A的Tx，Rx，分別接B的Rx和Tx
但是，感覺，普通的DB9直接接DB9的話，應該是：
A的RTS，CTS，分別接B的RTS，CTS
A的Tx，Rx，分別接B的Rx和Tx
看了別的一些資料：
也是各種接法都有。
目前還是不太確定如何接的。
4.其他一些參考資料：
Introduction to Serial Communications
RS232 Specifications and standard
5.後來是看了：
RS232 Specifications and standard
後，又進一步的搞懂了一些內容：
之前的那套邏輯：
A設定RTS表示要傳送資料給B，而B設定CTS表示可以接受資料，通知A傳送資料給B，A就開始去真正的傳送資料給B了
的背景是：
硬體連線是：
A的RTS<->B的RTS
A的CTS<->B的CTS
對應的
A一般是計算機PC
B一般是接在PC上的一個modem貓
對應的，A要傳送資料給B的執行過程是：
- A設定A的RTS：表示要發資料給B；
- A檢測A的CTS：
- 如果A的CTS是被設定了，那說明B設定了B的CTS
- 表示B可以接受資料了
- A就去傳送資料給B了
- 如果A的CTS沒被設定，那說明B沒有去設定B的CTS
- 說明B還出於busy忙的狀態
- 等B忙清了，再去設定B的CTS
- 此時A才能檢測到A的CTS，是被設定了，才能傳送資料給B
而如果交叉連線：
A的RTS<->B的CTS
A的CTS<->B的RTS
則就變成了其所說的：
非貓連線（null modem connection)（模式）
此時：
A的RTS，就不是：A用來通知B，A要傳送資料（給B）了
就變成了：
A用於指示（告訴）B，A是否可以接受資料
即：
A的RTS，由於連著B的CTS，所以如果A直接檢測到A被設定了
那麼說明B已經設定了B的CTS（就傳到了對應的A的RTS），此時A就可以直接通過檢測A的RTS，而判斷出B是否可以接受資料
所以就是從：
物理上RTS/CTS直連：
A的RTS<->B的RTS
A的CTS<->B的CTS
的：
A想要傳送資料給B之前：需要兩個步驟：（1）去設定一次A的RTS，（2）並且通過檢測A的CTS，去判斷是否可以傳送資料給B
變成了：
物理上RTS/CTS交叉連線：
A的RTS<->B的RTS
A的CTS<->B的CTS
的：
A想要傳送資料給B之前：直接一個步驟就實現了：（1）直接檢測A自己的RTS，即B的CTS，是否被設定，如果被設定了，直接傳送資料
由此：
簡化了資料傳送前的執行步驟，提高了資料傳輸的效率
當然，當：
物理上RTS/CTS交叉連線
時，對應的軟體的流控制協議，也要根據上述的邏輯，去做對應的改動；
【總結】
1.RTS/CTS之間協調工作，實現流控制的邏輯，目前的理解是：
對於都是全雙工的兩個串列埠來說： 計算機（上面的串列埠） <-> （開發板或其他裝置上面的）串列埠 分別對應著的概念是： DCE <-> DTE 此處，分別叫做： 資料傳送方 <-> 資料接收方 此處，暫且叫做： 串列埠A <-> 串列埠B 此時就是： A打算髮送資料到B中 A設定RTS（Request To Send），表示：請求傳送（資料到對方） 此時：
|
2.但是對於目前常見的，直接兩個DB9的串列埠直接相連，物理上對應的引腳的接法：
估計是：
A的RTS，CTS，分別接B的RTS，CTS A的Tx，Rx，分別接B的Rx和Tx |
3.目前對於DTR/DSR的理解：
主要是用來做：建立連結
即：
資料傳送和接受之前，先要建立A和B的連線
這時候，才用到DTR/DSR