来自：http://blog.163.com/czblaze_3333/blog/static/208996228201272295236713/
Kermit协议
报文格式：
1. MARK，起始标记START_CHAR，为 0x01（CTRIL-A）；
2. LEN，报文剩余部分的长度，取值范围0~94，报文最大长度96，长度不包含换行符或者制表符；
3. SEQ，数据包编号，取模64,；
4. TYPE，k_state数据包类型
|
D |
数据报文 |
|
Y |
ACK报文（不能转换编码） |
|
N |
NAK，未收到 |
|
S |
发送初始化报文 |
|
B |
传输结束 |
|
F |
文件头部 |
|
Z |
文件结束 |
|
E |
Error |
|
Q，T |
保留 |
NAK包用来说明等待的包没有正常接收，它不提供别的信息，例如不提供请求的服务之类。它的数据域总是空的。T报文用于内部kermit程序说明超时。
5．DATA，0~31,127这33个控制字符需要进行转换，前面加’#’，0~31之间加上64,127减去64处理。加过前缀的序列不要分散在不同的包。前缀字符也包含在计数之内。除S,I,A报文及其响应，都不能进行编码。
6．CHECK，假如S是整个报文字符的算术和，只是校验0~5位的和。
这是基本的默认块校验，所有的kermit都必须可以实施。
kermit报文发送过程
1.发送方首先发送一个初始化报文S（以0x01起始），确定报文长度，超时时间等；-->
<--接收方返回一个确认报文Y，在报文数据段存放自己的参数
2.发送方发送文件头报文F，在数据段包含文件名-->（如果发送多个文件，重复此步骤即可）
<--返回ACK，数据段可以不包含数据
3.开始发送文件内容，数据报文D，不在可打印ascii码范围内的，需要被提前替换成等价的可打印字符，每个数据报文都会收到ACK。
4.文件数据发送结束后，发送方发送文件尾报文Z，收方接收后确认。
5.没有文件需要发送时，发送传输结束报文B，并接收ACK，然后关闭连接，物理连接依然保留
每个报文都有编号，0~63之间。
XMODEM
这种古老的传输协议速度较慢，但由于使用了CRC错误侦测方法，传输的准确率可高达99.6%,传输信息单位是“包=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
与上两种不同，可以连续的数据流发送数据，效率更高。Zmodem采用了串流式（streaming）传输方式，传输速度较快，而且还具有自动改变区段大小和断点续传、快速错误侦测等功能。这是目前最流行的文件传输协议。
在具体的环境中，通过多次采用的xmodem的传输可以发现，不管是直接传输，还是按照网上 的说法采用rz sz传输，都很难将文件正确传输到嵌入式设备上。当采用zmodem进行传输的时候却发现传输的效率很高，几乎没有失败。
Zmodem协议有两个显着的特点：它是非常有效的，它提供了类似于YMODEM-G的崩溃恢复机制，Zmodem协议不会等待肯定的确认后，每个块被发送，而是快速连续地发送块。Zmodem协议传输如果因任何原因被取消或中断，恢复后，先前传送的信息都需要重新发送。
【背景】
在串口中传输文件，所用到的协议，常常有Kermit，Xmodem，Ymodem，Zmodem等，对这些协议，单独看名字，就很容易混淆，搞不懂都是啥意思。所以，写此文，总结各自的特点，解释他们之间的区别和联系。
【常见的RS232串口中所用到的传输协议之间的区别和联系】
此处主要讨论RS232即串口应用中，用来传输数据或文件的协议，主要有这些：
Kermit，Xmodem，Xmodem-1K，Ymodem，Ymodem-G，Ymodem-1K，Zmodem
|
协议名称 |
相同点 |
各自特性 |
说明 |
对应软件或命令 |
||
|
Kermit |
都是常见的文件传输协议，主要应用于RS232串口应用中 |
计算机系统中的文件传输和管理协议。 特点： （1）文本文件和二进制文件传输 （2）全双工，半双工（8 -bit），7-bit的串行连接； （3）协议对底层介质不做限制，跨平台性很好。 （4）已在N多平台中实现了此协议，即用途相当地广泛。 |
Kermit名字的来源是来自Kermit the Frog from The Muppets。 |
(1)Uboot中的loadb; |
||
|
XYZModem |
Xmodem |
Xmodem |
一个简单的文件传输协议。将文件拆分成很多个固定大小的数据包，数据包大小是128字节，然后以一个数据包，一个数据包的形式发送数据。中间会带有一些额外信息，用于握手协议等方面，以保证得知接收方正确接收了数据包。 要点： （1）将文件拆分，以固定大小的数据包发送。 （2）数据包大小Packet size=128Byte |
（1）Xmodem最开始是在早期的BBS系统中很流行，因为其协议足够简单，很容易实现。 （2）由于效率太低，导致其他很多人在此基础上去对其扩展，以提高性能。 （3）Chuck Forsberg收集了众多的扩展功能，以此形成Ymodem，但是由于没有很成功的实现，导致实际应用产生各种变体。 但是其后来设计了Zmodem，由于效果太好，导致完全取代了之前的各种Xmodem的变体，包括Ymodem。 |
(1)PC Linux中的rx/sx； (2)嵌入式Linux中lrzsz； |
|
|
Xmodem-1K |
即Ymodem-1K，详情参见Ymode-1K |
|||||
|
Ymodem |
Ymodem |
在Xmodem（和Modem7）的基础上开发出来的，本身协议和Xmodem是一样的，只是在文件传输开始之前，多加了个Block0，用于传输文件名，文件大小，时间戳等信息。 |
本来协议设计者Chuck Forsberg都设计了好多可选的特性，以便于此协议可以用到多种环境和平台中，然后再换个协议名称的。但是实际上实现了Ymodem的应用中，都只是支持了1KB的包大小和CRC模式，除此之外的其他一些特性，都没实现，所以后来就还是沿用了旧的Ymodem这一叫法。同时，也导致了现存的很多Ymodem互相不是很兼容。 |
(1)uboot中的loady命令； (2)PC Linux中的rb/sb； (3)嵌入式Linux中lrzsz； |
||
|
Ymodem-1K |
此协议是在，原先Ymodem的数据包大小是（同Xmodem协议相同的）128byte的基础上，改成了 Packet size=1024byte=1KB。 |
原先Ymodem协议中，数据包大小为1KB，是个可选的设置项。此Ymodem-1K，作为Ymodem的变体，却没有实现Ymodem其他的一些特性，所以，最好是叫做XModem-1K |
||||
|
Ymodem-G |
Ymodem的变体，流数据传输，用于信号很好（error-free）的传输环境中。 其（1）取消了CR（2）取消了，在发送下一个数据包之前，必须等待接受者的ACK |
由于取消CRC和ACK等待，此协议理论上，速度会比Zmodem快，但是实际上用此此协议的很少。因为，在16550 UAT出现之前，很明显，此协议有个严重的问题，那就是缓存溢出（buffer overrun），即接受者来不及处理数据，你就接着发下一个数据包了。 |
||||
|
Zmodem |
从Xmodem发展而来，取代了Ymodem，算是Ymodem的终结者。 核心改进在于，引入了滑动窗口（sliding window）以提高性能。 其支持很多特性： （1）可重传机制； （2）发送者可自动开始传输； （3）扩展的32位的CRC校验； （4）可传输控制字符； |
(1)PC Linux中的rz/sz； (2)嵌入式Linux中lrzsz； |
||||
注释：
1.常见的Ymodem的实际是Ymodem-1K
虽然严格意义上说，Ymodem，数据表示128字节，但是很多具体Ymodem的实现，实际上是把Ymodem认为是1KB的数据包，即这类Ymodem的实现，虽然也叫Ymodem，但是实际上是Ymodem-1K，即：
常见的Ymodem == Ymodem-1K
例子：
（1）Windows XP自带的超级终端（Hyper Terminal）中的Ymodem，就是默认1KB的数据包大小。
（2）而SecureCRT中的Ymodem默认是数据包是128字节，可以设置为128B或1KB。
2. lrzsz是嵌入式中常用的通过串口传输文件的工具，是PC版Linux中的rz/sz的精简版。
【引用】
1. XMODEM
http://en.wikipedia.org/wiki/XMODEM
2. Ymodem
http://en.wikipedia.org/wiki/YMODEM
3. Zmodem
http://en.wikipedia.org/wiki/ZMODEM
4. Kermit
http://en.wikipedia.org/wiki/Kermit_(protocol)
5. rz(1) – Linux man page
6. lrzsz: free x/y/zmodem implementation