xmodem协议源码.docx
《xmodem协议源码.docx》由会员分享，可在线阅读，更多相关《xmodem协议源码.docx（6页珍藏版）》请在冰豆网上搜索。
xmodem协议源码
竭诚为您提供优质文档/双击可除
xmodem协议源码
篇一：
ymodem协议例子
一、ymodem协议学习的目的
1、ymodem协议的应用
打开超级终端，在传送主菜单里，有接收文件和发送文件的子菜单。
也就是超级终端可以与连接的对象之间相互传送文件。
打开发送文件选项，可知，只需要选择“文件名”和“协议”两个选项，就可以进行文件的传送了。
协议的类型有7中，xmodem及改进的1k-xmodem，ymodem和ymodem-g，zmodem及其改进协议，以及kermit，我这次主要学习嵌入式系统中用得较多的ymodem协议。
2、学习的目标
（1）传送文件的实现
添加一个命令，fsend，这个命令接受一个参数，就是文件的最终存放目录。
当开发板接收到这个命令后，做好接收文件的准备。
与超级终端进行协商后，将收到的文件写入指定位置。
（2）接收文件的实现
添加一个命令frecv，这个命令接受一个参数，就是超级终端所要索取的文件。
当开发板接收到这个命令后，就等待终端发送索取文件的协商要求。
二、ymodem协议分析
1、明确概念
一步一步来，先把概念搞清楚。
ymodem协议是一种发送并等待的协议。
即发送方发送一个数据包以后，都要等待接收方的确认。
如果是ack信号，则可以发送新的包。
如果是nak信号，则重发或者错误退出。
２、文件传输过程
文件传输过程的开启：
（1）开启是由接收方开启传输，它发一个大写字母c开启传输。
然后进入等待（soh）状态，如果没有回应，就会超时退出。
（2）发送方开始时处于等待过程中，等待c。
收到c以后，发送（soh）数据包开始信号，发送序号（00），补码（FF），“文件名”，“空格”“文件大小”“除去序号外，补满128字节”，cRc校验两个字节。
进入等待（ack）状态。
（3）接收方收到以后，cRc校验满足，则发送ack。
发送方接收到ack，又进入等待“文件传输开启”信号，即重新进入等待“c”的状态。
（4）前面接收方只是收到了一个文件名，限制正式开启文件传输，ymodem支持128字节和1024字节一个数据包。
128字节以（ＳＯＨ）开始，１０２４字节以（ＳＴＸ）开始。
接收方又发出一个“Ｃ”信号，开始准备接收文件。
进入等待“ＳＯＨ”或者“ＳＴＸ”状态。
（５）发送接收到“Ｃ”以后，发送数据包，（ＳＯＨ）（０１序号）（ＦＥ补码）（１２８位数据）（ＣＲＣ校验），等待接收方“ＡＣＫ”。
（６）文件发送完以后，发送方发出一个“ＥＯＴ”信号，接收方也以“ＡＣＫ”回应。
然后接收方会再次发出“Ｃ”开启另一次传输，若接着发送方会发出一个“全０数据包”，接收方“ＡＣＫ”以后，本次通信正式结束。
（７）当然Ｙｍｏｄｅｍ相对于Ｘｍｏｄｅｍ改进的地方就在于传输再次开启以后，又可以发送另外一个文件，即一次传输允许发送多个文件，但这个特性我就不准备实现了。
//帧格式
//128字节数据帧
//1024字节数据帧
应答方式
senderReceiver
40->
........->//filenameandlengthetc
.......->//data
........->
............................................................
->//tarsmitionover
//nextfile
....->
//取消传输
//至少2个
实例：
（1）00400040ff0a0b0c0d937bff
（2）004000b0FF43e780FF//c
（3）00400040ff0100fe01444b515632302d53544d33322e62696e003239303532000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001b0593adff//filenameandlengthetc
（4）004000b0ff064e95ff//ack
//（5）004000b0ff434e95ff//c
（6）00400040ff0101Fe00000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0fcfeb3205ff//data
（7）004000b0ff064e95ff//ack
（8）00400040ff0102fd000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0fcfeb1fafff//data
（9）004000b0ff064e95ff//ack
（10）00400040ff0103fc000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0fcfeb04c9ff//data
（11）004000b0ff064e95ff//ack
（12）00400040ff0104fb000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0fcfeb54f3ff//data
（13）004000b0ff064e95ff//ack
（14）00400040ff0105fa000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405
060708090a0b0c0d0e0fcFeb4f95ff//data
（15）004000b0ff064e95ff//ack
（16）00400040ff0106f9000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0fcFeb623fff//data
（17）004000b0ff064e95ff//ack
（18）00400040ff045cb6ff//eot
（19）004000b0ff064e95ff//ack
（20）004000b0ff434e95ff//c
（21）00400040ff0100Fe01000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001363ff//end
发送端中止发送
00400040ff18b16cff
手动取消
00400040ff61f782ff//a
00400040ff41f5a3ff//a
（20xx/5/24）版本2：
修改：
应答方式
senderReceiver
40->
........->//filenameandlengthetc
.......->//data
........->
............................................................
->//tarsmitionover
//nextfile
....->
篇二：
xmoedm必看
xmoedm必看
1．xmodem协议是什么？
xmodem协议是一种串口通信中广泛用到的异步文件传输协议。
分为标准xmodem和1k-xmodem两种，前者以128字节块的形式传输数据，后者字节块为1k即1024字节，并且每个块都使用一个校验和过程来进行错误检测。
在校验过程中如果接收方关于一个块的校验和与它在发送方的校验和相同时，接收方就向发送方发送一个确认字节（ack）。
由于xmodem需要对每个块都进行认可，这将导致性能有所下降，特别是延时比较长的场合，这种协议显得效率更低。
除了xmodem，还有ymodem，zmodem协议。
他们的协议内容和xmodem类似，不同的是ymodem允许批处理文件传输，效率更高；zmodem则是改进的了xmodem，它只需要对损坏的块进行重发，其它正确的块不需要发送确认字节。
减少了通信量。
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字符会怎么处理？
其实如果传送的是文本文件，那么接收方对于接收的内容是很容易识别的，因为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就赶紧发送数据包响应。
11．xmodem协议代码
看了以上说明，再参考代码，应该很容易会理解代码编写者的思路。
篇三：
lrzsz串口工具移植到aRmlinux教程
lrzsz是一个unix通信包，提供xmodem、ymodem和zmodem文件传输协议。
lrzsz以前是omen科技的主打软件，现在已经免费，并且遵循gnu开源协议。
lrzsz适合这样一种开发环境，一块板子，除了串口，没有任何外部出入输出设备，没有sd卡，没有网线，这个时候如果想跟这块板子传输交互文件，就需要用到串口传输了。
根据modem所采用的文件传输协议：
xmodem、ymodem、zmodem将其分类
xmodem：
简单通用，传输信息单位是“包=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/
升级会员 