XMODEM

簡單通用，傳輸信息單位是“包=128B”,傳輸速度慢，適合電話線路質(zhì)量差的情況下使用。Xmodem是最廣泛使用的文件傳輸協(xié)議之一。原始的Xmodem協(xié)議使用128字節(jié)的數(shù)據(jù)包和一個簡單的“校驗和”的錯誤檢測方法。隨后的版本XMODEM-CRC，使用了更安全的循環(huán)冗余校驗（CRC）錯誤檢測方法。 Xmodem協(xié)議始終首先嘗試使用CRC。如果發(fā)送者不響應(yīng)CRC的請求，接收器轉(zhuǎn)移到校驗和模式，并繼續(xù)其請求傳輸。1．Xmodem協(xié)議是什么？　　XMODEM協(xié)議是一種串口通信中 廣泛用到的異步文件傳輸協(xié)議。分為標(biāo)準(zhǔn)Xmodem和1k-Xmodem兩種，前者以128字節(jié)塊的形式傳輸數(shù)據(jù)，后者字節(jié)塊為1k即1024字節(jié)，并且每個塊都使用一個校驗和過程來進(jìn)行錯誤檢測。在校驗過程中如果接收方關(guān)于一個塊的校驗和與它在發(fā)送方的校驗和相同時，接收方就向發(fā)送方發(fā)送一個確認(rèn)字節(jié) (ACK)。由于Xmodem需要對每個塊都進(jìn)行認(rèn)可，這將導(dǎo)致性能有所下降，特別是延時比較長的場合，這種協(xié)議顯得效率更低。    除了Xmodem，還有Ymodem，Zmodem協(xié)議。他們的協(xié)議內(nèi)容和Xmodem類似，不同的是Ymodem允許批處理文件傳輸，效率更高；Zmodem則是改進(jìn)的了Xmodem，它只需要對損壞的塊進(jìn)行重發(fā)，其它正確的塊不需要發(fā)送確認(rèn)字節(jié)。減少了通信量。2．Xmodem協(xié)議相關(guān)控制字符    SOH                       0x01    STX             0x02    EOT                       0x04    ACK                       0x06    NAK                       0x15    CAN                       0x18    CTRLZ                 0x1A3．標(biāo)準(zhǔn)Xmodem協(xié)議（每個數(shù)據(jù)包含有128字節(jié)數(shù)據(jù)）幀格式
---------------------------------------------------------------------------|     Byte1     |    Byte2    |     Byte3      |Byte4~Byte131|  Byte132   ||-------------------------------------------------------------------------||Start Of Header|Packet Number|~(Packet Number)| Packet Data |  Check Sum |--------------------------------------------------------------------------
SOH信息包序號信息包序號的補碼數(shù)據(jù)區(qū)段校驗和4．1k-Xmodem（每個數(shù)據(jù)包含有1024字節(jié)數(shù)據(jù)）幀格式2-2STX信息包序號信息包序號的補碼數(shù)據(jù)區(qū)段校驗和5．?dāng)?shù)據(jù)包說明    對于標(biāo)準(zhǔn)Xmodem協(xié)議來說，如果傳送的文件不是128的整數(shù)倍，那么最后一個數(shù)據(jù)包的有效內(nèi)容肯定小于幀長，不足的部分需要用CTRL- Z(0x1A)來填充。這里可能有人會問，如果我傳送的是bootloader工程生成的.bin文件，mcu收到后遇到0x1A字符會怎么處理？其實如 果傳送的是文本文件，那么接收方對于接收的內(nèi)容是很容易識別的，因為CTRL-Z不是前128個ascii碼，不是通用可見字符，如果是二進(jìn)制文件，mcu其實也不會把它當(dāng)作代碼來執(zhí)行。哪怕是Excel文件等，由于其內(nèi)部會有些結(jié)構(gòu)表示各個字段長度等，所以不會讀取多余的填充字符。否則 Xmodem太弱了。對于1k-Xmodem，同上理。6．如何啟動傳輸？    傳輸由接收方啟動，方法是向發(fā)送方發(fā)送"C"或者NAK(注意，這里提到的NAK是用來啟動傳輸?shù)摹Ｒ韵挛覀儠吹絅AK還可以用來對數(shù)據(jù)產(chǎn)生重傳的機 制)。接收方發(fā)送NAK信號表示接收方打算用累加和校驗；發(fā)送字符"C"則表示接收方想打算使用CRC校驗（具體校驗規(guī)則下文Xmodem源碼，源碼勝于雄辯)。7．傳輸過程    當(dāng)接收方發(fā)送的第一個"C"或者NAK到達(dá)發(fā)送方，發(fā)送方認(rèn)為可以發(fā)送第一個數(shù)據(jù)包，傳輸已經(jīng)啟動。發(fā)送方接著應(yīng)該將數(shù)據(jù)以每次128字節(jié)的數(shù)據(jù)加上包頭，包號，包號補碼，末尾加上校驗和，打包成幀格式傳送。發(fā)送方發(fā)了第一包后就等待接收方的確認(rèn)字節(jié)ACK，收到接收方傳來的ACK確認(rèn)，就認(rèn)為數(shù)據(jù)包被接收方正確接收，并且接收方要求發(fā)送方繼續(xù)發(fā)送下一個包； 如果發(fā)送方收到接收方傳來的NAK(這里，NAK用來告訴發(fā)送方重傳，不是用來啟動傳輸)字節(jié)，則表示接收方請求重發(fā)剛才的數(shù)據(jù)包；如果發(fā)送方收到接收方傳來的CAN字節(jié)，則表示接收方請求無條件停止傳輸。8．如何結(jié)束傳輸？    如果發(fā)送方正常傳輸完全部數(shù)據(jù)，需要結(jié)束傳輸，正常結(jié)束需要發(fā)送方發(fā)送EOT 字節(jié)通知接收方。接收方回以ACK進(jìn)行確認(rèn)。當(dāng)然接收方也可強制停止傳輸，當(dāng)接收方發(fā)送CAN 字節(jié)給發(fā)送方，表示接收方想無條件停止傳輸，發(fā)送方收到CAN后，不需要再發(fā)送 EOT確認(rèn)（因為接收方已經(jīng)不想理它了，呵呵）。9．特殊處理    雖然數(shù)據(jù)包是以 SOH 來標(biāo)志一個信息包的起始的，但在 SOH 位置上如果出現(xiàn)EOT則表示數(shù)據(jù)傳輸結(jié)束，再也沒有數(shù)據(jù)傳過來。接收方首先應(yīng)確認(rèn)數(shù)據(jù)包序號的完整性，通過對數(shù)據(jù)包序號取補，然后和數(shù)據(jù)包序號的補碼異或，結(jié)果為0表示正確，結(jié)果不為0則發(fā)送NAK請求重傳。    接收方確認(rèn)數(shù)據(jù)包序號正確后，然后檢查是否期望的序號。如果不是期望得到的數(shù)據(jù)包序號，說明發(fā)生嚴(yán)重錯誤，應(yīng)該發(fā)送一個 CAN 來中止傳輸。    如果接收到的數(shù)據(jù)包的包序號和前一包相同，那么接收方會忽略這個重復(fù)包，向發(fā)送方發(fā)出 ACK ，準(zhǔn)備接收下一個包。    接收方確認(rèn)了信息包序號的完整性和是正確期望的后，只對 128 字節(jié)的數(shù)據(jù)區(qū)段進(jìn)行算術(shù)和校驗，結(jié)果與幀中最后一個字節(jié)（算術(shù)校驗和）比較，相同發(fā)送 ACK，不同發(fā)送 NAK。10．校驗和的說明    Xmodem協(xié)議支持2種校驗和，它們是累加和與CRC校驗。    當(dāng)接收方一開始啟動傳輸時發(fā)送的是NAK，表示它希望以累加和方式校驗。    當(dāng)接收方一開始啟動傳輸時發(fā)送的是字符“C”，表示它希望以CRC方式校驗。    可能有人會問，接收方想怎么校驗發(fā)送方都得配合嗎，難道發(fā)送方必須都支持累加和校驗和CRC校驗？事實上Xmodem要求支持CRC的就必須同時支持累加和，如果發(fā)送方只支持累加和，而接收方用字符“C”來啟動，那么發(fā)送方只要不管它，當(dāng)接收方繼續(xù)發(fā)送“C”，三次后都沒收到應(yīng)答，就自動會改為發(fā)送 NAK，因為它已經(jīng)明白發(fā)送方可能不支持CRC校驗，現(xiàn)在接收方改為累加和校驗和發(fā)送方通訊。發(fā)送方收到NAK就趕緊發(fā)送數(shù)據(jù)包響應(yīng)。