Xmodem通信协议：

协议的细节这里不涉及，只说明一下编程注意的事项。数据包有两种：128bytes和1024bytes，tr800模块只支持128bytes。没有采用校验和，而是采用CRC（CCITT）校验。由于RAM有限及通信特性，Uart接收采用FIFO结构。

协议格式：
MESSAGE BLOCK LEVEL PROTOCOL, CRC MODE
 Each block of the transfer in CRC mode looks like:

<SOH><blk #><255-blk #><--128 data bytes--><CRC hi><CRC lo>
    in which:
<SOH>           = 01 hex
<blk #>     = binary number, starts at 01 increments by 1, and
             wraps 0FFH to 00H (not to 01)
<255-blk #> = ones complement of blk #.
<CRC hi>    = byte containing the 8 hi order coefficients of the CRC.
<CRC lo>    = byte containing the 8 lo order coefficients of the CRC.

Flow Diagram        

SENDER                            RECEIVER
                     <---          <C>
                           times out after 3 seconds,
                     <---          <nak>
<soh> 01 FE -data- <xx> --->
                     <---          <ack>
<soh> 02 FD -data- <xx> --->      (data gets line hit)
                     <---          <nak>
<soh> 02 FD -data- <xx> --->
                     <---          <ack>
<soh> 03 FC -data- <xx> --->
   (ack gets garbaged)  <---       <ack>
                           times out after 10 seconds,
                     <---          <nak>
<soh> 03 FC -data- <xx> --->
                     <---          <ack>
<eot>                --->
                     <---          <ack>

Program Tips：
* The character-receive subroutine should be called with a parameter specifying the number of seconds to wait.  The receiver should first call it with a time of 10, then <nak> and try again, 10 times.

* After receiving the <soh>, the receiver should call the character receive subroutine with a 1-second timeout, for the remainder of the message and the <cksum>.  Since they are sent as a continuous stream, timing out of this implies a serious like glitch that caused, say, 127 characters to be seen instead of 128.

* When the receiver wishes to <nak>, it should call a "PURGE" subroutine, to wait for the line to clear.  Recall the sender tosses any characters in its UART buffer immediately upon completing sending a block, to ensure no glitches were mis-interpreted.

* The most common technique is for "PURGE" to call the character receive subroutine, specifying a 1-second timeout,and looping back to PURGE until a timeout occurs.  The <nak> is then sent, ensuring the other end will see it.（关键：实现PURGE-字符接收子程序设定1s超时）

* You may wish to add code recommended by John Mahr to your character receive routine - to set an error flag if the UART shows framing error, or overrun.  This will help catch a few more glitches - the most common of which is a hit in the high bits of the byte in two consecutive bytes.  The <cksum> comes out OK since counting in 1-byte produces the same result of adding 80H + 80H as with adding 00H + 00H.

key：协议的流程、时间次数控制、出错处理。