- 想搞清楚linux下的終端(Terminal)、設備IO，以及Windows下的設備IO（可提醒IO、IO完成端口等），似乎這個古老的RS232串口還真是一個不錯的切入點。所以，從基礎開始，看看串口。
注：聆聽Oswald Buddenhagen教誨，Windows首字符一定要大寫，否則M$可能會不高興的^_^
DTE與DCE
|
DTE |
Data Terminal Equipment |
數據終端設備 |
|
DCE |
Data Circuit-terminating Equipment |
數據通信設備 |
一直以來每理清這兩個是什麼東西，比如說，我用電腦通過232串口直接控制一個分子泵，那麼誰是DTE、誰是DCE？
而理不清這個，就渾渾噩噩，始終弄不明白那些串口引腳如何工作的。原來：二者都是DTE
在遠古時代，比如一個大型主機和一個終端設備進行通訊，二者之間需要調制解調器進行信號調製：
DTE <==> DCE <======...=====>DCE <==> DTE
而現在呢，我們使用的一般都是：
DTE <=====> DTE
不用於遠距離傳輸，沒有DCE什麼事了。彼此都認爲自己連接的都是DCE。
9針串口
- RS-232C規標準接口有25條線，4條數據線、11條控制線、3條定時線、7條備用和未定義線，常用的只有9根
所以： 只關注目前還算很常見的 DE-9 pin 接口。假定是PC和一個modem相連。
|
名字 |
引腳(從PC角度) |
信號起源 |
作用 |
|
DTD |
1 |
DCE |
已經連接成功 |
|
DTR |
4 |
DTE |
通知對方自己已經就緒 |
|
DSR |
6 |
DCE |
|
|
RI |
9 |
DCE |
振鈴 |
|
RTS |
7 |
DTE |
PC請求發送數據 |
|
CTS |
8 |
DCE |
|
|
TxD |
3 |
DTE |
數據收發 |
|
RxD |
2 |
DCE |
|
|
GND |
5 |
common |
公共地 |
連線
只考慮兩個DTE連接的情況
3線
|
設備A |
設備B |
|
|
TxD |
---> |
RxD |
|
RxD |
<--- |
TxD |
|
Gnd |
---- |
Gnd |
TxD與RxD交錯鏈接，Gnd直連。
當直接這樣連線時，可以更近一步，將自己的RTS與CTS、DSR與DTR分別連起來。
這樣一來：
|
設備A |
設備B |
|
|
TxD |
---> |
RxD |
|
RxD |
<--- |
TxD |
|
Gnd |
---- |
Gnd |
|
RTS |
RTS |
|
|
DTR |
DTR |
效果就是，如果一方設置了硬件握手，發出握手請求的同時，就立即得到迴應(儘管我們自己知道這是假的)。
5線
|
設備A |
設備B |
|
|
TxD |
---> |
RxD |
|
RxD |
<--- |
TxD |
|
Gnd |
---- |
Gnd |
|
RTS |
---> |
CTS |
|
CTS |
<--- |
RTS |
加入了 RTS/CTS 握手。
7線
如果真的要多用一些線，可以使用7線鏈接。（接法不統一，這只是其中一種。當然，前面3線都不會有變化任何變化）
每個DTE可以發出3個信號TxD、RTS、DTR，加Gnd互聯，共7線。
|
設備A |
設備B |
|
|
TxD |
---> |
RxD |
|
RxD |
<--- |
TxD |
|
Gnd |
---- |
Gnd |
|
RTS |
---> |
DCD |
|
DCD |
<--- |
RTS |
|
DTR |
---> |
DSR |
|
DSR |
<--- |
DSR |
這樣一來 DTR/DSR 硬件握手就可以正常工作了。
- 當A方準備好，發出DTR信號，該信號直接聯至B的RI和DSR。即只要A準備好，B立即產生呼叫有效，並同時準備好。
- A的RTS和CTS相連，並與B的DCD互連。即：一旦甲方請求發送(RTS)，便立即得到允許(CTS)，同時，使B的DCD有效，即檢測到載波信號
流向控制
硬件流控
- RTS(Request To Send)/CTS(Clear To Send) 流控
- DTR(Data Terminal Ready)/DSR(Data Set Ready) 流控
軟件流控
- XON/XOFF
RTS/CTS
原本含義(主要是半雙工MODEM系統中發送方式和接收方式之間的切換)：
- RTS 用來表示DTE想DCE請求發送數據，即當終端要發送數據時，使該信號有效(ON)，向MODEM請求發送。它用來控制MODEM是否要進入發送狀態。
-
CTS 用來表示DCE準備好接收DTE發來的數據，是對請求發送信號RTS的響應信號。當MODEM已準備好接收終端傳來的數據，並向前發送時，使該信號有效，通知終端開始沿發送數據線TxD發送數據。
後來的變化(全雙工)：
- CTS 不再是 RTS的響應，它用來表示DCE是否允許發送數據。
windows
DCB 相關成員：
|
fRtsControl |
RTS_CONTROL_DISABLE 使得RTS保持off |
|
RTS_CONTROL_ENABLE 使得RTS保持on |
|
|
RTS_CONTROL_HANDSHAKE 啓用RTS握手 |
|
|
RTS_CONTROL_TOGGLE 根據有無數據可發送切換狀態 |
|
|
fOutxCtsFlow |
是否根據CTS的狀態才確定數據收發 |
DTR/DSR
DTR/DSR 一般情況下始終爲ON，通常用來通知對方設備是否連接正常並已經加電(powered-up)。
- DSR 有效時(ON)狀態，表明MODEM處於可以使用的狀態
- DTR 有效時(ON)狀態，表明數據終端處於可以狀態
但是設備製造商實現了各個非標準的變體，比如用來進行流控^_^
windows
DCB 相關成員：
|
fDtrControl |
DTR_CONTROL_DISABLE 保持off |
|
DTR_CONTROL_ENABLE 保持on |
|
|
DTR_CONTROL_HANDSHAKE 啓用硬件握手 |
|
|
fOutxDsrFlow |
是否根據DSR的狀態確定數據收發 |
|
fDsrSensitivity |
是否只接受DSR爲on時的數據 |
XON/XOFF
縮寫詞XOFF與 XON源於：transmit off 和 transmit on。x代表transmit/transmitter/....，前面遇到的 RxD，TxD也是這種情況。
|
ASCII碼值，十進制 |
名字 |
對應鍵盤按鍵 |
|
|
19 |
DC3(Device Control 1 ) |
CTRL+S |
^S |
|
17 |
DC1(Device Control 1 ) |
CTRL+Q |
^Q |
軟件流控使用這兩個字符，是一個事實標準。
注意：當使用這種流控方式時，兩個字符在帶內(in band)傳遞，所以我們將無法再直接傳輸這兩個字符，而只能自己根據需要進行轉義。
爲了健壯性，某些串口打印機每隔1~30秒發送一次 XON，以表明他們在線且準備好接受數據。
Windows
DCB結構中相關的成員：
|
fOutX |
數據發送時是否使用軟件流控（收到XOFF停止發送數據，收到XON重新開始） |
|
fInX |
數據接收時是否使用軟件流控（當前緩衝區快滿時發送XOFF，有空間時發送XON） |
|
fTXContinueOnXoff |
因接受緩衝區快滿而發送XOFF後，繼續發送發送緩衝區數據還是等待發送XON以後繼續 |
|
XonChar |
設置我們前面提到的2個流控字符 |
|
XoffChar |