xmodem协议源码.docx
《xmodem协议源码.docx》由会员分享，可在线阅读，更多相关《xmodem协议源码.docx（12页珍藏版）》请在冰豆网上搜索。
xmodem协议源码
编号：
_______________
本资料为word版本，可以直接编辑和打印，感谢您的下载
xmodem协议源码
甲方：
___________________
乙方：
___________________
日期：
___________________
说明：
本合同资料适用于约定双方经过谈判、协商而共同承认、共同遵守的责任与义务，同时阐述确定的时间内达成约定的承诺结果。
文档可直接下载或修改，使用时请详细阅读内容。
xmodertfr议源码
篇一：
ymodem协议例子
一、ymodem协议学习的目的
1、ymodem协议的应用
打开超级终端，在传送主菜单里，有接收文件和发送文
件的子菜单。
也就是超级终端可以与连接的对象之间相互传送文件。
打开发送文件选项，可知，只需要选择“文件名”和“协议”两个选项，就可以进行文件的传送了。
协议的类型有7中，xmodem及改进的1k-xmodem,ymodem和ymodem-g,zmodem^其改进协议，以及kermit,我这次主要学习嵌入式系统中用得较多的ymodem协议。
2、学习的目标
（1）传送文件的实现
添加一个命令，fsend,这个命令接受一个参数，就是
文件的最终存放目录。
当开发板接收到这个命令后，做好接收文件的准备。
与超级终端进行协商后，将收到的文件写入指定位置。
（2）接收文件的实现
添加一个命令frecv,这个命令接受一个参数，就是超级终端所要索取的文件。
当开发板接收到这个命令后，就等待终端发送索取文件的协商要求。
二、ymodemW、议分析
1、明确概念
一步一步来，先把概念搞清楚。
ymodem协议是一种发送并等待的协议。
即发送方发送一个数据包以后，都要等待接收方的确认。
如果是ack信号，
则可以发送新的包。
如果是nak信号，则重发或者错误退出。
2、文件传输过程
文件传输过程的开启：
（1）开启是由接收方开启传输，它发一个大写字母c开启传输。
然后进入等待（soh）状态，如果没有回应，就会超时退出。
（2）发送方开始时处于等待过程中，等待c。
收到c以
后，发送（soh）数据包开始信号，发送序号（00）,补码（FF）,
“文件名”，“空格”“文件大小”“除去序号外，补满128字节”，cRc校验两个字节。
进入等待（ack）状态。
（3）接收方收到以后，cRc校验满足，则发送ack。
发送方接收到ack,乂进入等待“文件传输开启”信号，即重新进入等待“c”的状态。
（4）前面接收方只是收到了一个文件名，限制正式开
启文件传输，ymoden^持128字节和1024字节一个数据包。
128字节以（SOH）开始，1024字节以（STX）开始。
接收方乂发出一个“C”信号，开始准备接收文件。
进
入等待“SOH”或者“STX”状态。
（5）发送接收到“C”以后，发送数据包，（SOH）
（01序号）（FE补码）（128位数据）（CRC校验），
等待接收方“ACK”。
（6）文件发送完以后，发送方发出一个“EOT”信
号，接收方也以“ACK”回应。
然后接收方会再次发出“C”开启另一次传输，若接着
发送方会发出一个“全。
数据包”，接收方“ACK”以后，本次通信正式结束。
（7）当然Ymodem相对于Xmodem改进的地
方就在于传输再次开启以后，乂可以发送另外一个文件，即
一次传输允许发送多个文件，但这个特性我就不准备实现了。
//帧格式
//128字节数据帧
//1024字节数据帧
应答方式
senderReceiver
->//filenameandlengthetc
->//data
->
->//tarsmitionover
//nextfile
....->
//取消传输
//至少2个
实例：
⑴00400040ff0a0b0c0d937bff
（2）004000b0FF43e780FF//c
（3）
00400040ff0100fe01444b515632302d53544d33322e62696e0
032393035320000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000001b0593adff//filenameandlengthetc
⑷004000b0ff064e95ff//ack
//（5）004000b0ff434e95ff//c
（6）00400040ff0101Fe00000102030405060708090a0b0c0d0e
0f000102030405060708090a0b0c0d0e0f00010203040506070
8090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f0001
02030405060708090a0b0c0d0e0f000102030405060708090a0
b0c0d0e0f000102030405060708090a0b0c0d0e0f0001020304
05060708090a0b0c0d0e0fcfeb3205ff//data
⑺004000b0ff064e95ff//ack
（8）00400040ff0102fd000102030405060708090a0b0c0d0e0f
000102030405060708090a0b0c0d0e0f0001020304050607080
90a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102
030405060708090a0b0c0d0e0f000102030405060708090a0b0
c0d0e0f000102030405060708090a0b0c0d0e0f000102030405
060708090a0b0c0d0e0fcfeb1fafff//data
（9）004000b0ff064e95ff//ack
（10）00400040ff0103fc000102030405060708090a0b0c0d0e0
090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f00010
2030405060708090a0b0c0d0e0f000102030405060708090a0b
0c0d0e0f000102030405060708090a0b0c0d0e0f00010203040
5060708090a0b0c0d0e0fcfeb04c9ff//data
（11）004000b0ff064e95ff//ack
（12）00400040ff0104fb000102030405060708090a0b0c0d0e0
f000102030405060708090a0b0c0d0e0f000102030405060708
090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f00010
2030405060708090a0b0c0d0e0f000102030405060708090a0b
0c0d0e0f000102030405060708090a0b0c0d0e0f00010203040
5060708090a0b0c0d0e0fcfeb54f3ff//data
（13）004000b0ff064e95ff//ack
（14）00400040ff0105fa000102030405060708090a0b0c0d0e0
f000102030405060708090a0b0c0d0e0f000102030405060708
090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f00010
2030405060708090a0b0c0d0e0f000102030405060708090a0b
0c0d0e0f000102030405060708090a0b0c0d0e0f00010203040
（16）00400040ff0106f9000102030405060708090a0b0c0d0e0
f000102030405060708090a0b0c0d0e0f000102030405060708
090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f00010
2030405060708090a0b0c0d0e0f000102030405060708090a0b
0c0d0e0f000102030405060708090a0b0c0d0e0f00010203040
5060708090a0b0c0d0e0fcFeb623fff//data
（17）004000b0ff064e95ff//ack
（18）00400040ff045cb6ff//eot
（19）004000b0ff064e95ff//ack
（20）004000b0ff434e95ff//c
（21）e010*********
000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000
0000000000000000000000000001363ff//end
发送端中止发送
00400040ff18b16cff
手动取消
00400040ff61f782ff//a
00400040ff41f5a3ff//a
（20xx/5/24）版本2:
修改：
应答方式
senderReceiver
40->
->//filenameandlengthetc
->//data
->
->//tarsmitionover
//nextfile
....->
篇二：
xmoedm^、看
xmoedmt^、看
1.xmodem协议是什么？
xmodem协议是一种串口通信中广泛用到的异步文件传
输协议。
分为标准xmodem#口1k-xmodem两种，前者以128
字节块的形式传输数据，后者字节块为1k即1024字节，并
且每个块都使用一个校验和过程来进行错误检测。
在校验过
程中如果接收方关于一个块的校验和与它在发送方的校验
和相同时，接收方就向发送方发送一个确认字节（ack）。
由
于xmodemft要对每个块都进行认可，这将导致性能有所下降，特别是延时比较长的场合，这种协议显得效率更低。
除
了xmodem还有ymodemzmodemW、议。
他们的协议内容和xmodem类似，不同的是ymodem允许批处理文件传输，效率更高；zmodem则是改进的了xmodem它只需要对损坏的块进行重发，其它正确的块不需要发送确认字节。
减少了通信
Mo
2.xmodem协议相关控制字符
soh0x01
stx0x02
eot0x04
ack0x06
nak0x15
can0x18
ctRlz0x1a
3.标准xmodem协议（每个数据包含有128字节数据）帧格式
||||||
|soh|信息包序号|信息包序号的补码|数据区段|校验
||||||
4.1k-xmodem（每个数据包含有1024字节数据）帧格
||||||
|stx|信息包序号|信息包序号的补码|数据区段|校验
|||||
|
5.数据包说明
对于标准xmodem协议来说，如果传送的文件不是128
的整数倍，那么最后一个数据包的有效内容肯定小于帧长，
不足的部分需要用ctRl-z（0x1a）来填充。
这里可能有人会问，
如果我传送的是bootloader工程生成的.bin文件，mcu收
到后遇到0x1a字符会怎么处理？
其实如果传送的是文本文
件，那么接收方对于接收的内容是很容易识另U的，因为
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.校验和的说明
xmoden#议支持2种校验和，它们是累加和与cRc校验。
当接收方一开始启动传输时发送的是nak,表示它希望
以累加和方式校验。
当接收方一开始启动传输时发送的是字符“c”，表示它希望以cRc方式校验。
可能有人会问，接收方想怎么校验发送方都得配合吗，难道发送方必须都支持累加和校验和cRc校验？
事实上xmodem要求支持cRc的就必须同时支持累加和，如果发送方只支持累加和，而接收方用字符“c”来启动，那么发送方只要不管它，当接收方继续发送“c”，三次后都没收到应答，就自动会改为发送nak,
因为它已经明白发送方可能不支持cRc校验，现在接收方改
为累加和校验和发送方通讯。
发送方收到nak就赶紧发送数
据包响应。
11.xmodem协议代码
看了以上说明，再参考代码，应该很容易会理解代码编写者的思路。
篇三：
lrzsz串口工具移植到aRmlinux教程lrzsz是一个unix通信包，提供xmodemymodemfi]
zmode成件传输协议。
lrzsz以前是omen科技的主打软件,
现在已经免费，并且遵循gnu开源协议。
lrzsz适合这样一
种开发环境，一块板子，除了串口，没有任何外部出入输出设备，没有sd卡，没有网线，这个时候如果想跟这块板子传输交互文件，就需要用到串口传输了。
根据modemW采用
的文件传输协议：
xmodemymodemzmodemW其分类
xmodern简单通用，传输信息单位是“包=128b”，传输速度慢，适合电话线路质虽差的情况下用。
ymodem由xmodem寅变来，效率可靠性高“包=128*8b”，一次传输可发送或接受几个文件。
zmodem与上两种不同，已连续的数据流发送数据，效率更高。
在ubuntu主机中可以直接使用rz或者sz命令与
securecRt交互文件，如果想在开发板中，上传下载文件的话，需要移植完整版的lrzsz到开发板，使用其完整功能。
移植步骤：
1下载源码包
首先下载最新版的lrzsz,地址：
https:
//ohse.de/uwe/software/lrzsz.html。
下面以
0.12.20版本为例，下载源码包为：
lrzsz-0.12.20.tar.gz。
2复制并解压源码包
3配置
4编译安装
make完成之后，会在当前目录src/下生成lrz和lsz
两个文件。
5
复制到目标板并执行
通过网络、u盘、sd卡等方式，将生成的lrz和lsz复制到目标板的/usr/sbin目录，并在目标版上添加可执行权限：
6配置串口
在使用之前，需要设置串口：
7测试
在目标版上，执行lrz命令将文件从pc机传送到目标
版上，执行lsz命令将文件从目标版传到pc机上：
参考地址：
/seven_7_one/blog/static/16260641220xx1113111645638
/
升级会员 