XMODEM

簡單通用，傳輸信息單位是“包=128B”,傳輸速度慢，適合電話線路質量差的情況下使用。Xmodem是最廣泛使用的文件傳輸協議之一。原始的Xmodem協議使用128字節的數據包和一個簡單的“校驗和”的錯誤檢測方法。隨后的版本XMODEM-CRC，使用了更安全的循環冗余校驗（CRC）錯誤檢測方法。 Xmodem協議始終首先嘗試使用CRC。如果發送者不響應CRC的請求，接收器轉移到校驗和模式，并繼續其請求傳輸。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                 0x1A3．標準Xmodem協議（每個數據包含有128字節數據）幀格式
---------------------------------------------------------------------------|     Byte1     |    Byte2    |     Byte3      |Byte4~Byte131|  Byte132   ||-------------------------------------------------------------------------||Start Of Header|Packet Number|~(Packet Number)| Packet Data |  Check Sum |--------------------------------------------------------------------------
SOH信息包序號信息包序號的補碼數據區段校驗和4．1k-Xmodem（每個數據包含有1024字節數據）幀格式2-2STX信息包序號信息包序號的補碼數據區段校驗和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就趕緊發送數據包響應。