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 0x1A
3．標準Xmodem協議（每個數據包含有128字節數據）幀格式
2-1
|
SOH |
信息包序號 |
信息包序號的補碼 |
數據區段 |
校驗和 |
4．1k-Xmodem（每個數據包含有1024字節數據）幀格式
2-2
|
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就趕緊發送數據包響應。
YMODEM
由XMODEM演變來，效率可靠性高，包=128*8B；一次傳輸可發送或接受幾個文件。
XMODEM1K本質上是XMODEM CRC1K（1024字節）的數據包。在某些系統中，它也可以被稱爲YMODEM。有些通信軟件程序，著名的Procomm的1.x版本中，也將XMODEM-1K 稱爲YMODEM，但在Procomm的2.0版本中不再稱XMODEM-1K爲YMODEM。
YMODEM -G：YMODEM-G是一種YMODEM的變種。它被設計成用於支持錯誤控制的調制解調器。該協議不提供軟件糾錯或恢復，但預計調制解調器提供的服務。這是一個流媒體協議，在一個連續的數據流上發送和接收1K的數據包，直顯式停止。每塊被髮送後，它不會等待肯定的確認，而是快速連續地發送塊。如果任何塊傳輸失敗，本次傳輸將會失敗退出。
文件傳輸過程的開啓：
（1）開啓是由接收方開啓傳輸，它發一個大寫字母C開啓傳輸。然後進入等待（SOH）狀態，如果沒有迴應，就會超時退出。
（2）發送方開始時處於等待過程中，等待C。收到C以後，發送（SOH）數據包開始信號，發送序號（00），補碼（FF），“文件名”，“空格”“文件大小”“除去序號外，補滿128字節”，CRC校驗兩個字節。進入等待（ACK）狀態。
（3）接收方收到以後，CRC校驗滿足，則發送ACK。發送方接收到ACK，又進入等待“文件傳輸開啓”信號，即重新進入等待“C”的狀態。
（4）前面接收方只是收到了一個文件名，限制正式開啓文件傳輸，Ymodem支持128字節和1024字節一個數據包。128字節以（SOH）開始，1024字節以（STX）開始。
接收方又發出一個“C”信號，開始準備接收文件。進入等待“SOH”或者“STX”狀態。
（5）發送接收到“C”以後，發送數據包，（SOH）（01序號）（FE補碼）（128位數據）（CRC校驗），等待接收方“ACK”。
（6）文件發送完以後，發送方發出一個“EOT”信號，接收方也以“ACK”迴應。
然後接收方會再次發出“C”開啓另一次傳輸，若接着發送方會發出一個“全0數據包”，接收方“ACK”以後，本次通信正式結束。
（7）當然YMODEM相對於XMODEM改進的地方就在於傳輸再次開啓以後，又可以發送另外一個文件，即一次傳輸允許發送多個文件。
所用到的符號
#define MODEM_SOH 0x01 //數據塊起始字符
#define MODEM_STX 0x02 //1028字節開始
#define MODEM_EOT 0x04 //文件傳輸結束
#define MODEM_ACK 0x06 //確認應答
#define MODEM_NAK 0x15 //出現錯誤
#define MODEM_CAN 0x18 //取消傳輸
#define MODEM_C 0x43 //大寫字母Ｃ
CRC計算方法
in_ptr = mblock->buf; //指向要計算CRC的緩衝區開頭
cksum = 0; //
for (stat=mblock->len ; stat>0; stat--) //len是所要計算的長度
{
cksum = cksum^(int)(*in_ptr++) << 8; //
for (i=8; i!=0; i--)
{
if (cksum & 0x8000)
cksum = cksum << 1 ^ 0x1021;
else
cksum = cksum << 1;
}
}
ZMODEM
與上兩種不同，可以連續的數據流發送數據，效率更高
在具體的環境中，通過多次採用的xmodem的傳輸可以發現，不管是直接傳輸，還是按照網上 的說法採用rz sz傳輸，都很難將文件正確傳輸到嵌入式設備上。當採用zmodem進行傳輸的時候卻發現傳輸的效率很高，幾乎沒有失敗。
Zmodem協議有兩個顯着的特點：它是非常有效的，它提供了類似於YMODEM-G的崩潰恢復機制，Zmodem協議不會等待肯定的確認後，每個塊被髮送，而是快速連續地發送塊。 Zmodem協議傳輸如果因任何原因被取消或中斷，恢復後，先前傳送的信息都需要重新發送。
原文：小貓吃柿子的博客——KERMIT,XMODEM,YMODEM,ZMODEM傳輸協議小結
