RS232、RS485和TTL
作為一個底層軟體開發工程師，經常會碰到RS232、RS485和TTL這一類的問題。
之前總是碰到問題之後Google一下，把當下的問題解決了之後就不管了，過個一兩天就忘得一幹二淨，結果後續每次都會碰到類似的問題，都是從零開始地去解決，這種方式看起來當時快速解決了問題，結果在後續的開發中浪費了更多的時間。
為了解決這個問題，部落客決定一次性把這些東西給弄清楚
串行通信
串行通信是指 使用一條資料線，将資料一位一位地依次傳輸，每一位資料占據一個固定的時間長度。
其隻需要少數幾條線就可以在系統間交換資訊，特别适用于計算機與計算機、計算機與外設之間的短距離通信。
串行通信在傳輸方式上分為同步通信和異步通信，在傳輸方向上分為單工通信，半雙工通信，全雙工通信。
同步通信
顧名思義，同步通信需要通信雙方進行資料同步，一般表現為通信雙方在時鐘線上的統一,雙方在在資料的收發上是同時的，根據時鐘線的跳變來操作資料線實作發送(讀取)，常用的同步協定有SPI I2C。
異步通信
異步通信不需要建立資料同步即可傳輸資料，發送方按照一定的協定格式來發送資料，接收方接收到資料再根據協定進行解析，雙方的收發不需要同時進行，也不需要進行傳輸時的校驗，RS232，485和UART就屬于這一類。
同步通信和異步通信的比較
在這裡，我們不妨可以先思考一下，同步通信和異步通信最根本的差別是什麼？
同步通信，通信雙方遵循相同的時鐘，每一個幀資料的收發都是需要經過雙方共同确認，然後再進行下一幀傳輸。
而異步通信則不然，在發送發看來，需要發送資料的時候，隻負責把資料發出去就行了，接受方到底收沒收到或者怎麼解析不需要發送方操心。
從上述的原理上的差別出發，我們以發送0x55(01010101b)為例，可以發現兩者通信的差別：
在同步發送中，資料線上隻需要根據時鐘發送資料01010101，接收方同時也可以根據時鐘來解析收到的資料。
但是在異步發送中，因為沒有時鐘同步，如果發送方僅僅将資料01010101發送出來，接收方無法解析接收到的資料。原因有兩個：
- 接收方不知道資料是以一個什麼樣的間隔時間發送過來的，可能發送方的時鐘頻率和配置決定了發送為1bit/us，但是接收方的時鐘配置不一緻，就出現解析錯誤。
- 接受方無法判斷資料的開始和結束，如果資料線的預設電平為高，發送資料的第一位也為高，将難以判斷資料是從哪裡開始。
是以，針對這兩個問題，異步通信提出了兩個相應的解決方案：
- 通信雙方遵循相同的傳輸速率，即波特率
- 在通信協定中加入開始位，結束位，校驗位以實作資料的接收時解析。
同步通信和異步通信的優劣
- 可以看出，同步通信中的資料傳輸效率(注意是效率，非速率)要高于異步傳輸，同步傳輸效率一般能達到100%，而異步傳輸中傳輸的資料并非全是有效資料，像序列槽協定中，常用配置中(1停止位，無校驗)傳輸一個位元組需要傳送10bit。
- 在更複雜的應用中，同步傳輸可以做到點對多點的傳輸，多點可以共用一個時鐘線，可以輕松實作一點寫，多點讀的操作。而在異步通信中，無法确定接收方接收資料的時間，是以不适用于點對多點的傳輸。
- 在相同的時鐘頻率下，傳輸效率高的同步通信自然能達到更高的資料吞吐量。
- 異步傳輸在傳輸效率上比同步傳輸低，但是同時也省去了同步所需要的時間，尤其是在遠距離傳輸時，時鐘同步所帶來的開銷也是不容忽視的，是以在長距離的傳輸中，一般使用異步通信，如RS485就支援KM級别的距離傳輸，而SPI I2C一般都用于闆級通信。
- 異步傳輸不需要時鐘線，更容易實作且節省資源。
單工通信
單工即單向通信，在整個資料傳輸的過程中隻允許定向地傳輸資料
半雙工通信
雙工即雙向通信，半雙工指的是在同一時刻，隻允許一個方向的發送接收，就像兩個人打電話，A可以對B說話，B可以對A說話，但是A/B不能同時說話，那樣會造成混亂。
全雙工通信
全雙工通信就是允許資料在兩個方向上同時傳輸。資料的收和發之間不會互相影響。
RS232 RS485 TTL電平
RS232 RS485 TTL同屬于異步串行通信，這三種通信方式本質上是電平邏輯的差別。
RS232
RS232多用于電腦的序列槽，目前使用最廣泛的就DB9接口，即九線接口，目前一般的電腦主機後面都會有這樣的接口.
RS232電平采用負邏輯,
-15V ~ -3V 代表邏輯1
+3V ~ +15V 代表邏輯0
-3V ~ +3V 無意義
在早期還有DB25線的接口，後來IBM将标準改成9線接口。
這種信号傳輸方式決定了一根資料線即可實作資料傳輸，是以兩根信号線(TX RX)即可實作全雙工地資料傳輸,上圖中的其他信号腳類似于RTS/CTS等都是用于差錯控制，在較簡單的應用中隻需要GND RX TX即可。
RS232電平傳輸方式有一些明顯的缺點：
- 接口的信号電平值相對太高，容易損壞接口電路的晶片。
- 傳輸速率比較低，在異步傳輸時，波特率隻有20Kbps。
- 接口使用一根信号線和一根信号傳回線回路構成共地的傳輸模式，很容易産生共模幹擾，是以抗噪聲比較弱。
-
由于抗幹擾能力弱，易産生共模幹擾，是以傳輸距離并不遠。
針對RS232在這些方面的不足，于是不斷出現了一些新的标準，其中RS485是使用比較廣泛的标準。
RS485
RS485多用于長距離傳輸的應用場景，大多數是在工業場景中，RS485電平邏輯采用差分電平，即傳輸資料至少需要兩根信号線，根據兩根信号線電壓的內插補點來确定電平邏輯，發送端電平：
+2V ~ +6V 代表邏輯1
-2V ~ -6V 代表邏輯0
其他 無意義
接收端電平：
> +200mv 代表邏輯1
< -200mv 代表邏輯0
其他 無意義
由于在傳輸資料時需要兩根信号線同時工作，是以RS485隻能做到半雙工通信，在RS232上依然有以下優化：
- 差分信号抗幹擾能力強
- 傳輸距離大大加長，可以達到KM級别的傳輸
- 相對應RS232而言可以支援多點傳輸甚至聯網構成分布式系統。
- 傳輸速率可達到10M/bps。
TTL電平
目前我們熟知的單片機基本上都是使用的TTL電平的信号系統，這是計算機處理器控制的裝置内部各部分之間通信的通信标準。
TTL內建電路的全名是半導體-半導體邏輯內建電路（Transistor-Transistor Logic)。在傳統的單片機系統中，VCC(供電電壓)為5V，電平标準為：
輸出：
小于0.8V 代表邏輯0
大于2.4V 代表邏輯1
輸入：
小于1.2V 代表邏輯0
大于2.0V 代表邏輯1
其他 無意義
因為2.4V和5V之間還有很大的空閑，白白增加了系統的功耗，同時影響了速度，是以來後就把一部分砍掉了，也就是後來的LVTTL，LVTTL又分為3.3V、2.5V甚至更低電壓的LVTTL(Low Voltage TTL).在3.3V LVTTL,Vcc = 3.3V中，電平标準為:
輸出：
大于2.4V 代表邏輯1
小于0.4V 代表邏輯0
輸入：
小于0.8V 代表邏輯0
大于2V 代表邏輯1
其他 無意義
TTL電平輸入腳懸空時是内部認為是高電平。要下拉的話應用1k以下電阻下拉。
TTL電平無法進行長距離傳輸，抗幹擾能力弱，信号衰減較大。
TTL電平為邏輯電平而設計，基本用于闆級通信，單片機基本上都使用TTL信号系統。
無意義的電平
在上面的電平描述中，都提到了無意義的電平，事實上在資料的接收中，如果接收到一個無意義的電平，這時候的邏輯輸出是不确定的，有可能是正确的，有可能是錯誤的。
例如，RS232的系統中，需要傳輸資料0x55(01010101b)，但是在傳輸過程中由于幹擾，最低位的資料1電平在接收端為0V，即無意義電平，其他位正常，這時候在接收端的解析中可能出現接收資料為0x54和0x55的結果，即無意義電平的解析是不确定的，可能是正确結果，也可能不是。
串行通信流控
串行通信中的流控制
這裡講到的流，指的是資料流，資料在兩個序列槽之間傳輸時，常常出現一些意料之外的情況，比如通信雙方速率不一緻，又或者是接收端緩沖區溢出導緻資料丢失等等。
流控制專門為了解決這些問題而生，例如，當接收端的資料處理不過來時，就可以發出“不再接收”的信号，發送端收到信号馬上停止發送，等接收端可以繼續接收之後，再發送“繼續接收”的信号提醒發送端繼續發送。
流控制一般分為硬體流控制和軟體流控制，顧名思義，硬體流控制需要硬體上的支援，常用的有rts/cts,dts/cts信号線，流控制的信号在這些信号線上傳輸，而軟體流控制則是由軟體來實作，在傳輸過程中定義特殊字段來作為流控制信号。
硬體流控制
硬體流控制必須将相應的電纜線連上，用rts/cts(請求發送/清除發送)流控制時，應将通訊兩端的rts、cts線對應相連，資料終端裝置(如計算機)使用rts來起始數據機或其它資料通訊裝置的資料流，而資料通訊裝置(如數據機)則用cts來起動和暫停來自計算機的資料流。
這種硬體握手方式的過程為：
在程式設計時根據接收端緩沖區大小設定一個高位标志(可為緩沖區大小的75％)和一個低位标志(可為緩沖區大小的25％)，當緩沖區内資料量達到高位時，我們在接收端将cts線置低電平(送邏輯0)。
當發送端的程式檢測到cts為低後，就停止發送資料，直到接收端緩沖區的資料量低于低位而将cts置高電平。
rts則用來标明接收裝置有沒有準備好接收資料。
軟體流控制
由于電纜線的限制，我們在普通的控制通訊中一般不用硬體流控制，而用軟體流控制。一般通過xon/xoff來實作軟體流控制。
常用方法是：當接收端的輸入緩沖區内資料量超過設定的高位時，就向資料發送端發出xoff字元(十進制的19或control-s，裝置程式設計說明書應該有詳細闡述)，發送端收到xoff字元後就立即停止發送資料；當接收端的輸入緩沖區内資料量低于設定的低位時，就向資料發送端發出xon字元(十進制的17或control-q)，發送端收到xon字元後就立即開始發送資料。一般可以從裝置配套源程式中找到發送的是什麼字元。
但是這種流控制僅僅适用于字元流傳輸的情況，如果是傳輸二進制資料，很可能資料内容中就帶有xoff字元導緻出現差錯，是以軟體流控制還是有比較大的缺陷。
不同電平之間的互相轉換
在嵌入式的軟體開發過程中，經常要用到不同裝置之間的序列槽通信，既然這些序列槽分屬于不同的電平信号系統，自然是不能直接進行通信的。
比如：将RS232的TX連接配接到TTL電平的RX時，發送端發送邏輯0信号為+10V，但是+10V的信号很可能直接将TTL端的晶片損壞，因為TTL端隻支援0~5V的電平，是以在雙方進行通信的時候，需要對電平進行轉換才能進行通信。
對于電平的轉換，網上已經有非常成熟的方案可以直接使用：
好了，關于串行通信的問題讨論就到此為止了，如果朋友們對于這個有什麼疑問或者發現有文章中有什麼錯誤，歡迎留言
個人郵箱：[email protected]
原創部落格，轉載請注明出處！
祝各位早日實作項目叢中過，bug不沾身.
（完）
TTL電平部分參考：https://blog.csdn.net/lijiuyangzilsc/article/details/48599745