Xmodem协议详解以及源代码剖析
XMODEM协议
XMODEM协议XMODEM协议是一种用于串行通信的错误检测和纠正协议,能够保证可靠地传输文件。
XMODEM协议基于逐块传输的原理,将大文件划分为若干个块,然后逐个传输和校验块。
XMODEM协议的工作流程如下:1. 发送方准备传输的文件,将文件分成多个块(通常为128字节)。
2. 发送方发送一个控制字符C,作为开始传输的信号。
3. 接收方收到控制字符C后,发送一个ACK应答信号,表示准备好接收。
4. 发送方开始发送文件的第一个块,包括块号、数据、校验和等信息。
5. 接收方接收到数据后进行校验,如果数据正确,则发送一个ACK应答信号。
6. 发送方收到ACK应答信号后,开始发送下一个块。
7. 接收方连续收到块,并进行校验,直到收到发送方发送的最后一个块。
8. 接收方发送一个结束字符EOT,表示传输结束。
9. 发送方收到EOT后,发送一个ACK应答信号。
10. 接收方收到ACK应答信号后,传输完成。
XMODEM协议使用校验和来验证接收到的数据的完整性。
发送方在发送每个块之前,计算数据的校验和,并将校验和附加到块的末尾。
接收方收到块后,将接收到的数据和附加的校验和进行计算,与发送方计算的校验和进行比对。
如果两个校验和相等,说明数据没有错误。
如果不相等,接收方会发送一个NAK应答信号,表示接收到的数据有错误,要求发送方重新发送。
XMODEM协议的优势在于其简洁、可靠和易于实现。
然而,由于基于逐块传输的原理,传输效率较低。
每传输一个块需要发送方等待接收方的ACK应答信号,这样会浪费许多时间。
为了提高传输效率,后来出现了改进的XMODEM协议,如XMODEM-CRC和XMODEM-1K。
XMODEM-CRC使用更强大的循环冗余校验(CRC)算法替代了校验和,提高了错误检测的能力。
XMODEM-1K将块的大小增加到1024字节,减少了传输块的数量,从而提高了传输效率。
总结来说,XMODEM协议是一种简单而可靠的传输协议,适用于低带宽、不太强调传输速度的环境下。
xmodem通信协议
xmodem通信协议
Xmodem是一种简单且可靠的串行通信协议,用于在计算机之间传输文件。
它的工作原理是将文件划分为若干个固定长度的数据块,并通过串行线路逐块传输。
每个数据块都包含了一个数据包编号、数据内容和校验和。
传输过程中,发送方将一个数据块发送给接收方,接收方收到后进行校验和验证。
如果数据块包含错误,则接收方会发送一个确认帧给发送方,要求重新发送该数据块。
如果数据块无误,则接收方发送一个确认帧给发送方,表示接收成功。
发送方收到确认帧后,再发送下一个数据块。
传输完成后,发送方发送一个传输结束帧,表示文件传输完毕。
Xmodem协议主要有三个版本:
1. Xmodem: 最早的版本,使用起始位和奇偶校验位来检查数
据的完整性。
每个数据块包含数据、校验和和一个确认帧。
2. Xmodem-CRC: 在Xmodem的基础上引入了循环冗余校验(CRC),提高了错误检测的准确性。
3. Xmodem-1K: 改进版本,每个数据块的长度增加到1024字节,提高了传输速度。
Xmodem通信协议简单易用,广泛应用于早期的串口通信设备和计算机之间的文件传输。
然而,由于其低效的传输速度和简单的错误处理机制,现在已经被更先进的协议所替代,如Ymodem、Zmodem和Kermit等。
XMODEM协议
XMODEM协议XMODEM协议是一种简单而古老的串行通信协议,它用于在计算机之间进行文件传输。
XMODEM协议最初由Ward Christensen和Keith Petersen于1977年开发,它是第一个广泛使用的文件传输协议之一。
尽管XMODEM协议已经被更先进的协议所取代,但它的基本原理仍然对我们理解现代通信协议有所帮助。
XMODEM协议的工作原理非常简单。
发送方将文件分成128字节的数据块,每个数据块都会被编号,接收方在接收到数据块后会发送一个确认信号,如果发送方没有收到确认信号,它会重新发送数据块。
这种简单的确认和重传机制确保了数据的可靠传输。
XMODEM协议的简单性使得它在早期个人计算机上得到了广泛的应用。
然而,它也存在一些缺点。
首先,XMODEM协议的速度相对较慢,因为它在发送每个数据块后都需要等待确认信号。
其次,XMODEM协议没有进行错误检测和纠正,因此在传输过程中很容易出现数据损坏的情况。
为了解决XMODEM协议的缺点,后来出现了一些改进版本,比如YMODEM和ZMODEM。
这些改进版本在速度和可靠性上都有所提高,但它们仍然保留了XMODEM协议的基本原理。
这些改进版本在一定程度上延续了XMODEM协议的影响,但随着现代通信技术的发展,它们也逐渐被更先进的协议所取代。
尽管XMODEM协议已经不再是主流的文件传输协议,但它作为通信协议的基础原理仍然具有重要意义。
通过学习XMODEM协议,我们可以更好地理解通信协议的工作原理,从而更好地理解和应用现代通信技术。
总的来说,XMODEM协议作为早期的文件传输协议,虽然已经被更先进的协议所取代,但它的简单原理和基本思想仍然对我们有所启发。
通过了解XMODEM协议,我们可以更好地理解通信协议的发展历程,从而更好地应用现代通信技术。
因此,即使XMODEM协议已经不再被广泛使用,但它的影响仍然存在,它对我们理解通信协议的发展和应用具有重要意义。
Xmodem、Ymodem协议总结
Xmodem、Ymodem协议总结写在前⾯: 本⽂包含如下内容: ⼀、 ⼆、 三、 四、 (4-1) (4-2) 五、 (5-1) (5-2) (5-3) (5-4)⼀、⽂件传输简介 ⽂件传输是数据交换的主要形式。
在进⾏⽂件传输时,为使⽂件能被正确识别和传送,我们需要在两台计算机之间建⽴统⼀的传输协议。
这个协议包括了⽂件的识别、传送的起⽌时间、错误的判断与纠正等内容。
Xmodem、Ymodem和Zmodem协议是最常⽤的三种通信协议。
⼆、传输协议 在SecureCRT下的传输协议有ASCII、Xmodem、Ymodem、Zmodem等。
如下图所⽰,在开发中,可以使⽤SecureCRT软件进⾏⽂件传输。
三、协议特点 (1)Xmodem协议是最早的,传输128字节信息块。
(2)Ymodem是Xmodem的改进版协议,具有传输快速稳定的优点。
它可以⼀次传输1024字节的信息块,同时还⽀持传输多个⽂件。
平常所说的Ymodem协议是指的Ymodem-1K,除此还有Ymodem-g(没有CRC校验,不常⽤)。
YModem-1K⽤1024字节信息块传输取代标准的128字节传输,数据的发送会使⽤CRC校验,保证数据传输的正确性。
它每传输⼀个信息块数据时,就会等待接收端回应ACK信号,接收到回应后,才会继续传输下⼀个信息块,保证数据已经全部接收。
四、XModem协议解析 Xmodem协议传输有接收程序和发送程序完成,先由接收程序发送协商字符,协商校验⽅式,协商通过之后发送程序就开始发送数据包,接收程序接收到完整的⼀个数据包之后按照协商的⽅式对数据包进⾏校验。
校验通过之后发送确认字符,然后发送程序继续发送下⼀包;如果校验失败,则发送否认字符,发送程序重传此数据包。
定义: SOH 01H(modem数据头) EOT 04H(发送结束) ACK 06H(应答) NAK 15H(⾮应答) CAN 18H(取消发送) Xmodem数据包,包含⼀个标题开始字符,⼀个单字节包序号,⼀个包序号的补码,128字节数据和⼀个双字节的CRC校验。
xmodem_串口_传输_协议
Xmodem协议)V1.1 - Dec 8, 2005中文版19, Innovation First Road • Science Park • Hsin-Chu • Taiwan 300 • R.O.C.Tel: 886-3-578-6005 Fax: 886-3-578-4418 E-mail: mcu@版权声明凌阳科技股份有限公司保留对此文件修改之权利且不另行通知。
凌阳科技股份有限公司所提供之信息相信为正确且可靠之信息,但并不保证本文件中绝无错误。
请于向凌阳科技股份有限公司提出订单前,自行确定所使用之相关技术文件及规格为最新之版本。
若因贵公司使用本公司之文件或产品,而涉及第三人之专利或著作权等智能财产权之应用及配合时,则应由贵公司负责取得同意及授权,本公司仅单纯贩售产品,上述关于同意及授权,非属本公司应为保证之责任。
又未经凌阳科技股份有限公司之正式书面许可,本公司之所有产品不得使用于医疗器材,维持生命系统及飞航等相关设备。
页1系统概要 (5)1.1系统说明 (5)1.2Xmodem简介 (5)1.3Xmodem协议 (5)1.3.1相关说明 (5)1.3.2协议简介 (5)1.3.3校验和信息包 (6)1.3.4CRC校验信息包 (7)1.4系统组成 (9)2软件说明 (10)2.1软件说明 (10)2.2档案构成 (10)2.3子程序说明 (10)3程序范例 (13)3.1DEMO程序 (13)3.2文件传输 (15)4MCU使用资源 (19)4.1MCU硬件使用资源说明 (19)5参考文献 (26)版本日期编写及修订者编写及修订说明1.0 2004/01/13初版1.1 2005/12/08错误校正Sender Flow ReceiverNAK <---OKSOH 0x05 0xFA Data[0-127]Chksum---> Packet<---ACKOKEOT --->PacketACK get garbaged <--- ACKOKEOT --->PacketACKFinished <---1.3.4 CRC校验信息包1、CRC校验信息包<SOH><blk #><255-blk #><--128 data bytes--><CRC hi><CRC lo>其中:<SOH> = 01 hex信息包序号,从 01开始以发送一包将加1,加到FF hex将循环。
xmodem协议介绍及VxWorks下的应用
/*最大重试次数*/
#define MAX_RETRY
10
/*最大包序列宏定义*/
#define MAX_SEQNO
255Biblioteka /*等待包头的时间 10S*/
#define WAIT_SOH_TIME 10
/*发送 C 字符的次数*/
#define SEND_C_TIMES
3
/*校验和方式*/
#define CHECK_CRC
发送端发现最后一个数据包不足 128 字节时,填充 CTRL+Z (0x1a)。发送端发送完毕后
发送 EOT 结束文件传输,或者发现接收端一直不响应或对同一数据包响应 NAK 超过规定次
数(一般 10 次)时发送 CAN 取消传输。接收端接收到 EOT 或 CAN 时结束传输流程。
下面以校验和 checksum 的数据包传输流程说明 xmodem 协议的原理。接收端启动连接后,
xmodem 协议介绍及 VxWorks 下的应用
最初,XMODEM 协议是一种基于调制解调器直接拨号通讯的文件传输协议,用来支持两台 计 算 机 之 间 的 文 件 传 输 。由于其简单可靠、实现方便的特性,现在已经广泛应用于嵌入式设备 中。实现 xmodem 只需要微处理器带有串口控制器就行了,一般的 8 位单片机也能进行文件 传输。
/*CRC 计算*/ U16 CRC16_CCITT (U8 *ptr, S32 count) {
U16 usCrc; U8 * pTmp; U16 i;
usCrc = 0; pTmp = ptr; while (--count >= 0) {
usCrc = usCrc ^ ((U16)( *pTmp++ ) << 8); for ( i = 0; i < 8; ++i) {
研究Xmodem协议必看的11个问题
研究Xmodem协议必看的11个问题Xmodem协议作为串口数据传输主要的方式之一,恐怕只有做过bootloader的才有机会接触一下,网上有关该协议的内容要么是英语要么讲解不详细。
笔者以前写bootloader时研究过1k-Xmodem,参考了不少相关资料。
这里和大家交流一下我对Xmodem的理解,多多指教!1.Xmodem协议是什么?XMODEM协议是一种串口通信中广泛用到的异步文件传输协议。
分为标准Xmodem 和1k-Xmodem两种,前者以128字节块的形式传输数据,后者字节块为1k即1024字节,并且每个块都使用一个校验和过程来进行错误检测。
在校验过程中如果接收方关于一个块的校验和与它在发送方的校验和相同时,接收方就向发送方发送一个确认字节(ACK)。
由于Xmodem需要对每个块都进行认可,这将导致性能有所下降,特别是延时比较长的场合,这种协议显得效率更低。
除了Xmodem,还有Ymodem,Zmodem协议。
他们的协议内容和Xmodem类似,不同的是Ymodem允许批处理文件传输,效率更高;Zmodem则是改进的了Xmodem,它只需要对损坏的块进行重发,其它正确的块不需要发送确认字节。
减少了通信量。
2.Xmodem协议相关控制字符SOH 0x01STX 0x02EOT 0x04ACK 0x06NAK 0x15CAN 0x18CTRLZ 0x1A3.标准Xmodem协议(每个数据包含有128字节数据)帧格式_______________________________________________________________| | | | | || SOH | 信息包序号 | 信息包序号的补码 | 数据区段 | 校验和 ||_____|____________|___________________|__________|____________|4.1k-Xmodem(每个数据包含有1024字节数据)帧格式_______________________________________________________________| | | | | || STX | 信息包序号 | 信息包序号的补码 | 数据区段 | 校验和 ||_____|____________|___________________|__________|____________|5.数据包说明对于标准Xmodem协议来说,如果传送的文件不是128的整数倍,那么最后一个数据包的有效内容肯定小于帧长,不足的部分需要用CTRL-Z(0x1A)来填充。
Xmodem协议详解以及源代码
研究Xmodem协议必看的11个问题原文地址:/s/blog_4db10c6c0100av57.html~type=v5 _one&label=rela_prevarticleXmodem协议作为串口数据传输主要的方式之一,恐怕只有做过bootloader的才有机会接触一下,网上有关该协议的内容要么是英语要么讲解不详细。
笔者以前写bootloader时研究过1k-Xmodem,参考了不少相关资料。
这里和大家交流一下我对Xmodem的理解,多多指教!1.Xmodem协议是什么?XMODEM协议是一种串口通信中广泛用到的异步文件传输协议。
分为标准X modem和1k-Xmodem两种,前者以128字节块的形式传输数据,后者字节块为1 k即1024字节,并且每个块都使用一个校验和过程来进行错误检测。
在校验过程中如果接收方关于一个块的校验和与它在发送方的校验和相同时,接收方就向发送方发送一个确认字节 (ACK)。
由于Xmodem需要对每个块都进行认可,这将导致性能有所下降,特别是延时比较长的场合,这种协议显得效率更低。
除了Xmodem,还有Ymodem,Zmodem协议。
他们的协议内容和Xmodem类似,不同的是Ymodem允许批处理文件传输,效率更高;Zmodem则是改进的了X modem,它只需要对损坏的块进行重发,其它正确的块不需要发送确认字节。
减少了通信量。
2.Xmodem协议相关控制字符SOH 0x01STX 0x02EOT 0x04ACK 0x06NAK 0x15CAN 0x18CTRLZ 0x1A3.标准Xmodem协议(每个数据包含有128字节数据)帧格式_______________________________________________________________ | | || | || SOH | 信息包序号| 信息包序号的补码 | 数据区段| 校验和||_____|____________|___________________|__________|____________| 4.1k-Xmodem(每个数据包含有1024字节数据)帧格式_______________________________________________________________ | | || | || STX | 信息包序号| 信息包序号的补码 | 数据区段| 校验和||_____|____________|___________________|__________|____________| 5.数据包说明对于标准Xmodem协议来说,如果传送的文件不是128的整数倍,那么最后一个数据包的有效内容肯定小于帧长,不足的部分需要用CTRL- Z(0x1A)来填充。
Ymodem协议要点
Ymodem协议要点1.写在前面在进行文件传输时,为使文件能被正确识别和传送,需要在两台计算机之间建立统一的传输协议,协议需要包括了文件的识别、传送的起止时间、错误的判断与纠正等内容。
常用的文件传输协议有:【1】ASCII:传输速度快最快,但只能传送文本文件。
【2】Xmodem:协议古老悠久,传输速度较慢,采用了CRC校验算法,传输的准确率可高达99.6%;每次传输信息块为128字节。
【3】Ymodem:Ymodem是Xmodem的改进版,每次传输信息块最大1024字节,速度比Xmodem快;同时还支持传输多个文件。
【4】Zmodem:Zmodem采用了串流式(streaming)传输方式,传输速度较快,而且还具有自动改变区段大小和断点续传、快速错误侦测等功能。
Zmodem目前最流行的文件传输协议。
Ymodem协议用于计算机间传输文件,同样适用于嵌入式领域,如MCU升级固件时,可以使用Ymodem协议传输固件文件,传输总线不限于USB、UART、CAN等。
2.Ymodem 帧格式Ymodem 有两种帧格式,主要区别是信息块长度不一样。
名称帧头包号包号反码信息块校验简写 SOH/STX PN XPN DATA CRC字节数 1 1 1 1024/128 22.1 帧头帧头表示两种数据帧长度,主要是信息块长度不同。
帧头 SOH(0x01) STX(0x02)信息块长度 128字节 1024字节2.2 包序号数据包序号只有1字节,因此计算范围是0~255;对于数据包大于255的,序号归零重复计算。
2.3 帧长度【1】以SOH(0x01)开始的数据包,信息块是128字节,该类型帧总长度为133字节。
【2】以STX(0x02)开始的数据包,信息块是1024字节,该类型帧总长度为1029字节。
2.4 校验Ymodem采用的是CRC16校验算法,校验值为2字节,传输时CRC高八位在前,低八位在后;CRC计算数据为信息块数据,不包含帧头、包号、包号反码。
嵌入式系统软件开发工具——串口XModem数据传输
XModem使用实例 7
第四步:进入PC超级终端软件的[文件/属性]菜单,在弹出的对话框单击<配置>按钮,进入 Console口配置对话框,将速率设置为115200bps。
XModem使用实例 8
第五步:配置终端的波特率设置完成后,做一次终端的断开和连接操作,波特率设置才能生效: 单击超级终端的<断开>按钮,即断开了超级终端和交换机的连接,单击<连接>按钮,则重新 建立超级终端和交换机的连接。
XModem使用实例 10
第七步:此时,从终端窗口选择[传送\发送文件],在弹出的对话框中单击<浏览>按钮,选择 需要下载的软件,并将下载使用的协议改为“Xmodem”。
XModem使用实例 11
第八步:选择完成后,单击<发送>按钮,系统弹出如下图所示的界面。
XModem使用实例 12
第九步:程序下载完成后,系统界面如下: Loading CCCCCCCC done!
XModem协议传输由接收程序和发送程序完成。先由接收程序发送协商字符,协商校验方式, 协商通过之后发送程序就开始发送数据包,接收程序接收到完整的一个数据包之后按照协商的 方式对数据包进行校验。校验通过之后发送确认字符,然后发送程序继续发送下一数据包;如 果校验失败,则发送否认字符,发送程序重传此数据包。
Enter your choice(0-3): 然后可以选择不同的协议来对BOOTROM进行加载。
XModem使用实例 5
第二步:在下载程序菜单中,键入3,选择采用XModem协议完成BOOTROM的加载,回车后, 系统进入下载速率设置菜单: select your download baudrate: 1.* 9600 2. 19200 3. 38400 4. 57600 5. 115200 0. Return Enter your choice (0-5):
XMODEM协议
XMODEM transfer protocol-----------------------------------------author: christensen2004-3-25 10:08noted: Job Nelson*/1。
帧格式__________________________________________________| | | | | || SOH | 信息包序号 | 信息包序号的补码 | 数据区段 | 算术校验和 ||_____|________ _|________________|________|__________|说明:SOH 帧的开头字节,代表信息包中的第一个字节信息包序号:对 256 取模所得到当前包号,第一个信息包的序号为 1而信息包序号范围 0~255信息包序号的补码:当前信息包号的补码数据区段:数据区段的长度固定为 128 字节,其内容没有任何限制,可以是文本数据或二进制数据算术校验和: 1字节的算术校验和,只对数据区段计算后对 256 取模而得2。
传输逻辑1> 收发双方拨号连通后,发送方等待接收方传来 NAK 信号。
当第一个 NAK 到达,发送方解释为开始发送第一个包2> 发送方一旦收到第一个 NAK ,启动了传输,发送方就将数据以每次 128 字节打包成帧格式传送,再等待接收方的确认信号3> 发送方收到接收方传来的 ACK 信号,解释为信息包被正确接收,并有发送下一个包的含义4> 发送方收到接收方传来的 NAK 信号,解释为请求重发同一数据包5> 发送方收到接收方传来的 CAN 信号,解释为请求无条件停止传输过程6> 发送方正常传输完全部数据,需要正常结束,发送 EOT 信号通知接收方。
接收方用 ACK 进行确认7> 接收方发送 CAN 无条件停止传输过程,发送方收到 CAN 后,不发送 EOT 确认8> 虽然信息包是以 SOH 来标志一个信息包的起始的,但在 SOH 位置上出现的EOT则表示数据传输结束,再也没有数据传过来9> 接收方首先应确认信息包序号的完整性,通过对信息包序号取补,然后和信息包序号的补码异或,结果为 0 表示正确,结果不为 0 则发送 NAK 请求重传10> 接收方确认信息包序号正确后,然后检查是否期望的序号。
XMODEM文件传输技术
XMODEM文件传输技术在水情报文传输中的应用文波(新疆水文水资源局信息中心 830000)摘要: 为了提高水情传输质量及速度,减轻工作人员劳动强度,结合实际情况本文提出了一种新的解决办法,引入了Xmod em点对点传输协议。
首先介绍了Xm odem协议族的基本原理,提出了应用Xm odem协议来解决水情报文传输所面临的问题。
然后给出了解决方案和利用V arianAsync32组件在Del phi5开发环境下具体实现的方法,并应用在了新疆水情传输上,实验运行了一年,正式使用了两年,结果非常理想,不光解决了以往水情报文上报慢错报多的问题,还大大减轻了人员的工作量。
关键词: Xmodem;水情报文;传输;组件引言近年来水文自动测报技术已经改变了我国由人工采集雨水情信息参数,再通过电报电话等方式传递的传统报汛手段,它利用遥测、通信、计算机等现代高科技实时完成降水量、水位等数据的采集、传输和加工处理,可在无人值守的情况下快速准确地掌握所需区域的水雨情等水文信息,传递至决策机构,进行洪水预报和优化调度,最大限度地减少洪涝灾害损失,提高水资源利用率,具有良好的社会效益和经济效益。
但是这只是解决了数据从测站到中心站的传输问题,而从地区分局到省中心局却还是使用传统的电报或电台话报,这样工作效率低下,速度慢,差错率高。
所以就急需寻找一个好的解决方案,能快速高效,费用低廉的解决从分局到省中心局报文传输的问题。
本文选出了三种常用的通讯方式,基于TCP/IP的SOCK ET传输,基于公网的电子邮件的传输,和点对点的基于Xmodem的文件传输协议。
通过在全新疆14个地区分局实验比较了它们的性能指标,最后证明了Xm odem文件传输协议是最经济,快速方便的。
基于Xmodem协议的IAP编程的研究(stm32)
报告人: 蔡志威
3013.12.11
报告内容
1. Xmodem协议简介
2. IAP编程原理
3. Boot与App程序设计
4. 实验步骤 5. 远程升级应用
2
1. Xmodem协议简介
串行通信的文件传输协议主要有:Xmodem、Ymodem、
17
5. 远程升级应用
ZNE100T 是一款市面上常见 的以太网转串口模块,可以实现 串口与以太网之间的透明传输。
/share/link?shareid=4
284569222&uk=1543663689
9
3. Boot与App程序设计
中断向量表的偏移量设置:(misc.c中) void NVIC_SetVectorTable(uint32_t NVIC_VectTab, uint32_t Offset) #ifdef VECT_TAB_SRAM SCB->VTOR = SRAM_BASE | VECT_TAB_OFFSET; #else SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; #endif 设计VECT_TAB_OFFSET=0x4000 预留16KB的
在倒计时10秒内,按H键进入帮助菜单:
1. CRC校验烧录APP代码; 2. SUM校验烧录APP代码; 3. 启动APP程序 ; 4. 擦除扇区 R. 重启BootLoader; S. 设置启动时间 B. 取消代码更新
15
10S串口没有接收到命令,则跳转到APP用户代码区。
16
4. 实验步骤
按1键,发送APP代码,烧录到8004000地址处。 按3键,在指定地址启动用户APP程序。
bootloaderxmodem协议
bootloaderxmodem协议甲方:_______________________乙方:_______________________地址:_______________________联系人:_______________________联系电话:_______________________签订日期:_______________________签订地址:_______________________第一条协议目的1.1 协议目的的定义① 本协议的目的在于明确甲乙双方在协议期间的权利与义务。
② 双方就Bootloader Xmodem协议的实施、开发和使用达成一致。
③ 乙方负责协议内容中涉及的技术支持和开发工作。
④ 甲方提供所需的硬件设施和相关资源支持。
1.2 协议的适用范围① 本协议适用于甲乙双方在Bootloader Xmodem协议中涉及到的所有技术实施、版本更新等方面的合作。
② 所有在协议期内发生的技术问题及解决方案,均应按照本协议执行。
③ 如有新的技术要求,双方应协商决定是否纳入协议内容。
④ 双方对于协议内容的修改、更新,应提前30天通知对方。
1.3 双方责任的划分① 甲方负责提供必要的硬件环境和开发平台。
② 乙方负责技术开发与相关的测试工作。
③ 双方应保持信息的及时共享,确保协议的顺利执行。
④ 双方应在项目实施期间按计划推进,确保进度符合预期。
第二条技术支持与开发2.1 乙方的技术支持责任① 乙方应提供Bootloader Xmodem协议相关的技术指导和开发支持。
② 乙方在开发过程中,应及时向甲方反馈进展情况,并根据甲方的需求调整开发计划。
③ 乙方应在规定的时间内完成开发任务,并提供相关的文档和说明。
④ 乙方应对甲方提供的设备和资料保密,不得用于协议外的其他用途。
2.2 技术开发进度与测试① 双方应共同确认开发进度,并根据进度安排进行阶段性验收。
② 乙方应按照双方商定的技术标准进行开发和调试。
Xmodem协议详解以及源代码剖析
研究 Xmodem 协议必看的 11个问题Xmodem 协议作为串口数据传输主要的方式之一,恐怕只有做过 bootloader 的才有机会接触一下, 网上有关该协议的内容要么是英语要么讲解不详细。
笔者以前写 bootloader 时研究过 1k-Xmodem ,参考了不少相关资料。
这里和大家交流一下我对 Xmodem 的理解,多多指教!1. Xmodem 协议是什么?XMODEM协议是一种串口通信中广泛用到的异步文件传输协议。
分为标准Xmodem 和 1k-Xmodem 两种,前者以 128字节块的形式传输数据,后者字节块为 1k 即 1024字节,并且每个块都使用一个校验和过程来进行错误检测。
在校验过程中如果接收方关于一个块的校验和与它在发送方的校验和相同时,接收方就向发送方发送一个确认字节 (ACK。
由于 Xmodem 需要对每个块都进行认可, 这将导致性能有所下降, 特别是延时比较长的场合, 这种协议显得效率更低。
除了 Xmodem ,还有 Ymodem , Zmodem 协议。
他们的协议内容和 Xmodem 类似,不同的是 Ymodem 允许批处理文件传输,效率更高; Zmodem 则是改进的了Xmodem ,它只需要对损坏的块进行重发,其它正确的块不需要发送确认字节。
减少了通信量。
2. Xmodem 协议相关控制字符SOH 0x01STX 0x02EOT 0x04ACK 0x06NAK 0x15CAN 0x18CTRLZ 0x1A3.标准 Xmodem 协议(每个数据包含有 128字节数据帧格式_______________________________________________________________| SOH | 信息包序号 | 信息包序号的补码 | 数据区段 | 校验和 ||_____|____________|___________________|__________|____________|4. 1k-Xmodem (每个数据包含有 1024字节数据帧格式_______________________________________________________________| STX | 信息包序号 | 信息包序号的补码 | 数据区段 | 校验和 ||_____|____________|___________________|__________|____________|5.数据包说明对于标准 Xmodem 协议来说,如果传送的文件不是 128的整数倍,那么最后一个数据包的有效内容肯定小于帧长,不足的部分需要用 CTRL- Z(0x1A来填充。
串口Xmodem协议的发送数据
串口Xmodem协议的发送数据程序/**********************************************************日期:2007-05-21编写:李猛功能:编程实现简化Xmodem协议,为实现标准的Xmodem协议做基础备注:此程序中430为发送方说明:1.程序开始时,会循环等待NAK的到来,只要收到的不是NAK,就会一直等待下去,直到收到了NAK,才开始数据的发送;2.上一轮如果发送的是一组数据,则收到CAN,程序就中止;收到ACK,就发送下一组数据;收到NAK,就发送上一组数据;如果收到的不是上面三种,程序就返回,直到出现三个中的某一个;3.上一轮如果发送的是EOT,收到CAN就中止;收到ACK,就结束程序;收到NAK,就再发送EOT;收到的是其他数据就返回,直到出现三个中的某一个。
**********************************************************/#include <msp430x14x.h>#define uchar unsigned char#define NAK 0x15 //Xmodem协议中的术语#define ACK 0x06#define CAN 0x18#define EOT 0x04#define SOH 0x01//要发送的数据,即430从此数组中取数据构成数据包,共22字节,分5次发送,最后一次补3个0x1A uchar FileSend[22] ={0xAA,0xA9,0xA8,0xA7,0xA6,0xA5,0xA4,0xA3,0xA2,0xA1,0xA0,0x9F,0x9E,0x9D,0x9C,0x 9B,0x9A,0x99,0x98,0x97,0x96,0x95};//数据包,长9字节,分别为SOH、包序号、序号补码、5字节数据、校验码uchar DataSend[9];uchar Seq = 0x01; //数据包序号,初值为1uchar cmpl; //数据包序号的补码uchar csum; //垂直累加和校验码,初值为0uchar rec_PC; //收到的PC的确认命令uchar k = 0; //指向FileSend的标号,从中取数据时使用,初值为0uchar j = 0; //指向DataSend的标号,发送数据时使用,初值为0uchar fin_flag = 0; //数据取完的标志,为1时表示FileSend中的数据已经取完uchar eot_flag = 0; //发送完成的标志,为1时表示430已经发送过了EOT标志void Init_CLK(); //函数声明void Init_Port();void Init_UART0();void main(void){WDTCTL = WDTPW + WDTHOLD; //关闭看门狗_DINT(); //关中断Init_CLK();Init_Port();Init_UART0(); //一系列的初始化_EINT(); //开中断while(1); //等待:接收中断,功能全在接收中断函数中完成//主程序只是循环等待}/******************时钟初始化函数******************/void Init_CLK(void){BCSCTL1=0x00;BCSCTL1 += XT2OFF; //关闭XT2,因为板子上没有BCSCTL1 += XTS; //低速振荡器是高频模式BCSCTL2=0x00;BCSCTL2 += SELM0;BCSCTL2 += SELM1; //MCLK的时钟源为低速晶体振荡器//此外,ACLK的时钟源为LFTX1,SMCLK的时钟源为DC0CLK//分频因子均为1}/******************端口初始化函数******************/void Init_Port(void){P3DIR=0;P3SEL=0; //P3所有管脚均初始化为输入方向和一般I/O口return;}/******************串口初始化函数******************/void Init_UART0(void){U0CTL=SWRST; //串行模块设置时的必须U0CTL += CHAR; //8位数据位,1位停止位,无校验U0TCTL=0x00;U0TCTL += SSEL0; //波特率时钟源选择为ACLKU0BR1=0x01;U0BR0=0xA0;U0MCTL=0xBA; //设置波特率为9600U0CTL &= ~SWRST;ME1 |= UTXE0+URXE0; //使能USART0模块IE1 |= URXIE0; //使能USART0的接收中断P3SEL |= BIT4+BIT5; //P3.4和P3.5为串口功能P3DIR |= BIT4; //P3.4为输出return;}/******************接收中断函数******************/#pragma vector=USART0RX_VECTOR__interrupt void Usart0Rx(){rec_PC = RXBUF0; //接收到的PC的命令if (rec_PC == CAN){while (1); //如果接收到CAN命令,则取消传输,程序中止//程序在此处循环,不再跳出中断}if (k == 0) //k=0表示这是第一次接收PC命令,判断是否是开始传输的标志NAK{if (rec_PC == NAK) //收到NAK则开始发送第一组数据,收到的不是NAK则返回继续等待NAK {cmpl = 0xFF - Seq; //计算包序号补码csum = FileSend[k]+FileSend[k+1]+FileSend[k+2]+FileSend[k+3]+FileSend[k+4];//计算垂直累加和校验码DataSend[0] = SOH;DataSend[1] = Seq;DataSend[2] = cmpl;DataSend[3] = FileSend[k];DataSend[4] = FileSend[k+1];DataSend[5] =FileSend[k+2];DataSend[6] = FileSend[k+3];DataSend[7] = FileSend[k+4];DataSend[8] = csum;//取得数据包while (j<9) //发送数据包{while ((IFG1 & UTXIFG0)==0);TXBUF0 = DataSend[j];j++;}k = k+5; //指向下一组数据Seq++; //数据包序号增1j = 0;return; //返回,不在执行下面的语句}}if (k != 0) //k!=0,表示已经发送过了数据包,接收到的是PC对数据包的确认命令{if (rec_PC == NAK) //PC发回NAK,则把刚才发送的数据包重新发送一遍{if (eot_flag == 1) //如果刚才发送的不是数据,而是EOT,则再将EOT重新发送{while ((IFG1 & UTXIFG0)==0);TXBUF0 = EOT;eot_flag = 1;return;}while (j<9){while ((IFG1 & UTXIFG0)==0);TXBUF0 = DataSend[j];j++;}j = 0;}if (rec_PC == ACK){if (eot_flag == 1) //表明刚才发送的是EOT,此时PC发回的ACK是对刚才发送的EOT的确认,程序完成{while (1);}else if (fin_flag == 1) //表明刚才发送的是最后一个数据包//此时PC发回的ACK是对刚才发送的最后一个数据包的确认//数据发送完成,发送EOT,返回等待确认{while ((IFG1 & UTXIFG0)==0);TXBUF0 = EOT;eot_flag = 1;}else //刚才发送的是一组普通的数据,取下一个数据包并发送{cmpl = 0xFF - Seq;//判断是否已经发送到了最后一组数据if (k==20){csum = FileSend[k]+FileSend[k+1]+0x1A+0X1A+0X1A;DataSend[0] = SOH;DataSend[1] = Seq;DataSend[2] = cmpl;DataSend[3] = FileSend[k];DataSend[4] = FileSend[k+1];DataSend[5] = 0X1A;DataSend[6] = 0X1A;DataSend[7] = 0X1A;DataSend[8] = csum;fin_flag = 1;}else{csum =FileSend[k]+FileSend[k+1]+FileSend[k+2]+FileSend[k+3]+FileSend[k+4];DataSend[0] = SOH;DataSend[1] = Seq;DataSend[2] = cmpl;DataSend[3] = FileSend[k];DataSend[4] = FileSend[k+1];DataSend[5] = FileSend[k+2];DataSend[6] = FileSend[k+3];DataSend[7] = FileSend[k+4];DataSend[8] = csum;}while (j<9){while ((IFG1 & UTXIFG0)==0);TXBUF0 = DataSend[j];j++;}k = k+5;Seq++;j = 0;}}}return;}。
Zmodem协议
Zmodem协议Zmodem协议是一种用于在计算机之间进行文件传输的协议,它是Xmodem协议的改进版本。
Zmodem协议通过增加数据压缩、数据加密和数据校验等功能,提高了文件传输的效率和可靠性。
本文将介绍Zmodem协议的基本原理、特点和应用。
首先,Zmodem协议采用了CRC校验和数据压缩技术,可以有效地检测和纠正传输过程中出现的错误。
在文件传输过程中,发送端会对数据进行CRC校验,确保数据的完整性;同时,Zmodem协议还支持数据压缩,可以减小传输的数据量,提高传输效率。
其次,Zmodem协议还支持断点续传功能,即使在传输过程中出现意外中断,也可以通过重新连接来继续文件传输,而不需要重新开始传输整个文件。
这一特点使Zmodem协议在传输大文件时表现出色,大大提高了文件传输的可靠性和效率。
此外,Zmodem协议还支持多文件传输和目录传输功能,可以一次性传输多个文件或整个目录,方便快捷。
这一特点使Zmodem协议在实际应用中更加灵活多样,适用于各种文件传输场景。
总的来说,Zmodem协议作为一种高效可靠的文件传输协议,具有以下特点,数据校验、数据压缩、断点续传、多文件传输和目录传输。
这些特点使得Zmodem协议在计算机之间进行文件传输时表现出色,受到了广泛的应用。
在实际应用中,Zmodem协议可以用于各种场景,比如在网络管理、系统维护、软件发布等方面。
通过Zmodem协议,用户可以方便地在不同计算机之间传输文件,提高工作效率,简化操作流程。
总之,Zmodem协议作为一种高效可靠的文件传输协议,具有广泛的应用前景。
它通过数据校验、数据压缩、断点续传、多文件传输和目录传输等功能,提高了文件传输的效率和可靠性,为计算机之间的文件传输提供了便利。
相信随着技术的不断进步,Zmodem协议将会在更多领域得到应用,为用户带来更加便捷的文件传输体验。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
研究 Xmodem 协议必看的 11个问题Xmodem 协议作为串口数据传输主要的方式之一,恐怕只有做过 bootloader 的才有机会接触一下, 网上有关该协议的内容要么是英语要么讲解不详细。
笔者以前写 bootloader 时研究过 1k-Xmodem ,参考了不少相关资料。
这里和大家交流一下我对 Xmodem 的理解,多多指教!1. Xmodem 协议是什么?XMODEM协议是一种串口通信中广泛用到的异步文件传输协议。
分为标准Xmodem 和 1k-Xmodem 两种,前者以 128字节块的形式传输数据,后者字节块为 1k 即 1024字节,并且每个块都使用一个校验和过程来进行错误检测。
在校验过程中如果接收方关于一个块的校验和与它在发送方的校验和相同时,接收方就向发送方发送一个确认字节 (ACK。
由于 Xmodem 需要对每个块都进行认可, 这将导致性能有所下降, 特别是延时比较长的场合, 这种协议显得效率更低。
除了 Xmodem ,还有 Ymodem , Zmodem 协议。
他们的协议内容和 Xmodem 类似,不同的是 Ymodem 允许批处理文件传输,效率更高; Zmodem 则是改进的了Xmodem ,它只需要对损坏的块进行重发,其它正确的块不需要发送确认字节。
减少了通信量。
2. Xmodem 协议相关控制字符SOH 0x01STX 0x02EOT 0x04ACK 0x06NAK 0x15CAN 0x18CTRLZ 0x1A3.标准 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 协议代码看了以上说明,再参考代码,应该很容易会理解代码编写者的思路。
XModem 源码#include "crc16.h"#define SOH 0x01#define STX 0x02#define EOT 0x04#define ACK 0x06#define NAK 0x15#define CAN 0x18#define CTRLZ 0x1A#define DLY_1S 1000#define MAXRETRANS 25static int last_error = 0;#include "string.h"void port_outbyte(unsigned char trychar{unsigned char buf[2];buf[0] = trychar;lowLevel_write(buf,1;}unsigned char port_inbyte(unsigned int time_out { unsigned char ch; int i;last_error = 0;if(lowLevel_read(&ch,1 == 1 return ch;last_error = 1;return ch;}static int check(int crc, const unsigned char *buf, int sz {if (crc{unsigned short crc = crc16_ccitt(buf, sz; unsigned short tcrc = (buf[sz]<<8+buf[sz+1]; if (crc == tcrc return 1;}else{int i;unsigned char cks = 0;for (i = 0; i < sz; ++i{cks += buf[i];}if (cks == buf[sz] return 1;}return 0;}static void flushinput(void{//while (port_inbyte(((DLY_1S*3>>1 >= 0 ; }int xmodemReceive(unsigned char *dest, int destsz { unsigned char xbuff[1030];unsigned char *p;int bufsz, crc = 0;unsigned char trychar = 'C';unsigned char packetno = 1;int i, c, len = 0;int retry, retrans = MAXRETRANS;for(;;{for( retry = 0; retry < 16; ++retry{if (trycharport_outbyte(trychar;c = port_inbyte((DLY_1S<<1;if (last_error == 0{switch (c{case SOH:bufsz = 128;goto start_recv;case STX:bufsz = 1024;goto start_recv;case EOT:flushinput(;port_outbyte(ACK; return len;case CAN:c = port_inbyte(DLY_1S; if (c == CAN {flushinput(;port_outbyte(ACK; return -1;}break;default:break;}}}if (trychar == 'C' {trychar = NAK; continue;}flushinput(;port_outbyte(CAN; port_outbyte(CAN; port_outbyte(CAN; return -2;start_recv:if (trychar == 'C' crc = 1;trychar = 0;p = xbuff;*p++ = c;for (i = 0; i < (bufsz+(crc?1:0+3; ++i{c = port_inbyte(DLY_1S;if (last_error != 0goto reject;*p++ = c;}if (xbuff[1] == (unsigned char(~xbuff[2] &&(xbuff[1] == packetno || xbuff[1] == (unsigned charpacketno-1 && check(crc, &xbuff[3], bufsz{if (xbuff[1] == packetno{int count = destsz - len;if (count > bufszcount = bufsz;if (count > 0{memcpy (&dest[len], &xbuff[3], count;len += count;}++packetno;retrans = MAXRETRANS+1;}if (--retrans <= 0{flushinput(;port_outbyte(CAN;port_outbyte(CAN;port_outbyte(CAN; return -3; } port_outbyte(ACK; continue; } reject: flushinput(; port_outbyte(NAK; } } int xmodemTransmit(unsigned char *src, int srcsz { unsigned char xbuff[1030]; int bufsz, crc = -1; unsigned char packetno = 1; int i, c, len = 0; int retry; for(;; { for( retry = 0; retry < 16; ++retry { c = port_inbyte((DLY_1S<<1; if (last_error == 0 { switch (c { case 'C': crc = 1; goto start_trans; case NAK: crc = 0; goto start_trans; case CAN: c = port_inbyte(DLY_1S; if (c == CAN { port_outbyte(ACK; flushinput(; return -1; } break;default: break; } } } port_outbyte(CAN; port_outbyte(CAN; port_outbyte(CAN; flushinput(; return -2; for(;; { start_trans: xbuff[0] = SOH; bufsz = 128; xbuff[1] = packetno; xbuff[2] = ~packetno; c = srcsz - len; if (c > bufsz c = bufsz; if (c >= 0{ memset (&xbuff[3], 0, bufsz; if (c == 0 { xbuff[3] = CTRLZ; } else { memcpy(&xbuff[3], &src[len], c; if (c < bufsz xbuff[3+c] = CTRLZ; } if (crc { unsigned short ccrc = crc16_ccitt(&xbuff[3], bufsz; xbuff[bufsz+3] = (ccrc>>8 & 0xFF; xbuff[bufsz+4] = ccrc & 0xFF; } else { unsigned char ccks = 0; for (i = 3; i < bufsz+3; ++i {ccks += xbuff[i]; } xbuff[bufsz+3] = ccks; } for (retry = 0; retry < MAXRETRANS; ++retry { for (i = 0; i < bufsz+4+(crc?1:0; ++i { port_outbyte(xbuff[i]; } c =port_inbyte(DLY_1S; if (last_error == 0 { switch (c { case ACK: ++packetno; len += bufsz; goto start_trans; case CAN: c = port_inbyte(DLY_1S; if ( c == CAN{ port_outbyte(ACK; flushinput(; return -1; } break; case NAK: default: break; } } }port_outbyte(CAN; port_outbyte(CAN; port_outbyte(CAN; flushinput(; return -4; } else { for (retry = 0; retry < 10; ++retry {port_outbyte(EOT; c = port_inbyte((DLY_1S<<1; if (c == ACK break; } flushinput(; return (c == ACK?len:-5; } } } }。