RTS/CTS協(xié)議
RTS/CTS協(xié)議(Request To Send/Clear To Send)
即請求發(fā)送/允許發(fā)送協(xié)議，相當于一種握手協(xié)議，主要用來解決"隱藏終端"問題。"隱藏終端"（Hidden Stations）是指，基站A向基站B發(fā)送信息，基站C未偵測到A也向B發(fā)送，故A和C同時將信號發(fā)送至B，引起信號沖突，最終導致發(fā)送至B的信號都丟失了。"隱藏終端"多發(fā)生在大型單元中（一般在室外環(huán)境），這將帶來效率損失，并且需要錯誤恢復機制。當需要傳送大容量文件時，尤其需要杜絕"隱藏終端"現(xiàn)象的發(fā)生。IEEE802.11提供了如下解決方案。在參數(shù)配置中，若使用RTS/CTS協(xié)議，同時設置傳送上限字節(jié)數(shù)----一旦待傳送的數(shù)據(jù)大于此上限值時，即啟動RTS/CTS握手協(xié)議：首先，A向B發(fā)送RTS信號，表明A要向B發(fā)送若干數(shù)據(jù)，B收到RTS后，向所有基站發(fā)出CTS信號，表明已準備就緒，A可以發(fā)送，而其余欲向B發(fā)送數(shù)據(jù)的基站則暫停發(fā)送；雙方在成功交換RTS/CTS信號（即完成握手）后才開始真正的數(shù)據(jù)傳遞，保證了多個互不可見的發(fā)送站點同時向同一接收站點發(fā)送信號時，實際只能是收到接收站點回應CTS的那個站點能夠進行發(fā)送，避免了沖突發(fā)生。即使有沖突發(fā)生，也只是在發(fā)送RTS時，這種情況下，由于收不到接收站點的CTS消息，大家再回頭用DCF提供的競爭機制，分配一個隨機退守定時值，等待下一次介質空閑DIFS后競爭發(fā)送RTS，直到成功為止。
解釋一：
RTS：終端我準備發(fā)數(shù)據(jù)給你，快用CTS應答，準備好沒？
CTS：好了，來吧
解釋二：
CTS：主機，我有數(shù)據(jù)，請求接收
RTS：我是主機，就緒，請求發(fā)送。
SIMCOM公司的解釋，RTS和CTS似乎是獨立的
RTS是模塊的輸入端，用于MCU通知模塊，MCU是否準備好，模塊是否可向MCU發(fā)送信息，RTS的有效電平為低。
CTS是模塊的輸出端，用于模塊通知MCU，模塊是否準備好，MCU是否可向模塊發(fā)送信息，CTS的有效電平為低
一是RS232標準
二是MODEM的硬件流控
SIMCOM公司的解釋完全正確
很久很久以前，計算機還沒有出現(xiàn)，那時就已經(jīng)存在了(計算機)史前的串口設備(電傳打字機，工控測量設備，通信調(diào)制解調(diào)器)，為了連接這些串口，EIA制定了RS232標準，采用DB25接插件，支持同步和異步串口，D型的接口可以有效防止插反。標準化給使用帶來了便利。
時光荏苒，個人計算機出現(xiàn)了，這些已有的串口設備毫無疑問地成為了最初的外設，自然而然地RS232標準被個人計算機采納。但是設備制造商傾向于體積更小，成本更低的接口，因此，將DB25中未使用的和支持同步模式的引腳去掉，形成DB9。最初的情況相當混亂，因為DB9只定義了信號，卻沒有指定信號和引腳的對應關系，各個制造商只能自行定義。幸運的是，IBM的PC成了工業(yè)標準，DB9逐漸統(tǒng)一到IBM的定義上來。
DB9只有9根線，遵循RS232標準。定義如下：
DTR,DSR------DTE設備準備好/DCE設備準備好。主流控信號。
RTS,CTS------請求發(fā)送/清除發(fā)送。用于半雙工時，收發(fā)切換。屬于輔助流控信號。半雙工的意思是說，發(fā)的時候不收，收的時候不發(fā)。那么怎么區(qū)分收發(fā)呢？缺省時是DCE向DTE發(fā)送數(shù)據(jù)，當DTE決定向DCE發(fā)數(shù)據(jù)時，先有效RTS，表示DTE希望向DCE發(fā)送，一般DCE不能馬上轉換收發(fā)狀態(tài)，DTE就通過監(jiān)測CTS是否有效來判斷可否發(fā)送，這樣避免了DTE在DCE未準備好時發(fā)送所導致的數(shù)據(jù)丟失。
全雙工時，這兩個信號一直有效即可。
隨著計算機的日益普及，很多非RS232的串口也要接入PC機，如果為每一種新出現(xiàn)的串口都增加一個新的I/O口顯然不現(xiàn)實，因為PC后面板位置有限，因此，將RS232串口和非RS232串口都通過RS232口接入是最佳方案。UART的U(通用)指的就是這個意思。早期ROM BIOS和DOS里的通信軟件都是為RS232設計的，在沒有檢測到DCD有效前不會發(fā)送數(shù)據(jù)，因此，就連發(fā)送一個字符這樣樸素的應用也要給出DCD、DTR、DSR等控制信號。因此，串口接頭上要將一些控制線短接，或者干脆繞過系統(tǒng)軟件自己寫通信程序。
到此，UART的涵義就總結為：通用的 異步 (串行) I/O口。
就在UART冠以通用二字，準備一統(tǒng)江湖的時候，制造商們不滿于它的速度、體積和靈活性(軟件可配置)，推出了USB和1394串口。目前，筆記本上的UART串口有被取消的趨勢，因而有網(wǎng)友發(fā)出了“沒有串口，吾誰與歸”的慨嘆，古今多少事，都付笑談中，USB取代UART是后話，暫且不表。
話說自從賀氏(Hayes)公司推出了聰明貓(SmartModem)，他們制定的MODEM接口就成了業(yè)界標準，自此以后，所有公司制造的兼容貓都符合賀氏標準(連AT指令也兼容，大家一起抄他唄)。
細觀賀氏制定的MODEM串口，與RS232標準大不相同。DTR在整個通信過程中一直保持有效，DSR在MODEM上電后/可以撥號前有效(取決于軟件對DSR的理解)，在通信過程的任意時刻，只要DTR/DSR無效，通信過程立即終止。在某種意義上，這也可以算是流控，但肯定不是RS232所指的那種主流控。如果拘泥于RS232，你是不會理解DTR和DSR的用途的。
賀氏不但改了DTR和DSR，竟然連RTS和CTS的涵義也重新定義了。因此，RTS和CTS已經(jīng)不具有最開始的意義了。從字面理解RTS和CTS，是用于半雙工通信的，當DTE想從收模式改為發(fā)模式時，就有效RTS請求發(fā)送，DCE收到RTS請求后不能立即完成轉換，需要一段時間，然后有效CTS通知DTE：DCE已經(jīng)轉到發(fā)模式，DTE可以開始發(fā)送了。在全雙工時，RTS和CTS都缺省置為有效即可。然而，在賀氏的MODEM串口定義中，RTS和CTS用于硬件流控，和什么勞什子的全雙工/半雙工一點關系也沒有。
注意，硬件流控是靠軟件實現(xiàn)的，之所以強調(diào)“硬件”二字，僅僅是因為硬件流控提供了用于流量情況指示的硬件連線，并不是說，你只要把線連上，硬件就能自己流控。如果軟件不支持，光連上RTS和CTS是沒有用的。
RTS和CTS硬件流控的軟件算法如下：(RTS有效表示PC機可以收，CTS有效表示MODEM可以收，這兩個信號互相獨立，分別指示一個方向的流量情況。)
PC端處理：
發(fā). 當 發(fā)現(xiàn)（不一定及時發(fā)現(xiàn)） CTS (-3v to -15v)無效時，停止發(fā)送,
當 發(fā)現(xiàn)（不一定及時發(fā)現(xiàn)） CTS (3v to 15v)有效時，恢復發(fā)送；
收. 0<M<N<LEN_OF_RX_BUFFERS
當接收buffers中的bytes<M 時，給 RTS 有效信號（+3v to +15v),
當接收buffers中的bytes>N 時，給 RTS 無效信號（-3v to -15v);
MODEM端處理：
同上，但RTS與CTS交換。
聯(lián)系客服
