電子產(chǎn)業(yè)一站式賦能平臺

PCB聯(lián)盟網(wǎng)

搜索
查看: 1312|回復(fù): 0
收起左側(cè)

武漢arm嵌入式培訓(xùn)_關(guān)于嵌入式系統(tǒng)中通訊協(xié)議設(shè)計的規(guī)律淺析

[復(fù)制鏈接]

2607

主題

2607

帖子

7472

積分

高級會員

Rank: 5Rank: 5

積分
7472
跳轉(zhuǎn)到指定樓層
樓主
發(fā)表于 2020-7-24 12:23:44 | 只看該作者 回帖獎勵 |正序瀏覽 |閱讀模式
武漢arm嵌入式培訓(xùn)_關(guān)于嵌入式系統(tǒng)中通訊協(xié)議設(shè)計的規(guī)律淺析,   

公司里做項目,嵌入式系統(tǒng)大大小小,到處都是。因為都是一個系統(tǒng)里的,所以都需要通訊,既然通訊就涉及到協(xié)議問題。

談及協(xié)議,很多工程師覺得協(xié)議的設(shè)計相對簡單,主要是報文的設(shè)計。大多數(shù)時候,協(xié)議的應(yīng)用場景簡單,沒有復(fù)雜的交互。這么做的確也是沒什么太大的問題。然而,就是這么簡單的場景,仍有一些協(xié)議會在實際中發(fā)生意想不到的問題。歸根結(jié)蒂,還是沒有把握協(xié)議涉及的規(guī)律。下面我們簡單的聊聊協(xié)議設(shè)計的規(guī)律。

  

協(xié)議設(shè)計中面臨的問題:

1.設(shè)計者大多數(shù)情況下,從應(yīng)用出發(fā),僅僅考慮了基本需求的滿足,沒有考慮擴(kuò)展需求的滿足;

2.從osi七層理論上,我們往往設(shè)計的協(xié)議時站在比較高層的角度去設(shè)計,往往忽視了RS485/RS232, I2C, CAN, ETHERNET等物理層承載特點,設(shè)計缺乏對具體應(yīng)用的針對性,導(dǎo)致潛在問題的產(chǎn)生;

3.容錯和效率的考慮不足。

基本需求肯定是完成系統(tǒng)的基本功能。然而可能因為需求定義的不完整,系統(tǒng)設(shè)計人員沒有前瞻性;協(xié)議中沒有定義版本號,沒有對協(xié)議兼容性的測試,導(dǎo)致老產(chǎn)品和新產(chǎn)品協(xié)議不兼容,而又無法采用簡單的軟件辦法解決。這是個常見問題,最簡單的辦法是在握手協(xié)議中增加協(xié)議的版本號,用以判斷是否對該協(xié)議支持以及為后續(xù)的軟件做兼容準(zhǔn)備。協(xié)議看似好像只有報文設(shè)計,就像一個人一樣,他在父母的眼里永遠(yuǎn)是個孩子,在自己的孩子面前是父母,在朋友面前是朋友。我相信所有這些側(cè)面合起來才是一個完整的人。UML 從不同的角度去觀察系統(tǒng)會得到不同的圖。協(xié)議也是如此,協(xié)議的報文只是協(xié)議靜態(tài)特性的一個方面,協(xié)議還有更重要的動態(tài)特性。如出錯后怎么辦,重發(fā)?重發(fā)幾次?節(jié)點損壞如何從網(wǎng)絡(luò)中剔除?怎么樣才是一個完整的通訊過程?持續(xù)的時間是多少?最壞情況下是怎么樣的?最好的情況下是什么樣的?誰發(fā)起通訊?重要的協(xié)議可能要保證非?煽浚绾未_定接受者接收的完全正確,并且可靠執(zhí)行?往往這些問題已經(jīng)超出了對報文自身的考慮,而是對系統(tǒng)解決方法的一種設(shè)計。這里有個小例子,一個RS485的半工通訊,主機(jī)向從機(jī)發(fā)送數(shù)據(jù),希望從機(jī)可靠保存該數(shù)據(jù);從機(jī)接收到該數(shù)據(jù)驗證完畢后,寫入自身的存儲裝置,然后再回應(yīng)主機(jī),寫入成功或者失敗。但這里有個問題,rs485是個主/從結(jié)構(gòu),無法同時發(fā)送數(shù)據(jù),只能由主機(jī)點名從機(jī)回應(yīng)。如果寫入時間過長,從機(jī)回應(yīng)報文的時間也必定過長;如果從機(jī)很多的話,這個時間就經(jīng)不起浪費(fèi)了?赡苄薷臑,從機(jī)收到主機(jī)的信息后,立即應(yīng)答收到。主機(jī)再分發(fā)其他從機(jī)的數(shù)據(jù),分發(fā)完畢后,再由主機(jī)采用查詢協(xié)議查詢從機(jī)寫入的成功與否。 當(dāng)然,也可以采用一些系統(tǒng)級的辦法,只要從機(jī)收到數(shù)據(jù)后,從機(jī)一定保證數(shù)據(jù)寫入成功,那么這個問題也變得簡單了。主機(jī)也不用再查詢寫入是否成功了。軟件的設(shè)計也就相對簡單很多。

RS485/RS232也有雙工通訊,但在實際中用得少。這里除了省線材之外,恐怕最重要的是因為RS485/RS232不帶沖突檢測,要么采用大家輪樁做主機(jī),要么一個主機(jī),點名讓大家發(fā)言的辦法。所以,通訊采用一問一答的方法比較多,這比較符合半工的工作狀態(tài)。當(dāng)然不排除一些雙工的應(yīng)用場景。實際應(yīng)用中,大多數(shù)還是采用半工的辦法。這里協(xié)議的設(shè)計主要考慮單點較多;多播和單播,因為不能確定從機(jī)是否接收成功,所以重要的協(xié)議在多播和廣播之后還要查詢,這個是很麻煩的事情。軟件過程因此而復(fù)雜很多。RS485/RS232的通訊有自己的檢測錯誤的辦法,比如說奇偶校驗,奇偶校驗是一種簡單的錯誤校驗,并不能100%的擋住錯誤;對于可靠地協(xié)議,可能還是要設(shè)計自己的CRC或者校驗和等方法。但CRC校驗雖然可以用查表的辦法,但計算時間比奇偶校驗和校驗和等方法計算量還是過大了些。在一些實時性和低端應(yīng)用場合,可能時間開銷大了些。所以,如果報文不是過大,還是可以考慮奇偶校驗和校驗和;如果過大,先考慮crc8,再考慮crc16和crc32,不要一竿子切。

I2C的通訊一般只用于板級,但現(xiàn)在也有用于現(xiàn)場總線的趨勢。I2C設(shè)計之初是支持多主多從,兩個主機(jī)可以同時發(fā)送信息,仲裁獲勝的主機(jī)獲得總線,繼續(xù)發(fā)送。有仲裁不代表可以同時雙向發(fā)送信息,即主機(jī)和從機(jī)的地位還是不同的,主機(jī)點名從機(jī)回應(yīng)信息;雖然現(xiàn)在的CPU所帶的I2C硬件同時支持主模式和從模式,但在同一時刻,這兩個模式是不相容的。對于一個節(jié)點要么是主要么是從,而每次通訊都是由主發(fā)起,從被動接收,這就導(dǎo)致了和rs232無本質(zhì)的區(qū)別。且,I2C的物理層協(xié)議也決定了,其通訊方式也沒有rs232靈活,只能工作在半工狀態(tài)。兩個CPU傳遞一些簡單的信息,在CPU無多余的rs232情況下,還是非常有用得。由于是板級的通訊,信號的完整性保證了以后,基本上不可能存在錯誤,也不需要額外的校驗方法了。

Ethernet和CAN總線類似,所有節(jié)點對等,無主從之說,誰都可以發(fā)起信息。由于沖突的檢測,使得仲裁失敗的節(jié)點稍后重試,物理層完成,不需要軟件參與,因而給協(xié)議設(shè)計帶來了極大的便利。比如說,先前的那個問題,一個廣播協(xié)議出去,不再像 Rs232/rs485那樣,再去一一查詢確認(rèn)。有問題的設(shè)備直接上報問題就好。大大的簡便了問題的處理。RS232/RS485的節(jié)點如果發(fā)生問題,需要上報,也只能等到主機(jī)點名時才能有機(jī)會上報。Ethernet/Can就不用了,發(fā)生問題后,直接主動上傳?梢源_保問題和緊急情況的及時處理。如果Ethernet是基于TCP的協(xié)議,效率低了,但卻保證了很多特性,數(shù)據(jù)的順序到達(dá),可靠性等等。IP 層以下的協(xié)議有很大的問題就是不能保證數(shù)據(jù)的順序到達(dá),多個路徑的長短會影響協(xié)議到達(dá)的順序,有些系統(tǒng)在設(shè)計時為了效率,采用UDP或者M(jìn)AC層直接通訊。那么最好還是采用較為保守的策略,防止協(xié)議報文先后到達(dá)產(chǎn)生不必要的錯誤。Ethernet物理層 帶有CRC32校驗,自己再做校驗實在沒必要。

協(xié)議的效率是個較復(fù)雜的話題,以RS232為例,RS232如果1個起始位置,1個停止位置,沒有奇偶校驗。那么發(fā)送一個字節(jié)需要10Bit,對于9600bps的波特率,1秒鐘最多傳輸960個字節(jié)。大約是1ms一個字節(jié)。如果停止位加長,協(xié)議一次性運(yùn)送的有用的字節(jié)數(shù)還要更低。除去必要的幀頭,幀尾,地址,校驗信息,真正有用得信息除以總的總線上運(yùn)送的字節(jié)數(shù),就是協(xié)議的帶載能力。很顯然,如果我用多播和廣播,明顯地提高效率。對于RS232這種,廣播也許并不是個好的選擇,尤其是回頭確認(rèn)一遍。也許提高波特率是個不錯的主意。這隨之而來的問題是,1Mbps的通訊系統(tǒng),1Start,1stop, non-parity, 1個字節(jié)只需要10us,這么快的中斷不是普通的CPU能承受的。所以,可能需要DMA來接收。DMA 接收的話,就牽涉到變長的協(xié)議和定長的協(xié)議。變長的協(xié)議要動態(tài)的判斷是否收到一個完整的包,而定長的協(xié)議,對于高速的RS232有無可比擬的優(yōu)勢。大大降低計算的復(fù)雜度。定長的協(xié)議就牽涉到協(xié)議的長度。我們一般把最頻繁出現(xiàn)的協(xié)議的長度作為全部協(xié)議報文的長度。對于超長的協(xié)議,由于使用次數(shù)不多,拆成多條定長協(xié)議吧報文完成。比如說,我們的系統(tǒng)控制命令長度為所有協(xié)議的長度,因為80%的協(xié)議報文都是系統(tǒng)控制命令。而20%的報文是其他出現(xiàn)頻率較低的報文,如系統(tǒng)固件升級報文,本身固件的大小就很大,就算超長的報文也不可能容納?吵膳c控制命令報文等同的長度?此票容^零散,每包卻都有各自獨立性。都可以做單獨的報文發(fā)送,前后的耦合性降到最低,也就是說,雖然大協(xié)議被拆分成小的等長協(xié)議報文,每個等長報文在發(fā)送過程中出錯,可以單獨再發(fā)送,整個通信序列無需重置。通過合理的設(shè)計,協(xié)議的效率自然而然的就被提升了。

Ethernet的設(shè)計相對寬松,其底層太強(qiáng)大了。很多工作都做了,所以,等長不等長對Ethernet系統(tǒng)無所謂。關(guān)鍵要解決Ethernet的通信模型問題。如果是嵌入式服務(wù)器,TCP 保持半開鏈接不能太耗費(fèi)資源。如果是UDP或者mac層的協(xié)議,需要對協(xié)議序列的先后到達(dá)順序進(jìn)行解耦,防止出現(xiàn)不必要的問題。如果一個大協(xié)議包,需要拆成三個包發(fā)送,三個包順序任意無影響;任意包發(fā)生錯誤,只需要將錯誤包重發(fā)成功即可。Ethernet由于速度高,協(xié)議帶載能力可以得到很好的補(bǔ)充。另外,由于Ethernet是一個完美支持多播和廣播的網(wǎng)絡(luò),實際中使用廣播太多造成了廣播風(fēng)暴,導(dǎo)致網(wǎng)絡(luò)性能急劇下降,所以現(xiàn)在分了虛擬局域網(wǎng),就是為了抑制廣播風(fēng)暴,提高效率。實際使用中還是要盡量的合理設(shè)計系統(tǒng),避免過多的廣播協(xié)議的使用,以免拖慢整個網(wǎng)絡(luò)系統(tǒng)。
回復(fù)

使用道具 舉報

發(fā)表回復(fù)

您需要登錄后才可以回帖 登錄 | 立即注冊

本版積分規(guī)則


聯(lián)系客服 關(guān)注微信 下載APP 返回頂部 返回列表