Xmodem協議

Xmodem協議做爲串口數據傳輸主要的方式之一，恐怕只有作過bootloader的纔有機會 接觸一下，網上有關該協議的內容要麼是英語要麼講解不詳細。筆者之前寫bootloader時研究過1k-Xmodem，參考了很多相關資料。這裏和你們交流一下我對Xmodem的理解，多多指教！

 

1．Xmodem協議是什麼？
　　XMODEM協議是一種串口通訊中普遍用到的異步文件傳輸協議。分爲標準Xmodem和1k-Xmodem兩種，前者以128字節塊的形式傳輸數據，後者字節塊爲1k即1024字節，而且每一個塊都使用一個校驗和過程來進行錯誤檢測。在校驗過程當中若是接收方關於一個塊的校驗和與它在發送方的校驗和相同時，接收方就向發送方發送一個確認字節(ACK)。因爲Xmodem須要對每一個塊都進行承認，這將致使性能有所降低，特別是延時比較長的場合，這種協議顯得效率更低。
除了Xmodem，還有Ymodem，Zmodem協議。他們的協議內容和Xmodem相似，不一樣的是Ymodem容許批處理文件傳輸，效率更高；Zmodem則是改進的了Xmodem，它只須要對損壞的塊進行重發，其它正確的塊不須要發送確認字節。減小了通訊量。

 

2．Xmodem協議相關控制字符

        SOH     0x01
        STX     0x02
        EOT     0x04
        ACK     0x06
        NAK     0x15
        CAN     0x18
        CTRLZ   0x1A

 

3．標準Xmodem協議（每一個數據包含有128字節數據）幀格式
____________________________________________________________
|     |            |                  |          |         |
| SOH | 信息包序號 | 信息包序號的補碼 | 數據區段 |  校驗和 |
|_____|____________|__________________|__________|_________|

 

4．1k-Xmodem（每一個數據包含有1024字節數據）幀格式
___________________________________________________________
|     |            |                  |          |        |
| STX | 信息包序號 | 信息包序號的補碼 | 數據區段 | 校驗和 |
|_____|____________|__________________|__________|________|

 

5．數據包說明
對於標準Xmodem協議來講，若是傳送的文件不是128的整數倍，那麼最後一個數據包的有效內容確定小於幀長，不足的部分須要用CTRL-Z(0x1A)來填充。這裏可能有人會問，若是我傳送的是bootloader工程生成的.bin文件，mcu收到後遇到0x1A字符會怎麼處理？其實若是傳送的是文本文件，那麼接收方對於接收的內容是很容易識別的，由於CTRL-Z不是前128個ascii碼，不是通用可見字符，若是是二進制文件，mcu其實也不會把它看成代碼來執行。哪怕是excel文件等，因爲其內部會有些結構表示各個字段長度等，因此不會讀取多餘的填充字符。不然Xmodem太弱了。對於1k-Xmodem，同上理。

 

6．如何啓動傳輸？
傳輸由接收方啓動，方法是向發送方發送"C"或者NAK(注意哦，這裏提到的NAK是用來啓動傳輸的。如下咱們會看到NAK還能夠用來對數據產生重傳的機制)。接收方發送NAK信號表示接收方打算用累加和校驗；發送字符"C"則表示接收方想打算使用CRC校驗（具體校驗規則下文Xmodem源碼，源碼勝於雄辯)。

 

7．傳輸過程
當接收方發送的第一個"C"或者NAK到達發送方，發送方認爲能夠發送第一個數據包，傳輸已經啓動。發送方接着應該將數據以每次128字節的數據加上包頭，包號，包號補碼，末尾加上校驗和，打包成幀格式傳送。
發送方發了第一包後就等待接收方的確認字節ACK，收到接收方傳來的ACK確認，就認爲數據包被接收方正確接收，而且接收方要求發送方繼續發送下一個包；若是發送方收到接收方傳來的NAK(這裏，NAK用來告訴發送方重傳，不是用來啓動傳輸)字節，則表示接收方請求重發剛纔的數據包；若是發送方收到接收方傳來的CAN字節，則表示接收方請求無條件中止傳輸。

 

8．如何結束傳輸？
若是發送方正常傳輸徹底部數據，須要結束傳輸，正常結束須要發送方發送EOT 字節通知接收方。接收方回以ACK進行確認。固然接收方也可強制中止傳輸，當接收方發送CAN 字節給發送方，表示接收方想無條件中止傳輸，發送方收到CAN後，不須要再發送 EOT確認（由於接收方已經不想理它了，呵呵）。

 

9．特殊處理
雖然數據包是以 SOH 來標誌一個信息包的起始的，但在 SOH 位置上若是出現EOT則表示數據傳輸結束，再也沒有數據傳過來。
接收方首先應確認數據包序號的完整性，經過對數據包序號取補，而後和數據包序號的補碼異或，結果爲0表示正確，結果不爲0則發送NAK請求重傳。
接收方確認數據包序號正確後，而後檢查是否指望的序號。若是不是指望獲得的數據包序號，說明發生嚴重錯誤，應該發送一個 CAN 來停止傳輸。
若是接收到的數據包的包序號和前一包相同，那麼接收方會忽略這個重複包，向發送方發出 ACK ，準備接收下一個包。
接收方確認了信息包序號的完整性和是正確指望的後，只對 128 字節的數據區段進行算術和校驗，結果與幀中最後一個字節（算術校驗和）比較，相同發送 ACK，不一樣發送 NAK。

 

10．校驗和的說明
Xmodem協議支持2種校驗和，它們是累加和與CRC校驗。
當接收方一開始啓動傳輸時發送的是NAK，表示它但願以累加和方式校驗。
當接收方一開始啓動傳輸時發送的是字符「C」，表示它但願以CRC方式校驗。
可能有人會問，接收方想怎麼校驗發送方都得配合嗎，難道發送方必須都支持累加和校驗和CRC校驗？事實上Xmodem要求支持CRC的就必須同時支持累加和，若是發送方只支持累加和，而接收方用字符「C」來啓動，那麼發送方只要無論它，當接收方繼續發送「C」，三次後都沒收到應答，就自動會改成發送NAK，由於它已經明白髮送方可能不支持CRC校驗，如今接收方改成累加和校驗和發送方通信。發送方收到NAK就趕忙發送數據包響應。

 

11．Xmodem協議代碼
       看了以上說明，再參考代碼，應該很容易會理解代碼編寫者的思路。

 

文件: Xmodem協議說明.rar 大小: 495KB 下載: 下載