串口標準，說說流控制（RTS/CTS/DTR/DSR ）

"Data Terminal Equipment(數據終端設備)"的首字母縮略詞DTE，具有一定的數據處理能力和數據收發能力的設備，DTE提供或接收數據，例聯接到調制解調器上的計算機就是一種DTE。串行V.24端口（25針）通常規定DTE由第2根針腳作為TXD(發送數據線)，第3根針腳為RXD(接收數據線)，（其余針腳為：7是信號地線，4是DTS，5是RTS，6是DTR，8是DCD，以及包括發送時鐘、接收時鐘等等，都有規定具體的針腳）。

Data CommunicationsEquipment（數據通訊設備）的首字母縮略詞DCE,它在DTE和傳輸線路之間提供信號變換和編碼功能，并負責建立、保持和釋放鏈路的連接，如Modem。DCE設備通常是與DTE對接，因此針腳的分配相反，也就是2是接收，3是發送。

它們之間的區別是DCE一方提供時鐘，DTE不提供時鐘，但它依靠DCE提供的時鐘工作，比如PC機和MODEM之間。數據傳輸通常是經過DTE-DCE,再經過DCE-DTE的路徑。其實對于標準的串行端口，通常從外觀就能判斷是DTE還是DCE，DTE是針頭（俗稱公頭），DCE是孔頭（俗稱母頭），這樣兩種接口才能接在一起。

路由器通常是DTE設備，modem、GV轉換器等等傳輸設備通常被規定為DCE

RS232中RTS和CTS的作用

問：

以前挺明白的，今天一下子覺得以前的理解都不對了，以下三種解釋哪個對呢？

解釋一：

RTS：終端我已經準備就緒，有數據就發過來吧

CTS：來了，接招

解釋二：

RTS：終端我準備發數據給你，快用CTS應答，準備好沒？

CTS：好了，來吧

解釋三

CTS：主機，我有數據，請求接收

RTS：我是主機，就緒，請求發送。

我今天弄了個SIM100模塊，我將RTS設置無效之后，凡是要發往主機的數據都沒有發過來（包括主動數據RING），指令和指令返回結果都沒有返回，都緩存在模塊之中，等我將RTS設置有效后，緩存的數據全發來了，包括一大堆指令的執行結果，由此，我覺得上面的“解釋一”應該正確，而“解釋二”應該是錯的，但“解釋三”是否正確呢？就是說CTS和RTS哪個是發起者呢？

答：

一是錯的

二是RS232標準

三是MODEM的硬件流控

SIMCOM公司的解釋完全正確

很久很久以前，計算機還沒有出現，那時就已經存在了(計算機)史前的串口設備(電傳打字機，工控測量設備，通信調制解調器)，為了連接這些串口，EIA制定了RS232標準，采用DB25接插件，支持同步和異步串口，D型的接口可以有效防止插反。標準化給使用帶來了便利。

時光荏苒，個人計算機出現了，這些已有的串口設備毫無疑問地成為了最初的外設，自然而然地RS232標準被個人計算機采納。但是設備制造商傾向于體積更小，成本更低的接口，因此，將DB25中未使用的和支持同步模式的引腳去掉，形成DB9。最初的情況相當混亂，因為DB9只定義了信號，卻沒有指定信號和引腳的對應關系，各個制造商只能自行定義。幸運的是，IBM的PC成了工業標準，DB9逐漸統一到IBM的定義上來。

DB9只有9根線，遵循RS232標準。定義如下：

DTR,DSR------DTE設備準備好/DCE設備準備好。主流控信號。

RTS,CTS------請求發送/清除發送。用于半雙工時，收發切換。屬于輔助流控信號。半雙工的意思是說，發的時候不收，收的時候不發。那么怎么區分收發呢？缺省時是DCE向DTE發送數據，當DTE決定向DCE發數據時，先有效RTS，表示DTE希望向DCE發送，一般DCE不能馬上轉換收發狀態，DTE就通過監測CTS是否有效來判斷可否發送，這樣避免了DTE在DCE未準備好時發送所導致的數據丟失。

全雙工時，這兩個信號一直有效即可。

隨著計算機的日益普及，很多非RS232的串口也要接入PC機，如果為每一種新出現的串口都增加一個新的I/O口顯然不現實，因為PC后面板位置有限，因此，將RS232串口和非RS232串口都通過RS232口接入是最佳方案。UART的U(通用)指的就是這個意思。早期ROMBIOS和DOS里的通信軟件都是為RS232設計的，在沒有檢測到DCD有效前不會發送數據，因此，就連發送一個字符這樣樸素的應用也要給出DCD、DTR、DSR等控制信號。因此，串口接頭上要將一些控制線短接，或者干脆繞過系統軟件自己寫通信程序。

到此，UART的涵義就總結為：通用的 異步 (串行) I/O口。

就在UART冠以通用二字，準備一統江湖的時候，制造商們不滿于它的速度、體積和靈活性(軟件可配置)，推出了USB和1394串口。目前，筆記本上的UART串口有被取消的趨勢，因而有網友發出了“沒有串口，吾誰與歸”的慨嘆，古今多少事，都付笑談中，USB取代UART是后話，暫且不表。

話說自從賀氏(Hayes)公司推出了聰明貓(SmartModem)，他們制定的MODEM接口就成了業界標準，自此以后，所有公司制造的兼容貓都符合賀氏標準(連AT指令也兼容，大家一起抄他唄)。

細觀賀氏制定的MODEM串口，與RS232標準大不相同。DTR在整個通信過程中一直保持有效，DSR在MODEM上電后/可以撥號前有效(取決于軟件對DSR的理解)，在通信過程的任意時刻，只要DTR/DSR無效，通信過程立即終止。在某種意義上，這也可以算是流控，但肯定不是RS232所指的那種主流控。如果拘泥于RS232，你是不會理解DTR和DSR的用途的。

賀氏不但改了DTR和DSR，竟然連RTS和CTS的涵義也重新定義了。因此，RTS和CTS已經不具有最開始的意義了。從字面理解RTS和CTS，是用于半雙工通信的，當DTE想從收模式改為發模式時，就有效RTS請求發送，DCE收到RTS請求后不能立即完成轉換，需要一段時間，然后有效CTS通知DTE：DCE已經轉到發模式，DTE可以開始發送了。在全雙工時，RTS和CTS都缺省置為有效即可。然而，在賀氏的MODEM串口定義中，RTS和CTS用于硬件流控，和什么勞什子的全雙工/半雙工一點關系也沒有。

注意，硬件流控是靠軟件實現的，之所以強調“硬件”二字，僅僅是因為硬件流控提供了用于流量情況指示的硬件連線，并不是說，你只要把線連上，硬件就能自己流控。如果軟件不支持，光連上RTS和CTS是沒有用的。

RTS和CTS硬件流控的軟件算法如下：(RTS有效表示PC機可以收，CTS有效表示MODEM可以收，這兩個信號互相獨立，分別指示一個方向的流量情況。

最近在搗鼓一個GSM模塊，正好也要用到這東西，就baidu了一把，可以幫助我理解Datasheet的內容。看了上面的內容，我不知道各位明白了幾分，如果覺得都明白了，就不用看我廢話了。

還是先引用一些文字，來自Telit公司GM862 QUAD/PY的數據手冊

Pin Signal    I/O Function

20 C103/TXD I Serial data input (TXD) from DTE

29 C106/CTS O Output for Clear to send signal (CTS) to DTE

33 C107/DSR O Output for Data set ready signal (DSR) to DTE

37 C104/RXD O Serial data output to DTE

43 C108/DTR I Input for Data terminal ready signal (DTR) from DTE

45 C105/RTS I Input for Request to send signal (RTS) from DTE

注意上面各個功能的I/O的方向，看到這些縮寫的全稱，結合信號流向，是不是更容易理解呢。

DTE是數據發送的主動方，DCE是數據的接受方。

CTS是讓DTE明白的，也就是說DCE需要把自己的CTS給DTE看，讓他知道DEC已經準備好接受數據了。

RTS是DTE給DCE看的，告訴DCE，DTE有數據要發。