ymodemvc源碼

❶ 各位高手，請問xmodem/ymodem/zmodem有什麼區別

：XMODEM協議的控制字元
上表中各個縮寫也是標准ASCII碼的一個字元，在XMODEM協議中需要使用這些字元來表達協議的狀態。而其基本含義如表中所述。

2.2 數據幀格式與文件分解
XMODEM協議每次傳送的數據幀長度為132位元組，其中文件數據佔128位元組，其他4個位元組分別為開始標志，塊序號，塊序號的補碼和校驗位元組。其中開始標志，塊序號，塊序號的補碼位於數據塊開始， 校驗位元組位於數據塊結尾，如：

偏移 位元組數 名稱 描述 說明
名稱 數值(HEX)
0 1 SOH 01 起始位元組標志
1 1 Seq 1~FFh 塊序號
2 1 cmpl FFH-seq 塊序號的補碼
3 128 data ? 文件內容數據
131 1 csum ? 垂直累加和校驗 1：XMODEM協議允許使用2種校驗碼。2：校驗碼只從128位元組的數據進行計算後得出，頭部3個位元組不參加校驗和運算。
2 CRC ? 16位循環冗餘校驗
圖表 3：XMODEM協議的數據幀格式
如果文件長度不是128位元組的整數倍，最後一個數據塊的有效內容必然小於幀長，剩下部分需要用其他數據來填充，XMODEM建議使用「CTRL-Z」(=26（01aH）)，這種情況下，接收方如何區別該幀中屬於文件的內容和填充的內容呢？
如果傳送的文件是只包含字母、數字和可顯示符號的文本文件（例如C程序源代碼文件），那麼根據內容本身接收方是可以區分的（「26」不是字母或者數字的ASCII碼），如果傳送的是任意數值的二進制文件（如程序目標碼），則接收方是無法區分文件內容和填充內容。
重要提示：XMODEM協議不能保證接收方接收的文件長度和發送方完全一致，接收方所接收的文件數據長度總是128位元組的整數倍，比發送文件的實際長度要大1到127位元組。多出的內容位於文件結尾處。
XMODEM協議的這種缺點對於用於嵌入式系統的程序代碼下裝沒有實際影響，處理器不會將填充內容當作代碼執行，只要程序存儲器的容量足夠，能存儲接收的所有數據就可以了。如果將XMODEM協議用於資料庫下裝，應當考慮多餘內容的影響，一般標准資料庫文件中均有表示資料庫尺寸、欄位數、記錄數等資料庫結構參數，所以也不會把填充內容當作資料庫的記錄本身。
同樣，對於漢字型檔這種資料庫，使用XMODEM協議來下載也不會產生問題。

2.3 校驗演算法
校驗碼是對發送數據進行某種計算得到的編碼，為了防止數據在發送途中某些位發生錯誤，各種數據通信協議規定發送方除了發送應用數據外，還要發送校驗碼，而數據接收方則根據同樣演算法從收到的應用數據中計算出校驗碼，並和發送方發送的校驗碼比較，如相等，才認為收到了正確的數據。
在XMODEM協議中，可使用垂直累加和或者CRC校驗，使用CRC校驗的通信軟體可以自動從CRC校驗自動切換到累加和校驗模式。在本應用中，我們使用垂直累加和校驗。
累加和校驗碼是將所有發送數據的和按位元組累加，保留其最低位元組作為校驗碼，例如，發送的3個位元組數據分別為255（FFh）,5(05h),6(06h), 則：
1 1 1 1 1 1 1 1 FFH
0 0 0 0 0 1 0 1 05H
0 0 0 0 0 1 1 0 06H

1 0 0 0 0 1 0 1 0 －> 0000 1010
將高位丟棄後，得到累加和校驗碼為0Ah（10）。在上例中，如果原來數據在途中發生了變化，如FFH變為FEH,06H變為07H, 05H未變，則接收方所計算的校驗碼為：
接收 發送
1 1 1 1 1 1 1 0 FEH <- FFH
0 0 0 0 0 1 0 1 05H < - 05H
0 0 0 0 0 1 1 1 07H <- 06H

1 0 0 0 0 1 0 1 0 －> 0000 1010
校驗碼也為0AH。可見，在數據中有2位改變時，接收方所計算的校驗碼仍然與發送方一致，這種校驗方式不能檢測偶數位的誤碼。
XMODEM協議的校驗碼只對數據幀中的128位元組數據進行計算後得出，頭部3個位元組不參加校驗和運算。

2.4 XMODEM協議的啟動
XMODEM協議開始是文件接收方發出「NAK」位元組，文件發送方在收到該信號後發送數據幀，雙方開始正常通信過程。而文件發送方進入XMODEN協議後，等待對方發送」NAK」,如果等待時間超過60秒，則退出本次通信。
接收方發出「NAK」後，如果10秒後對方還沒有發送第一個數據幀，則重復發送「NAK」，這種重復次數最多允許10次，仍然沒有收到第一個數據塊，則退出本次通信。

（A）：發送方軟體延遲100秒以上工作導致不能啟動協議

（B）：接收方軟體延遲60秒發送」NAK」信號導致不能啟動協議

圖表 4 XMODEM協議不能啟動的2種情況
在嵌入式系統通過PC機來下載軟體的應用中，嵌入式系統軟體是文件接收方，PC機超級終端軟體是文件發送方。按照協議規定，嵌入式系統 的通信軟體進入XMODEM協議狀態後，PC機軟體必須在100秒內進入協議狀態（即執行超級終端的XMODEM文件傳輸功能），反之，後者先進入協議狀態，前者必須在60秒內進入協議狀態，顯然，通過人工來操作，這種時間差有些緊張。解決辦法只有加長嵌入式系統載入軟體的啟動等待時間，這種修改不會引起協議理解的歧義。

重要提示：為了發送和接收方能夠更容易啟動XMODEM協議，在設計中，將延長嵌入式系統下載軟體的啟動延時時間，在以下的代碼中，將這種延時時間改為600秒（10分鍾）。或者將等待時間設置為無限長，一致發出」NAK」信號，直到PC機上的超級終端軟體運行為止。

2.5 XMODEM的正常傳輸過程
中給出了一次正常的XMODEM通信中收發雙方的通信過程。

圖 5：沒有差錯的文件傳輸過程
文件接收方每收到一個數據幀後，如沒有校驗差錯、序號差錯等情況，均發送一個「ACK」字元作為應答，發送方在收到應答後才開始發送下一個字元，如此反復，直到文件內容傳送完畢，發送方傳送「EOT」字元表示傳送完成，發送方收到後再次以「ACK」回應，至此，整個文件傳輸過程就結束了。

2.6 XMODEM協議的中止
在通信進行過程中，雙方中的任意一方如果希望中止本次通信，可以發送「CAN」字元給對方，現在很多XMODEM協議軟體要求發送2個」CAN」字元來實現，
協議軟體的主動中止通信一般是人為發起的，例如按下超級終端軟體的「取消」按鈕。或者通過拔碼開關來控制嵌入式系統的下載軟體退出通信。

2.7 XMODEM協議的異常處理
在通信過程中，總是要出現各種異常情況，比如通信線路的突然中斷，一方機器停電而導致軟體中止執行等；通信軟體必須能夠檢測這些錯誤，並作出合理的處理。在前面的協議啟動一節中已經涉及到了錯誤檢測的問題，XMODEM對錯誤的規定很詳細，共計有8種情況，協議文本沒有說明是如何引起的，中給出了可能原因，
在嵌入式系統中，考慮到下載軟體一般均有人操作的，也可不考慮錯誤處理，這樣實現實現代碼會減小。在本文中，考慮到協議的完整性，考慮了各種錯誤的處理。

2.8 CRC校驗與累加和校驗方式的切換
XMODEM協議要求支持CRC校驗的通信軟體也能支持累加和校驗，這樣就可以和那些只支持累加和校驗的軟體進行通信，如果文件接收方只支持累加和，而發送方可支持CRC，接收方發送啟動信號為「NAK」，發送方收到後自動按累加和方式發送數據幀；如果相反，接收方支持CRC，而發送方支持累加和，接收方首先發出字母「C」來作為啟動信號，這時接收方應不理睬此信號，發送方在3秒後繼續發送信號「C」，共三次未收到應答後，改為發送「NAK」信號，表示使用累加和方式進行通信了。
如果通信雙方均採用CRC校驗，上述通信握手信號「NAK」用字母「C來代替，其他過程同上。
因為PC機超級終端軟體支持CRC模式，嵌入式系統作為文件接收方，只要發送「NAK」信號就能使對方自動按照校驗和方式通信了。

3 協議分層與層間介面
3.1 協議分層
我們將協議代碼分成3層：物理層，鏈路層和協議應用層。物理層用於控制UART器件，鏈路層處理XMODEM協議，應用層負責將收到的單個128位元組數據塊組合成一個完成的數據塊，並寫入程序存儲器緩沖區。這種分層，在程序移植時只要修改和硬體相關的物理層、應用層代碼，無需修改實現XMODEM協議的鏈路層代碼。
層與層之間通過消息來通信，XMODEM協議沒有規定分層結構和層間消息格式，這里將鏈路層與應用層之間、鏈路層和物理層之間的消息格式統一規定如下：
typedef struct {
int len; /* 消息內容長度，即Message中的內容位元組數 */
char mType; /* 層間消息類型, */
char Message[MAX_ MESSAGE_LEN]; /* 消息內容, 由發送進程填寫 */
} MessageOfLayer;
考慮到XMODEM數據幀為132位元組，定義常量「MAX_MESSAGE_LEN」為132位元組，按OSI標准，層間消息原語有數據請求、數據指示、響應、證實4種類型。給出了A方發送數據，B方接收數據時的層間消息類型圖 6: 單向數據傳送的層間消息順序：①②③④
消息1，2是承載實際數據的數據幀，消息3，4是傳送過程中的應答幀，表明數據已經正確傳送，必須說明的是，在發送數據的證實消息3不是從對方發出的，物理層在發送出數據後，立即向上一層發出證實消息。
在實際應用中，處理正常的數據傳送所需要的消息外，也需要定義一些控制管理消息，下面具體說明層間消息類型和作用。

3.2 鏈路層和物理層間的介面
n 數據請求：該消息用於向物理層發送XMODEM幀數據，包括132位元組的文件數據幀和NAK,ACK，CAN單位元組信號幀等，下載軟體只是接收文件，不需要發送132位元組的文件數據幀。
n 數據證實：物理層收到鏈路層的數據請求幀後，送到UART的緩沖器中，等發送緩沖器為空後，表明該位元組數據發送完成，向鏈路層發送證實消息，鏈路層接收到此消息後，就可以發送下一個位元組，實際上物理層傳送是一個無連接，證實消息不是由接收方產生的，不能表明對方已經正確接收到數據，而只表明已經發出數據。物理層協議一般也不提供有應答的傳輸機制。
n 數據指示：物理層在接收緩沖器滿後，將數據發送給鏈路層。
除了以上3個消息外，物理層和應用層之間還有以下2個消息：
n 啟動電路：由鏈路層向物理層發出，物理層在收到該協議後將串口進行初始化。
n 電路出錯：由物理層向鏈路層發出，用於報告物理層在數據傳送過程中的錯誤。
「數據響應」消息在本應用中不使用。

3.3 鏈路層和應用層間的介面
鏈路層和應用層之間的數據傳輸消息有二個：
n 數據塊指示：由鏈路層收到一個XMODEM協議幀（128位元組）後向應用層發出，應用層收到數據幀後寫入flash memory（PC版本寫入文件）。
n 數據塊塊響應：應用層收到XMODEM數據幀後，並寫入flash memory（PC版本寫入文件）後向鏈路層發出的響應信號。鏈路層收到響應後，向文件發送方發出「ACK」信號。
其他管理控制消息定義了3個：
n 協議啟動：應用層通知鏈路層啟動XMODEM協議。
n 通信結束：鏈路層在收到對方的EOT信號後向應用層發出，應用層收到此消息後，可以轉入應用程序入口，從而執行應用程序。
n 通信中止：鏈路層因為各種情況無法繼續進行XMODEM傳輸時向應用層傳送該消息，應用層收到此消息後，丟棄已經收到的數據，發出通信錯誤指示。

4 分層協議實現
4.1 協議的OS平台
為了實現分層協議，使用中的非搶先式操作系統作為軟體平台，各層分別作為一個進程。

4.2 應用層軟體實現
嵌入式系統下載軟體只接收代碼文件，對於協議中作為文件發送方的處理代碼可不編寫，應用層的任務是接收鏈路層的數據包，根據收到數據包的先後次序寫入程序存儲器，在PC機上模擬實現時，我們將數據存放在一個緩沖區內，完成後寫入文件中，使用windiff軟體和發送文件進行比較，以判斷代碼的是否正確。
應用層的進程初始化代碼的作用是：
n 擦除程序存儲器所使用的FLASH MEMORY(在本例中按29F010來編寫代碼)。
n 啟動一個10秒定時器，10秒後通知鏈路層啟動XMODEM協議。
n

❷ xmodem ymodem 主要區別

內容提要：本文描述了使用XMOMDEM文件傳輸協議的通信程序設計，該設計為具有FLASH 存儲器的嵌入式系統提供了和PC機上超級終端軟體之間的文件傳輸功能，在PC機上不安裝專用通信軟體情況下，實現程序在板升級、數據在板定製等，給現場調試和維護帶來方便。另外，本文也描述了基於狀態矩陣的通信軟體編程方法。
關 鍵 字： XMODEM 文件下載 FSM 狀態矩陣

1 設計目的與用途
2 XMODEM協議介紹
3 協議分層與層間介面
3.1 協議分層
3.2 鏈路層和物理層間的介面
3.3 鏈路層和應用層間的介面
4 分層協議實現
4.1 協議的OS平台
4.2 應用層軟體實現
4.3 鏈路層軟體實現
4.4 物理層軟體實現
5 軟體移植
6 軟體調試方法

參考文獻

附錄1：XMODEM協議通信的異常情況列表
附錄2：XMODEM協議的狀態轉移表
附錄3：源代碼文件列表
附錄4：完整源代碼

1 設計目的與用途
嵌入式系統的程序代碼一般存放在FLASH存儲器或者OTP存儲器中，後者實際上是一種一次性可編程的EPROM，成本低，適合於批量大的產品使用，但程序寫入後不能修改，使用FLASH的優點是程序可以隨時在板更換，這種特點給現場調試和軟體升級、修改帶來極大方便。
對印製板上FLASH編程有幾種方法，原始的方法是使用編程器，由於要將晶元取下，十分不便，也有一些廠家生產的處理器通過JTAG介面或者串口連接到PC機上（如PHILIPS公司的P89C51RD），可以實現處理器內部FLASH的在板編程，但需要專用下載編程軟體（一般由晶元生產廠商提供），無法對處理器外部的FLASH進行編程。
使用XMODEM協議進行程序下載是目前很多產品通用的做法，比如CISCO公司的路由器產品，HUAWEI公司的ISDN終端產品，這種方法使用WINDOWS自帶的超級終端軟體來傳送文件，無需安裝專用軟體。只要在目標板上增加一斷實現XMODEM協議的代碼，就可以方便地實現程序或者數據文件的下載了。在下文中，就敘述XMODEM協議程序的實現方法。

圖表 1：目標板程序由二部分組成：下載程序和應用程序
2 XMODEM協議介紹
XMODEM協議是最早出現的2台計算機間通過RS232非同步串口進行文件傳輸的通信協議標准，相對於YMODEM,ZMODEM等其他文件傳送協議來說，XMODEM協議實現簡單，適合於那些存儲器有限的場合。
XMODEM文件發送方將文件分解成128位元組的定長數據塊，每發送一個數據塊，等待對方應答後才發送下一個數據塊，數據校驗採用垂直累加和校驗，也可以採用16位的CRC校驗。屬於簡單ARQ（自動請求重發）協議，所以也適合於2線制的半雙工的RS485網路中使用。

2.1 術語
在具體敘述XMODEM協議的具體內容前，我們先給出協議用到的術語縮寫。
術語 數值 含義 備注
十進制 十六進制
SOH 1 01H 數據塊開始
EOT 4 04H 發送結束
ACK 6 06H 認可響應
NAK 21 15H 不認可響應 對於CRC校驗的協議軟體，本信號用字母「C」（43H）代替。
DLE 16 10H 中止數據連接
X-on 17 11H 數據傳送啟動 當通信雙方的速度不一致時，可採用該字元來調節通信速度，比如接收方速度太慢而導致接收緩沖器滿時，發送「X-off」給發送方，使發送方暫停發送數據。相當於RS232介面的DSR,CTS等信號。
X-off 19 13H 數據傳送停止
SYN 22 16H 同步
CAN 24 18H 撤銷傳送
圖表 2：XMODEM協議的控制字元
上表中各個縮寫也是標准ASCII碼的一個字元，在XMODEM協議中需要使用這些字元來表達協議的狀態。而其基本含義如表中所述。

2.2 數據幀格式與文件分解
XMODEM協議每次傳送的數據幀長度為132位元組，其中文件數據佔128位元組，其他4個位元組分別為開始標志，塊序號，塊序號的補碼和校驗位元組。其中開始標志，塊序號，塊序號的補碼位於數據塊開始， 校驗位元組位於數據塊結尾，如：

偏移 位元組數 名稱 描述 說明
名稱 數值(HEX)
0 1 SOH 01 起始位元組標志
1 1 Seq 1~FFh 塊序號
2 1 cmpl FFH-seq 塊序號的補碼
3 128 data ? 文件內容數據
131 1 csum ? 垂直累加和校驗 1：XMODEM協議允許使用2種校驗碼。2：校驗碼只從128位元組的數據進行計算後得出，頭部3個位元組不參加校驗和運算。
2 CRC ? 16位循環冗餘校驗
圖表 3：XMODEM協議的數據幀格式
如果文件長度不是128位元組的整數倍，最後一個數據塊的有效內容必然小於幀長，剩下部分需要用其他數據來填充，XMODEM建議使用「CTRL-Z」(=26（01aH）)，這種情況下，接收方如何區別該幀中屬於文件的內容和填充的內容呢？
如果傳送的文件是只包含字母、數字和可顯示符號的文本文件（例如C程序源代碼文件），那麼根據內容本身接收方是可以區分的（「26」不是字母或者數字的ASCII碼），如果傳送的是任意數值的二進制文件（如程序目標碼），則接收方是無法區分文件內容和填充內容。
重要提示：XMODEM協議不能保證接收方接收的文件長度和發送方完全一致，接收方所接收的文件數據長度總是128位元組的整數倍，比發送文件的實際長度要大1到127位元組。多出的內容位於文件結尾處。
XMODEM協議的這種缺點對於用於嵌入式系統的程序代碼下裝沒有實際影響，處理器不會將填充內容當作代碼執行，只要程序存儲器的容量足夠，能存儲接收的所有數據就可以了。如果將XMODEM協議用於資料庫下裝，應當考慮多餘內容的影響，一般標准資料庫文件中均有表示資料庫尺寸、欄位數、記錄數等資料庫結構參數，所以也不會把填充內容當作資料庫的記錄本身。
同樣，對於漢字型檔這種資料庫，使用XMODEM協議來下載也不會產生問題。

2.3 校驗演算法
校驗碼是對發送數據進行某種計算得到的編碼，為了防止數據在發送途中某些位發生錯誤，各種數據通信協議規定發送方除了發送應用數據外，還要發送校驗碼，而數據接收方則根據同樣演算法從收到的應用數據中計算出校驗碼，並和發送方發送的校驗碼比較，如相等，才認為收到了正確的數據。
在XMODEM協議中，可使用垂直累加和或者CRC校驗，使用CRC校驗的通信軟體可以自動從CRC校驗自動切換到累加和校驗模式。在本應用中，我們使用垂直累加和校驗。
累加和校驗碼是將所有發送數據的和按位元組累加，保留其最低位元組作為校驗碼，例如，發送的3個位元組數據分別為255（FFh）,5(05h),6(06h), 則：
1 1 1 1 1 1 1 1 FFH
0 0 0 0 0 1 0 1 05H
0 0 0 0 0 1 1 0 06H

1 0 0 0 0 1 0 1 0 －> 0000 1010
將高位丟棄後，得到累加和校驗碼為0Ah（10）。在上例中，如果原來數據在途中發生了變化，如FFH變為FEH,06H變為07H, 05H未變，則接收方所計算的校驗碼為：
接收 發送
1 1 1 1 1 1 1 0 FEH <- FFH
0 0 0 0 0 1 0 1 05H < - 05H
0 0 0 0 0 1 1 1 07H <- 06H

1 0 0 0 0 1 0 1 0 －> 0000 1010
校驗碼也為0AH。可見，在數據中有2位改變時，接收方所計算的校驗碼仍然與發送方一致，這種校驗方式不能檢測偶數位的誤碼。
XMODEM協議的校驗碼只對數據幀中的128位元組數據進行計算後得出，頭部3個位元組不參加校驗和運算。

2.4 XMODEM協議的啟動
XMODEM協議開始是文件接收方發出「NAK」位元組，文件發送方在收到該信號後發送數據幀，雙方開始正常通信過程。而文件發送方進入XMODEN協議後，等待對方發送」NAK」,如果等待時間超過60秒，則退出本次通信。
接收方發出「NAK」後，如果10秒後對方還沒有發送第一個數據幀，則重復發送「NAK」，這種重復次數最多允許10次，仍然沒有收到第一個數據塊，則退出本次通信。

（A）：發送方軟體延遲100秒以上工作導致不能啟動協議

（B）：接收方軟體延遲60秒發送」NAK」信號導致不能啟動協議

圖表 4 XMODEM協議不能啟動的2種情況
在嵌入式系統通過PC機來下載軟體的應用中，嵌入式系統軟體是文件接收方，PC機超級終端軟體是文件發送方。按照協議規定，嵌入式系統 的通信軟體進入XMODEM協議狀態後，PC機軟體必須在100秒內進入協議狀態（即執行超級終端的XMODEM文件傳輸功能），反之，後者先進入協議狀態，前者必須在60秒內進入協議狀態，顯然，通過人工來操作，這種時間差有些緊張。解決辦法只有加長嵌入式系統載入軟體的啟動等待時間，這種修改不會引起協議理解的歧義。

重要提示：為了發送和接收方能夠更容易啟動XMODEM協議，在設計中，將延長嵌入式系統下載軟體的啟動延時時間，在以下的代碼中，將這種延時時間改為600秒（10分鍾）。或者將等待時間設置為無限長，一致發出」NAK」信號，直到PC機上的超級終端軟體運行為止。

2.5 XMODEM的正常傳輸過程
中給出了一次正常的XMODEM通信中收發雙方的通信過程。

圖 5：沒有差錯的文件傳輸過程
文件接收方每收到一個數據幀後，如沒有校驗差錯、序號差錯等情況，均發送一個「ACK」字元作為應答，發送方在收到應答後才開始發送下一個字元，如此反復，直到文件內容傳送完畢，發送方傳送「EOT」字元表示傳送完成，發送方收到後再次以「ACK」回應，至此，整個文件傳輸過程就結束了。

2.6 XMODEM協議的中止
在通信進行過程中，雙方中的任意一方如果希望中止本次通信，可以發送「CAN」字元給對方，現在很多XMODEM協議軟體要求發送2個」CAN」字元來實現，
協議軟體的主動中止通信一般是人為發起的，例如按下超級終端軟體的「取消」按鈕。或者通過拔碼開關來控制嵌入式系統的下載軟體退出通信。

2.7 XMODEM協議的異常處理
在通信過程中，總是要出現各種異常情況，比如通信線路的突然中斷，一方機器停電而導致軟體中止執行等；通信軟體必須能夠檢測這些錯誤，並作出合理的處理。在前面的協議啟動一節中已經涉及到了錯誤檢測的問題，XMODEM對錯誤的規定很詳細，共計有8種情況，協議文本沒有說明是如何引起的，中給出了可能原因，
在嵌入式系統中，考慮到下載軟體一般均有人操作的，也可不考慮錯誤處理，這樣實現實現代碼會減小。在本文中，考慮到協議的完整性，考慮了各種錯誤的處理。

2.8 CRC校驗與累加和校驗方式的切換
XMODEM協議要求支持CRC校驗的通信軟體也能支持累加和校驗，這樣就可以和那些只支持累加和校驗的軟體進行通信，如果文件接收方只支持累加和，而發送方可支持CRC，接收方發送啟動信號為「NAK」，發送方收到後自動按累加和方式發送數據幀；如果相反，接收方支持CRC，而發送方支持累加和，接收方首先發出字母「C」來作為啟動信號，這時接收方應不理睬此信號，發送方在3秒後繼續發送信號「C」，共三次未收到應答後，改為發送「NAK」信號，表示使用累加和方式進行通信了。
如果通信雙方均採用CRC校驗，上述通信握手信號「NAK」用字母「C來代替，其他過程同上。
因為PC機超級終端軟體支持CRC模式，嵌入式系統作為文件接收方，只要發送「NAK」信號就能使對方自動按照校驗和方式通信了。

3 協議分層與層間介面
3.1 協議分層
我們將協議代碼分成3層：物理層，鏈路層和協議應用層。物理層用於控制UART器件，鏈路層處理XMODEM協議，應用層負責將收到的單個128位元組數據塊組合成一個完成的數據塊，並寫入程序存儲器緩沖區。這種分層，在程序移植時只要修改和硬體相關的物理層、應用層代碼，無需修改實現XMODEM協議的鏈路層代碼。
層與層之間通過消息來通信，XMODEM協議沒有規定分層結構和層間消息格式，這里將鏈路層與應用層之間、鏈路層和物理層之間的消息格式統一規定如下：
typedef struct {
int len; /* 消息內容長度，即Message中的內容位元組數 */
char mType; /* 層間消息類型, */
char Message[MAX_ MESSAGE_LEN]; /* 消息內容, 由發送進程填寫 */
} MessageOfLayer;
考慮到XMODEM數據幀為132位元組，定義常量「MAX_MESSAGE_LEN」為132位元組，按OSI標准，層間消息原語有數據請求、數據指示、響應、證實4種類型。給出了A方發送數據，B方接收數據時的層間消息類型圖 6: 單向數據傳送的層間消息順序：①②③④
消息1，2是承載實際數據的數據幀，消息3，4是傳送過程中的應答幀，表明數據已經正確傳送，必須說明的是，在發送數據的證實消息3不是從對方發出的，物理層在發送出數據後，立即向上一層發出證實消息。
在實際應用中，處理正常的數據傳送所需要的消息外，也需要定義一些控制管理消息，下面具體說明層間消息類型和作用。

3.2 鏈路層和物理層間的介面
n 數據請求：該消息用於向物理層發送XMODEM幀數據，包括132位元組的文件數據幀和NAK,ACK，CAN單位元組信號幀等，下載軟體只是接收文件，不需要發送132位元組的文件數據幀。
n 數據證實：物理層收到鏈路層的數據請求幀後，送到UART的緩沖器中，等發送緩沖器為空後，表明該位元組數據發送完成，向鏈路層發送證實消息，鏈路層接收到此消息後，就可以發送下一個位元組，實際上物理層傳送是一個無連接，證實消息不是由接收方產生的，不能表明對方已經正確接收到數據，而只表明已經發出數據。物理層協議一般也不提供有應答的傳輸機制。
n 數據指示：物理層在接收緩沖器滿後，將數據發送給鏈路層。
除了以上3個消息外，物理層和應用層之間還有以下2個消息：
n 啟動電路：由鏈路層向物理層發出，物理層在收到該協議後將串口進行初始化。
n 電路出錯：由物理層向鏈路層發出，用於報告物理層在數據傳送過程中的錯誤。
「數據響應」消息在本應用中不使用。

3.3 鏈路層和應用層間的介面
鏈路層和應用層之間的數據傳輸消息有二個：
n 數據塊指示：由鏈路層收到一個XMODEM協議幀（128位元組）後向應用層發出，應用層收到數據幀後寫入flash memory（PC版本寫入文件）。
n 數據塊塊響應：應用層收到XMODEM數據幀後，並寫入flash memory（PC版本寫入文件）後向鏈路層發出的響應信號。鏈路層收到響應後，向文件發送方發出「ACK」信號。
其他管理控制消息定義了3個：
n 協議啟動：應用層通知鏈路層啟動XMODEM協議。
n 通信結束：鏈路層在收到對方的EOT信號後向應用層發出，應用層收到此消息後，可以轉入應用程序入口，從而執行應用程序。
n 通信中止：鏈路層因為各種情況無法繼續進行XMODEM傳輸時向應用層傳送該消息，應用層收到此消息後，丟棄已經收到的數據，發出通信錯誤指示。

4 分層協議實現
4.1 協議的OS平台
為了實現分層協議，使用中的非搶先式操作系統作為軟體平台，各層分別作為一個進程。

4.2 應用層軟體實現
嵌入式系統下載軟體只接收代碼文件，對於協議中作為文件發送方的處理代碼可不編寫，應用層的任務是接收鏈路層的數據包，根據收到數據包的先後次序寫入程序存儲器，在PC機上模擬實現時，我們將數據存放在一個緩沖區內，完成後寫入文件中，使用windiff軟體和發送文件進行比較，以判斷代碼的是否正確。
應用層的進程初始化代碼的作用是：
n 擦除程序存儲器所使用的FLASH MEMORY(在本例中按29F010來編寫代碼)。
n 啟動一個10秒定時器，10秒後通知鏈路層啟動XMODEM協議。
n