SCI_uart dsp28335 程序，利用串口调试助手,电脑和dsp 相互通信。 DSP program 251万源代码下载-
&文件名称: SCI_uart& & [
& & & & &&]
&&所属分类:
&&开发工具: C-C++
&&文件大小: 276 KB
&&上传时间:
&&下载次数: 0
&&提 供 者:
&详细说明：dsp28335 uart程序，利用串口调试助手,电脑和dsp 相互通信。-dsp28335 uart program, the use of serial debugging assistant, computer and dsp to communicate with each other.
文件列表(点击判断是否您需要的文件，如果是垃圾请在下面评价投诉):
&&SCI_uart\.ccsproject&&........\.cproject&&........\.launches\SCI_uart.launch&&........\.project&&........\.settings\org.eclipse.cdt.codan.core.prefs&&........\.........\org.eclipse.cdt.debug.core.prefs&&........\.........\org.eclipse.core.resources.prefs&&........\28335_RAM_lnk.cmd&&........\Debug\ccsObjs.opt&&........\.....\example.obj&&........\.....\example.pp&&........\.....\makefile&&........\.....\objects.mk&&........\.....\SCI_uart.map&&........\.....\SCI_uart.out&&........\.....\SCI_uart_linkInfo.xml&&........\.....\source\DSP2833x_Adc.obj&&........\.....\......\DSP2833x_Adc.pp&&........\.....\......\DSP2833x_ADC_cal.obj&&........\.....\......\DSP2833x_CodeStartBranch.obj&&........\.....\......\DSP2833x_CpuTimers.obj&&........\.....\......\DSP2833x_CpuTimers.pp&&........\.....\......\DSP2833x_CSMPasswords.obj&&........\.....\......\DSP2833x_DBGIER.obj&&........\.....\......\DSP2833x_DefaultIsr.obj&&........\.....\......\DSP2833x_DefaultIsr.pp&&........\.....\......\DSP2833x_DisInt.obj&&........\.....\......\DSP2833x_DMA.obj&&........\.....\......\DSP2833x_DMA.pp&&........\.....\......\DSP2833x_ECan.obj&&........\.....\......\DSP2833x_ECan.pp&&........\.....\......\DSP2833x_ECap.obj&&........\.....\......\DSP2833x_ECap.pp&&........\.....\......\DSP2833x_EPwm.obj&&........\.....\......\DSP2833x_EPwm.pp&&........\.....\......\DSP2833x_EQep.obj&&........\.....\......\DSP2833x_EQep.pp&&........\.....\......\DSP2833x_GlobalVariableDefs.obj&&........\.....\......\DSP2833x_GlobalVariableDefs.pp&&........\.....\......\DSP2833x_Gpio.obj&&........\.....\......\DSP2833x_Gpio.pp&&........\.....\......\DSP2833x_I2C.obj&&........\.....\......\DSP2833x_I2C.pp&&........\.....\......\DSP2833x_Mcbsp.obj&&........\.....\......\DSP2833x_Mcbsp.pp&&........\.....\......\DSP2833x_MemCopy.obj&&........\.....\......\DSP2833x_MemCopy.pp&&........\.....\......\DSP2833x_PieCtrl.obj&&........\.....\......\DSP2833x_PieCtrl.pp&&........\.....\......\DSP2833x_PieVect.obj&&........\.....\......\DSP2833x_PieVect.pp&&........\.....\......\DSP2833x_Sci.obj&&........\.....\......\DSP2833x_Sci.pp&&........\.....\......\DSP2833x_Spi.obj&&........\.....\......\DSP2833x_Spi.pp&&........\.....\......\DSP2833x_SysCtrl.obj&&........\.....\......\DSP2833x_SysCtrl.pp&&........\.....\......\DSP2833x_usDelay.obj&&........\.....\......\DSP2833x_Xintf.obj&&........\.....\......\DSP2833x_Xintf.pp&&........\.....\......\subdir_rules.mk&&........\.....\......\subdir_vars.mk&&........\.....\sources.mk&&........\.....\subdir_rules.mk&&........\.....\subdir_vars.mk&&........\DSP2833x_Headers_nonBIOS.cmd&&........\example.c&&........\f28335.gel&&........\include\28335dsk.h&&........\.......\DSP2833x_Adc.h&&........\.......\DSP2833x_CpuTimers.h&&........\.......\DSP2833x_DefaultIsr.h&&........\.......\DSP2833x_DevEmu.h&&........\.......\DSP2833x_Device.h&&........\.......\DSP2833x_DMA.h&&........\.......\DSP2833x_Dma_defines.h&&........\.......\DSP2833x_ECan.h&&........\.......\DSP2833x_ECap.h&&........\.......\DSP2833x_EPwm.h&&........\.......\DSP2833x_EPwm_defines.h&&........\.......\DSP2833x_EQep.h&&........\.......\DSP2833x_Examples.h&&........\.......\DSP2833x_GlobalPrototypes.h&&........\.......\DSP2833x_Gpio.h&&........\.......\DSP2833x_I2c.h&&........\.......\DSP2833x_I2c_defines.h&&........\.......\DSP2833x_Mcbsp.h&&........\.......\DSP2833x_PieCtrl.h&&........\.......\DSP2833x_PieVect.h&&........\.......\DSP2833x_Project.h&&........\.......\DSP2833x_Sci.h&&........\.......\DSP2833x_Spi.h&&........\.......\DSP2833x_SWPrioritizedIsrLevels.h&&........\.......\DSP2833x_SysCtrl.h&&........\.......\DSP2833x_Xintf.h&&........\.......\DSP2833x_XIntrupt.h&&........\.......\IQmathLib.h&&........\.......\SFO.h&&........\.......\SFO_V5.h&&........\source\DSP2833x_Adc.c
&输入关键字，在本站251万海量源码库中尽情搜索：小木虫 --- 500万硕博科研人员喜爱的学术科研平台
&&查看话题
请教各位大神在发SCI论文时是自己翻译呢，还是花钱请别人帮忙翻译？
如题：各位大神发时是自己翻译呢，还是花钱请别人帮忙翻译？本人英语一般，现在研二，没动力学英语了 ，很羡慕英语好的同学~
你们老板还亲自给修改，真好
应该说是不是直接用英语写，呵呵！
看了不少帖子，多数认为直接用英语写比较好。
后悔本科时没好好学英语:shuai:
是的，都这么说呢
我本科毕业设计翻译英文论文时确实很头痛
老板比较负责，文章无论好坏，一般都会给个修改意见。。有时会亲自修改
研究生必备与500万研究生在线互动！
扫描下载送金币
浏览器进程
打开微信扫一扫
随时随地聊科研用 UART 做文件传输（采用 Xmodem协议）
用UART做文件传输，采用Zmodem协议详解
UART是一种通用串行数据，用于异步通信。该总线双向通信，可以实现全双工传输和接收。在嵌入式设计中，UART用来与PC进行通信，包括与监控调试器和其它器件，如通信。
UART首先将接收到的并行数据转换成串行数据来传输。消息帧从一个低位起始位开始，后面是7个或8个数据位，一个可用的奇偶位和一个或几个高位停止位。发现开始位时它就知道数据准备发送，并尝试与时钟频率同步。如果选择了奇偶，UART就在数据位后面加上奇偶位。奇偶位可用来帮助错误校验。
　　在接收过程中，UART从消息帧中去掉起始位和结束位，对进来的字节进行奇偶校验，并将数据字节从串行转换成并行。UART也产生额外的信号来指示发送和接收的状态。例如，如果产生一个奇偶错误，UART就置位奇偶标志。
　　数据方向和通信速度
　　数据传输可以首先从最低有效位(LSB)开始。然而，有些UART允许灵活选择先发送最低有效位或最高有效位(MSB)。
　　中的UART传送数据的速度范围为每秒几百位到1.5Mb。例如，嵌入在ElanSC520微控制器中的高速UART通信的速度可以高达1.1152Mbps。UART波特率还受发送和接收线对距离(线长度)的影响。
　　目前，市场上有只支持异步通信和同时支持异步与同步通信的两种硬件可用于UART。前者就是UART名字本身的含义，在微控制器中被称为串行通信(SCI)；微控制器中的通用同步异步(USART)和在微控制器中的UART是后者的两个典型例子。
1.1 系统说明 本应用例使用 SPMC75F2413A 的 UART 完成文件的 Upload（PC-&SPMC75F2413A）,通过Xmodem 文件传输协议的支持达到很好的传输效果。从而为大量数据的传输及驱动程序的重载提供了一个可行的实施方法。 1.2 Xmodem 简介 FTP 即 File Transfer Protocol 的缩写，串行通信的文件传输协议主要有：Xmodem、Ymodem、Zmodem 和 KERMIT 等。 Xmodem 协议一般支持 128 字节的数据包，并且支持一般校验和、CRC 两种校验方式，在出现数据包错误的情况下支持多次重传（一般为 10 次） 。Xmodem 协议传输由接收程序和发送程序完成。先由接收程序发送协商字符，协商校验方式，协商通过之后发送程序就开始发送数据包，接收程序接收到完整的一个数据包之后按照协商的方式对数据包进行校验。校验通过之后发送确认字符，然后发送程序继续发送下一包；如果校验失败，则发送否认字符，发送程序重传此数据包。 1.3&&& Xmodem 协议 1.3.1& 相关说明 1、定义：&SOH& 01H、&EOT& 04H、&ACK& 06H、&NAK& 15H、&CAN& 18H。 2、UART 格式：Asynchrous、8 data－bits、no parity、one stop－bit。 1.3.2& 协议简介 Xmodem 协议是由 Ward Chritensen 于 70 年代提出并实现的，传输数据单位为信息包，包含一个标题开始字符&SOH&，一个单字节包序号，一个包序号的补码，128 个字节数据和一个单字节的校验和。它把数据划分成 128个字符的小包进行发送，每发送一个小包都要检查是否正确，如果信息包正确接收方发送一个字节&ACK&的应答；有错重发则发送一个字节&NAK&应答，要求重发。因此 Xmodem 是一种发送等待协议，具有流量控制功能。优点：简单通用，几乎所有通信软件都支持该协议。 缺点：慢。检验和信息包格式如图 1－1 所示。
图 1－1 检验和信息包格式
&Xmodem 协议的数据包格式在 90 年代经过一次修改，传输数据单位仍为信息包，包含一个标题开始字符 SOH，一个单字节包序号，一个包序号的补码，128 个字节数据和一个双字节的 CRC16校验。所以新的协议格式信息包如图 1－2 所示。
图 1－2 CRC 校验信息包格式
1.3.3& 校验和信息包 1、校验和信息包 &SOH&&blk #&&255-blk #&&--128 data bytes--&&cksum& 其中： &SOH&&&&&&&&&& = 01 hex &blk #&&&&&& = 信息包序号，从 01 开始以发送一包将加 1，加到FF hex 将循环。& &255-blk #&&& = 信息包序号的补码。 &cksum&&&&&&& = 保留字节，丢掉进位的和校验。 2、校验和方式数据传输流程 & 接收方要求发送方以校验和方式发送时以 NAK来请求，发送方将对此做出应答。如表 1－1 所示传输 5 包数据的示意过程。
表 1－1 校验和数据传输过程
1.3.4&&& CRC 校验信息包 1、CRC 校验信息包 &SOH&&blk #&&255-blk #&&--128 data bytes--&&CRC hi&&CRC lo& 其中： &SOH&&&&&&&&&& = 01 hex &blk #&&&&&& = 信息包序号，从 01 开始以发送一包将加 1，加到FF hex 将循环。& &255-blk #&&& = 信息包序号的补码。 &CRC hi&&&&&& = CRC16 高字节。 &CRC lo&&&&&& = CRC16 低字节。 2、CRC 描述 计算 16－Bit CRC 校验的除数多项式为 X^16 + X^12 + X^5 + 1，信息包中的 128 数据字节将参加 CRC 校验的计算。在发送端 CRC16 的高字节在先，低字节在后。 3、CRC 校验方式数据传输流程 & 接收方要求发送方以 CRC 校验方式发送时以‘C’来请求，发送方将对此做出应答。如表 1－2所示传输 3 包数据的示意过程。
表 1－2 CRC 校验数据传输过程
4、在发送方仅仅支持校验和的传输方式时，就应对其请求 NAK，要求以 CheckSum 的校验方式来发送数据，如表 1－1 所示过程。如果发送方仅仅支持 CRC校验的传输方式，应以’C’来请求发送，如表 1－2 所示过程。如果两者都支持的话，将优先以’C’来请求发送。所以接收程序的实现过程将如表 1－3 所示。
表 1－2 CRC 校验数据传输过程
&5、信息包中如果剩余的数据不足 128－Byte 信息包的格式为： 【SOH 04 0xFB Data[100] CPMEOF[28] CRC CRC】 ，不足的 CPMEOF[28]将以 0x1A（^Z）填充。 &【注】 ：关于 Xmodem 协议的细节请参看附录 1 或《Xmodem 协议》 。
1.4& 系统组成 系统包括和 PC 相连的 RS232 电平转换，和数据存储的 SRAM 接口，如图 1－3 所示。其中： IOB[0－15]连接到SRAM& HM62864A的地址线A[0－15]， IOD[0－7]& 连接到SRAM& HM62864A的地址线 I/O[0－7]，IOD8、IOD9 和 IOD10 分别]连接到 SRAM HM62864A 的 CS1、OE 和 WE。Txd2 和 Rxd2 则通过电平转换后通过线连接到 PC 串口的 Rxd 和 Txd。
&图 1－3 系统框图&
& SRAM HM62864A 64K 的数据存储空间是用来存储接收来的大量数据，当然如果要验证所接收的数据和发送的数据是否一致，可以读取来查看。
2.1 软件说明 应用例程序部分主要完成 Xmodem 协议 Upload 文件，即接收来自 PC 端的文件。应用例软件部分要完成相关硬件资源的初始化，包括 UART 和 CMT0 的初始化。在范例中将把接收来的数据缓存到 SRAM中， 所以还有对 HM62864A& SRAM 的操作部分。 当然接收来的数据可以很灵活的来处理，这里只是为了方便对数据的校对。 2.2 档案构成
2.3 子程序说明 Spmc75_XmodemInial() 原&&& 形& void Spmc75_XmodemInitial(void) 描&&& 述& UART 和 CMT0 初始化及标志位复位。 输入参数& 无 输出参数& 无 头 文 件& AN_SPMC75_0109.H 库 文 件& 无 注意事项& UART 波特率初始为 115200bps，UART 初始化使用 Channel2，CMT0 固定为 8Hz 中断 例&&& 子& Spmc75_XmodemInitial();&&& //Initial Xmodem hardware.
Spmc75_XmodemReceive() 原&&& 形& void Spmc75_XmodemReceive(void) 描&&& 述& 以 Xmodem 协议发送接收请求，接收文件。 输入参数& 无 输出参数& 无 头 文 件& AN_SPMC75_0109.H 库 文 件& 无 注意事项& 等待…… 直到文件传输完毕。 在接收过程中，接收到一个校验无误的信息包后将申请软中断(break Interrupt)。可以在软中断中对数据进行处理。 整个文件接收完后将有一个标志位（xmodemstatus.B._recvrdy）置位。例&&& 子& Spmc75_XmodemReceive();&&& //Receive file Transfer &&Xmodem_Rxd_ISR( ) 原&&& 形& void Xmodem_Rxd_ISR(void) 描&&& 述& UART Rxd 中断服务函数。 输入参数& 无 输出参数& 无 头 文 件& AN_SPMC75_0109.H 库 文 件& 无 注意事项& 在 UART Rxd ISR 中使用，用作接收数据。 例&&& 子& void Q6(void) __attribute__ ((ISR)); void IRQ6(void) { &if(P_UART_Status-&B.RXIF) &{ && Xmodem_Rxd_ISR();&& //Xmodem Rxd ISR. &} }
Spmc75_TimeOut_ISR( ) 原&&& 形& void Spmc75_TimeOut_ISR(void) 描&&& 述& Time out 定时中断服务函数。 输入参数& 无 输出参数& 无 头 文 件& AN_SPMC75_0109.H 库 文 件& 无 注意事项& CMT0 中断服务函数，CMT0 固定中断频率为 8Hz。 例&&& 子& void IRQ7(void) __attribute__ ((ISR)); void IRQ7(void) { &if(P_INT_Status-&B.CF) &{ &&& if(P_CMT_Ctrl-&B.CM0IF && P_CMT_Ctrl-&B.CM0IE) && { &&&&& Spmc75_TimeOut_ISR();& //8Hz ISR for timout. && } &} }&&
3.1 DEMO 程序 范例为接收文件并存入 SRAM。范例程序可以结合图 1－3 所示的原理框图来操作，首先是SPMC75F2314A 接收来自 PC 的数据，并且存储到 SRAM 中。接收完毕可以对说存储的数据进行验证，即：从 SRAM 中读取接收来的数据来查看，人为的进行评估。 #include "AN_SPMC75_0109.H" //=================================================================== unsigned
Buffer[128]; extern& UInt16 I UInt16&& Outputaddr = 0; &main() { &UInt16& & & P_I_SPE-&W = 0x00; & P_IOB_SPE-&W = 0x00; & P_IOC_SPE-&W = 0x00; &SRAM_Inial(); &Q_(); &while(1) &{ &&& Spmc75_XmodemInitial();&&& //Initial Xmodem hardware. &&& Spmc75_XmodemReceive();&&& //Receive file Transfer &&& && if(xmodemstatus.B._recvrdy)& //Recv ready? && { &&&&& xmodemstatus.B._recvrdy = 0; &&&&& while(Outputaddr != Intputaddr)& //Read file from SRAM &&&& {//每次读取 128－Byte，请在每次读取 128－Byte 后来人为验证数据的正确性。&&&&&&&&&&&& //尤其要保证 SRAM 的操作是无误的。 &&&&&&& for(i=0;i&128 && Outputaddr != Ii++) &&&&&&& Buffer[i] = SRAM_ReadAByte(++Outputaddr); &&&& } && } &} } //====================================================================// Description: BREAK interrupt is used to XXX // Notes: Get Data.
//====================================================================extern unsigned
rxdbuf[133];& //接收数据的缓存器（Xmodem.C 中定义） UInt16 Intputaddr = 0; void BREAK(void) __attribute__ ((ISR)); void BREAK(void) { &UInt16& &for(i=3;i&131;i++) &{&&&& &&& SRAM_WriteAByte(++Intputaddr, rxdbuf[i]);& //数据存入 SRAM &} } //====================================================================// Description: IRQ6 interrupt source is XXX,used to XXX // Notes: //====================================================================void IRQ6(void) __attribute__ ((ISR)); void IRQ6(void) { &if(P_INT_Status-&B.UARTIF) & {&&&&&&&&&&& &&& if(P_UART_Status-&B.TXIF && P_UART_Ctrl-&B.TXIE){;} && if(P_UART_Status-&B.RXIF) && { &&&& Xmodem_Rxd_ISR();&& //Xmodem Rxd ISR. && } &}&& } //====================================================================// Description: IRQ7 interrupt source is XXX,used to XXX // Notes: //====================================================================void IRQ7(void) __attribute__ ((ISR)); void IRQ7(void) { &if(P_INT_Status-&B.CF) &{ &&& if(P_CMT_Ctrl-&B.CM0IF && P_CMT_Ctrl-&B.CM0IE) && { &&&&& Spmc75_TimeOut_ISR();& //8Hz ISR for timout. && } &&& P_CMT_Ctrl-&W = P_CMT_Ctrl-&W; &} }
3.2& 文件传输 通过 Console 口完成文件的 Xmodem 传输。一下所介绍的将是在 Window2000 操作系统下所作的演示。 1、超级终端，如图 3－1 所示。 【开始】－&【程序】－&【附件】－&【通讯】－&【超级终端】&&
图 3－1 超级终端
2、新建连接，如图 3－2 所示。 在【名称】中输入名称，选择图标…… 单击【确定】 。 &
图 3－2 新建连接
3、连接到，如图 3－3 所示。 连接到，在【连接时使用】中选择线所连接的 COM 口，单击【确定】 。&&
图 3－3 连接到
4、COM 属性，如图 3－4 所示。 在【每秒位数】选择波特率 115200bps，在【数据流控制】中选择无，其它默认，单击【确定】 。 &
图 3－4 COM 属性
5、按钮介绍，如图 3－5 所示。 有用的按钮这里有三个，连接、断开和发送。&&
图 3－5 按钮介绍
6、协议选择，如图 3－6 所示。 单击发送按钮，在对话框【文件名】中选择要传输的文件，在【协议】中选择 Xmodem。&
7、发送文件，如图 3－7 所示。 在上边都设置完以后，单击【发送】弹出信息框就开始进行文件的传输。
图 3－7 发送文件&
&8、传输信息，如图 3－8 所示。 传输的文件、数据包、校验方式、重试次数、重试总次数、应答情况、文件大小、用时等信息。 &
图 3－8 传输信息
4 MCU使用资源
4.1 硬件使用资源说明
&【附录 1】Xmodem 协议部分。 Table of Ctents: 1. DEFINIO 2. TRANSMON MEDIUM LEVEL PROTOCOL 3. MAGE BLOCK LEVEL PROTOCOL 4. FILE LEVEL PROTOCOL 5. DATA FLOW EXLE INCLUDIaNG ERROR RECOVERY 6. PROGRAMMING TIPS. &1. DEFINITIONS. & &soh& 01H&& &eot& 04H&& &ack& 06H&& &nak& 15H&& &can& 18H &2. TRANSMISSION MEDIUM LEVEL PROTOCOL Asynchronous, 8 data bits, no parity, one op bit. &&& The protocol imposes no restrictions on the contents of the data being transmitted.& No& control& characters& are& looked& for& in& the& 128-byte& data& messages.&Absolutely& any& kind& of& data& may& be& sent& -& binary,& ASCII,& etc.& The& protocol has not formally been adopted to a 7-bit environment for the transmission of ASCII-only (or unpacked-hex) data , although it could be simply by having both& ends& agree& to& AND& the& protocol-dependent& data& with& 7F& hex& before& validng it.& I specifically am referring to the checksum, and the block numbers and their ones-complement. &&& Those& wishing to maintain compatibility of the CP/M file structure, i.e. to allow modemming ASCII files to or from CP/M systems should follow this data format: & * ASCII tabs used (09H); tabs set every 8. & * Lines terminated by CR/LF (0DH 0AH) & * End-of-file indicated by ^Z, 1AH.& (one or more) & * Data is variable length, i.e. should be considered a &&& continuous stream of data bytes, broken into 128-byte &&& chunks purely for the purpose of transmission. & * A CP/M "peculiarity": If the data ends exactly on a &&& 128-byte boundary, i.e. CR in 127, and LF in 128, a &&& subsequent sector containing the ^Z EOF character(s) &&& is optional, but is preferred.& Some utilities or &&& user programs still do not handle EOF without ^Zs. & * The last block sent is no different from others, i.e. there is no "short block". &3. MESSAGE BLOCK LEVEL PROTOCOL && Each block of the transfer looks like: &SOH&&blk #&&255-blk #&&--128 data bytes--&&cksum& &&& in which: &SOH&&&&& = 01 hex &blk #&&& = binary number, starts at 01 increments by 1, and &&&&&&& wraps 0FFH to 00H (not to 01) &255-blk #& = blk # after going thru 8080 "CMA" instr, i.e. &&&&&&& each bit complemented in the 8-bit block number. &&&&&&& Formally, this is the "ones complement". &cksum&& = the sum of the data bytes only.& Toss any carry. &4. FILE LEVEL PROTOCOL --4A. COMMON TO BOTH SENDER AND RECEIVER: &&& All errors are retried 10 times. &&& Some& versions& of& the& protocol& use& &can&,& ASCII& ^X,& to& cancel& transmission.&
This was never adopted as a standard, as having a single "abort" character makes& the& transmission& susceptible& to& false& termination& due& to& an& &ack&& &nak& or &soh& being corrupted into a &can& and cancelling transmission. &&& The protocol may be considered "receiver driven", that is, the sender need not automatically re-transmit, although it does in the& current implementations. &--4B. RECEIVE PROGRAM CONSIDERATIONS: &&& The receiver has a 10-second timeout.& It sends a &nak& every time it times out.& The receiver's first timeout, which sends a &nak&, signals the transmitter& to& start.& Optionally,& the& receiver& could& send& a& &nak&& immediately, in& case& the& sender& was& ready.& This& would& save& the& initial& 10-second& timeout. However, the receiver MUST continue to timeout& every 10 seconds in& case the sender wasn't ready. &&& Once& into& a& receiving& a& block,& the& receiver& goes& into& a& one-second& timeout for each character and the checksum.& If the receiver wishes to &nak& a block for any reason (invalid header, timeout receiving data), it must wait for the line to clear. See "programming tips" for ideas Synchronizing:& If a valid block number is received, it will be: 1) the expected one, in which cas or 2) a repeat of the previously received block.& This should be considered OK, and only indicates that the receivers &ack& got& glitched,& and& the& sender& re-& 3)& any& other& block& number& indicates a fatal loss of synchronization, such as the rare case of the sender& getting a line-glitch that looked like an &ack&.& Abort the transmission, sending a &can& &--4C. SENDING PROGRAM CONSIDERATIONS. &&& While waiting for transmission to begin, the sender has only a single very long timeout, say one minute. In the current protocol, the sender has a 10 second timeout before retrying.& I suggest NOT doing this, and letting the protocol be completely receiver-driven.& This& will& be& compatible& with existing programs. When the sender has no more data, it sends an &eot&, and awaits& an& &ack&,& resending& the& &eot&& if& it& doesn't& get& one.& Again,& the& protocol could& be& receiver-driven,& with& the& sender& only& having& the& high-level& 1-minute timeout to abort. &5. DATA FLOW EXAMPLE INCLUDING ERROR RECOVERY Here is a sample of the data flow, sending a 3-block message. It includes the two most common line hits - a garbaged block, and an &ack& reply getting garbaged. &xx& represents the checksum byte. &SENDER&&&&&& RECEIVER &&&&&&& times out after 10 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& &soh& 03 FC -data- &xx&& ---&&&& &ack& &eot&&&&&&&& ---& &&&&&&&& &---&& &ack&&&
&6. PROGRAMMING 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. &*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. &&---------------------------------------------------------------& MODEM PROTOCOL OVERVIEW,& CRC OPTION ADDENDUM Last Rev: (preliminary& 1/13/85) This document describes the changes to the Christensen Modem Protocol that implement the CRC option. This document is an addendum to Ward Christensen's "Modem Protocol Overview". This& document and Ward's document are both required& for a complete description of the Modem Protocol. &--A. Table of Contents 1.& DEFINITIONS 7.& OVERVIEW OF CRC OPTION 8.& MESSAGE BLOCK LEVEL PROTOCOL, CRC MODE 9.& CRC CALCULATION 10. FILE LEVEL PROTOCOL, CHANGES FOR COMPATIBILITY 11. DATA FLOW EXAMPLES WITH CRC OPTION &--B. ADDITIONAL DEFINITIONS &C& 43H &7. OVERVIEW OF CRC OPTION The CRC used in the Modem Protocol is an alternate form of block check which& provides& more& robust& error& detection& than& the& original& checksum.& Andrew S. Tanenbaum says in his book, Computer Networks, that the CRC-CCITT used by& the& Modem& Protocol& will& detect& all& single& and& double& bit& errors,& all& errors with an odd number of bits, all burst errors of length 16 or less, 99.997% of 17-bit error bursts, and 99.998% of 18-bit and longer bursts. The changes to the Modem Protocol to replace the checksum with the CRC are straight for ward. If that were all that we did we would not be able to communicate between a program using the old checksum protocol and one using the new CRC protocol. An initial handshake was added to solve this
problem. The handshake allows a receiving program with CRC capability to determine whether the sending& program supports the CRC option, and to& switch it to CRC mode if it does. This handshake is designed so that it will work properly with programs which implement only& the original protocol.& A description of this handshake is presented in section 10. &8. 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. &&&&&&&&&&& See the next section for CRC calculation. &9. CRC CALCULATION --9A. FORMAL DEFINITION OF THE CRC CALCULATION To calculate the 16 bit CRC the message bits are considered to be the coefficients of a polynomial. This message polynomial is first multiplied by X^16 and then divided by the generator polynomial (X^16 + X^12 + X^5 + 1) using modulo two arithemetic. The remainder left after the division is the desired CRC. Since a message block in the Modem Protocol is 128 bytes or 1024 bits, the message polynomial will be of order X^1023. The hi order bit of the first byte of the message block is the coefficient of X^1023 in the message polynomial. The lo order bit of the last byte of the message block is the coefficient of X^0 in the message polynomial. &--9B. EXAMPLE OF CRC CALCULATION WRITTEN IN C /* This& function& calculates& the& CRC& used& by& the& "Modem& Protocol"& The& first& argument is a pointer to the& message block. The second argument is the number of bytes in the message block. The message block used by& the Modem& Protocol contains 128 bytes. The function return value is an integer which contains the CRC. The lo order 16 bits of this integer are the coefficients of the CRC. The The lo order bit is the lo order coefficient of the CRC. */ int calcrc(ptr, count) char *& { &&& int crc = 0, &&&& while(--count &= 0) { & crc = crc ^ (int)*ptr++ && 8; & for(i = 0; i & 8; ++i) &&&&& if(crc & 0x8000) crc = crc && 1 ^ 0x1021; &&&&& else crc = crc && 1; &} &&& return (crc & 0xFFFF); &&& } &10. FILE LEVEL PROTOCOL, CHANGES FOR COMPATIBILITY --10A. COMMON TO BOTH SENDER AND RECEIVER: The& only& change& to& the& File& Level& Protocol& for& the& CRC& option& is& the& initial handshake which is used to determine if both the sending and the receiving
programs& support& the& CRC& mode.& All& Modem& Programs& should& support& the& checksum mode for compatibility& with& older versions. A receiving program that wishes to receive in CRC mode implements the mode setting handshake by sending a &C& in place of the initial &nak&. If the sending program supports CRC mode it will recognize the &C& and will set itself into CRC mode, and respond by sending the first block as if a &nak& had been received. If the sending program does not support CRC mode it will not respond to the &C& at all. After the receiver has sent the &C& it will wait up to 3-seconds for the &soh& that starts the first block. If it receives a &soh& within 3-seconds it will assume the sender supports CRC mode and will proceed with the file exchange in CRC mode. If no &soh& is received within 3-seconds the& receiver will switch to checksum mode, send a &nak&, and proceed in checksum mode. If the receiver wishes to use checksum mode it should send an initial &nak& and& the& sending& program& should& respond& to& the& &nak&& as& defined& in& the& original Modem Protocol. After the mode has been set by the initial &C& or &nak& the protocol follows the original Modem Protocol and is identical whether the checksum or CRC is being used. &--10B. RECEIVE PROGRAM CONSIDERATIONS: There& are& at& least& 4& things& that& can& go& wrong& with& the& mode& setting& handshake. & 1. the initial &C& can be garbled or lost. & 2. the initial &soh& can be garbled. & 3. the initial &C& can be changed to a &nak&. & 4. the initial &nak& from a receiver which wants to receive in &&&& Checksum can be changed to a &C&. The first problem can be solved if the& receiver& sends& a& second& &C&& after& it& times& out& the& first& time.& This& process can& be& repeated& several& times.& It& must& not& be& repeated& a& too& many& times& before sending a& &nak& and& switching to checksum mode or a sending program without CRC& support& may& time& out& and& abort.& Repeating& the& &C&& will& also& fix& the& second problem if the sending program cooperates by responding as if a &nak& were received instead of ignoring the extra &C&. &It is possible to fix problems 3 and 4 but probably not worth the trouble since they will occur very infrequently. They could be fixed by switching modes in either the sending or the receiving program after a large number of successive &nak&s. This solution would risk other problems however. &--10C. SENDING PROGRAM CONSIDERATIONS. The sending program should start in the checksum mode. This will insure compatibility& with& checksum& only& receiving& programs.& Anytime& a& &C&& is& received before the first &nak& or &ack& the sending program should set itself into CRC mode and respond as if a &nak& were received. The sender should respond to additional &C&s as if they& were &nak&s until the first &ack& is received. This will& assist the receiving program in determining the correct mode when the &soh& is lost or garbled. After the first &ack& is received the sending program should ignore &C&s. &11. DATA FLOW EXAMPLES WITH CRC OPTION --11A. RECEIVER HAS CRC OPTION, SENDER DOESN'T Here is a data flow example for the case where the receiver requests transmission in the CRC mode& but the sender does& not support the CRC& option. This example also includes various transmission errors. &xx& represents the checksum byte. &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& &--11B. RECEIVER AND SENDER BOTH HAVE CRC OPTION Here is a data flow example for the case where the receiver requests transmission in the CRC mode and the sender supports the CRC option. This example also includes various transmission errors. &xxxx& represents the 2 CRC bytes. SENDER&&&&&&&& RECEIVER &&&&&&&&&&& &---&&&& &C& &soh& 01 FE -data- &xxxx& ---& &&&&&&&&&&& &---&&&& &ack& &soh& 02 FD -data- &xxxx& ---&&&& (data gets line hit) &&&&&&&&&&& &---&&&& &nak& &soh& 02 FD -data- &xxxx& ---& &&&&&&&&&&& &---&&&& &ack& &soh& 03 FC -data- &xxxx& ---& && (ack gets garbaged)&&&&& &---&&&&&&&& &ack& &&&&&&&&& times out after 10 seconds, &&&&&&&&&&& &---&&&& &nak& &soh& 03 FC -data- &xxxx& ---& &&&&&&&&&&& &---&&&& &ack& &eot&&&&&&&&&& ---& &&&&&&&&&&& &---&&&& &ack&&&
ZMODEM协议
1.1& 协议的历史 在 70 年代后期，调制刚刚开始打入新兴的台式机市场。由于缺乏为文件传输建立的标准，Ward Christensen开发了后来成为 XMODEM的文件传输协议。对 XMODEM 的增强很快就到来了，导致了整个协议族的产生，包括 YMODEM 和 XMODEM－1K。 &XMODEM 并不是一个精心设计的协议，它来源于广泛的研究和试验。它更接近于一个“周末工程” ，即个人的使用软件。对于这个最初的目的，随着时间的流逝，它还是支持的。XMODEM确实很有能力，但他有几个严重的局限： ? 协议控制字符没有包装到数据包中，是的协议易于受到噪声和单字符出错的影响。 ? XMODEM要求完全清除的 8位频道。频道需要通过所有控制字符，包括 X、XOFF、CR等等。许多老的分时系统不能满足这种要求。他们的设备驱动程序引起某些协议丢失。 ? BL：XMODEM 家族所使用的短包长度，不是 128 就是
字节，因为在发送下一个数据包之前每个数据包必须被认可，这就导致频道的低效使用。 &在 年，包交换网络提供商 Telenet委托Chuck Forsberg of Omen 开发新的文件传输程序，它可以在网络上高效的使用。结果就产生了 ZMODEM。它由一个公共域程序和一个新协议组成。 名称ZMODEM可能隐含着它是按XMODEM和YMODEM排列下来的后代，但并不真是这样的。ZMODEM 完全是新的协议，与这些早期系统中任何一个的共同点都非常少。& 1.2 ZMODEM 概述 ZMODEM 不同于 XMODEM 之处是和之间传递的所有信息都包含在数据包中，在ZMODEM 中称为帧。即使是简单的协议协议信息（比如确认信号）也在数据包中，这提供给 ZMODEM 很好的保护，以避免偶然的协议信息。 &ZMODEM 帧有两个组件。每个帧以报头开始，它标识帧的类型，并带有至多 4 个字节的信息。这 4个字节称为ZF0到 ZF3(按位置分别是 3到 0)。数据子包的流是原始数据块，可以有选择地跟随一个报头。 &每个数据子包可以包含至多
个字节的数据，其后跟随一个 CRC 值用于校验。对可连接到一个报头之后的数据子包的个数没有限制，这就是说，一个文件的所有数据可在一个帧内传送。
1.3 ZMODEM 帧类型 ZMODEM 支持多种帧类型。要实现简单的 ZMODEM 并不需要所有这些帧类型；有些用于更复杂的出错恢复和传输机制。这里提供一个完整的列表： &? ZRQINIT＝0： 当ZMODEM 发送器启动时， 它发送这种帧。 它是请求接收器发送它的 ZRINIT帧，该帧将开始文件传输。ZRQINIT 帧头可用于在接收程序中触发一个自动下载。 ZRQINIT 帧不发送任何数据子包。如果发送器试图发送一个命令给接收器，头字节 ZF0 包含常量 ZCOMMAND（这个特性应用例不支持） ；否则它包含一个 0。& ZRINIT＝0: 接收器发送这种帧以指明它准备好从发送器处接收文件。可以自发地发送它，或者应答 ZRQINIT 帧。这个帧具有 4 个字节地能力信息包装在报头中。ZF0 和 ZF1 的下列位可以进行设置和清除，这要取决于接收器的能力。& CANFDX＝1: 接收器具有确实的全双工操作，意味着它可以同时发送和接收数据。 CANOVIO＝2:接收器在写磁盘时可以接收数据，要充分利用ZMODEM 的流特性，就需要这种能力。& CANBRK＝4: 接收器可以发送一个中断信号。 CANCRY＝8: 接收器可以解码RLE帧。 应用例中不支持这种能力 （Omem& 可能把这种能力看做对 ZMODEM 的专有扩展） 。& CANLZW＝16: 接收器可以解压缩 UNIX压缩式的数据。这种能力在应用例中不支持。& CANFC32＝64: 接收器可以接受 CRC32，应用例不支持 CRC32。& ESCCTL=64:& 接收器需要看到所有控制字符转换码，而不是仅 XON/XOFF 等少数几个。 ZF2和 ZF3包含接收器输入缓冲的尺寸。 如果这个值是非零的就意味着接收器不能在完全的流模式中工作。相反，当它向磁盘写数据时，它将停止接收。& ZSINIT＝2：& 在处理ZRINIT 帧后，这个帧可以被发送器有选择地发送给接收器。它提供给接收器一些信息而不管接收器的能力。两个位装入 ZF0。 TESCCTL＝64: 此位用于指明发送器期望所有控制字符都进行转换。& TESC8＝128:& 此位用于指明发送器期望转换 8 位。ZMODEM 没有完全实现这种能力，但包含在未来改进的规范中。 仅有一个数据子包跟随在报头后面。这个子包包含不超过 32 个字符的字符串，以空字符终止。这个字符串用于在出错时唤醒发送器。& ZACK＝3: 这种帧类型用于确认 ZSINT 和 ZCHALLENGE 帧，以及其后跟随 ZCRCQ 或ZCRCW 终止符的数据子包。如果应答是给 ZCHALLENGE 帧的，4 个报头标志字节由ZCHALLENGE报头所发送的 4 个字节副本来填充。& ZFILE＝4: 这种帧类型用于初始化实际的文件传输。它包含一个报头，后面跟随单个数据子包，子包包含文件信息。4 个报头字节中填入了与要传输文件有关的各种标志。ZF0 包含文件转换选项；ZF1 包含可选的管理选项；ZF2 具有传输选项；ZF3 包含扩充选项。 这个帧考虑的选项最多，而且很少使用。对于我们的目的，在 ZFILE帧中传送的重要项是文件名称、长度及可选的日期。在此详细说明选项的其余部分是为了完整性。
ZSKIP＝5: 这是一个简单的帧，当接收器选择不接收发送器的 ZFILE帧制定的文件时，就发送这个帧。它在 4 个报头字节中没有存储数据，且不发送任何数据子包。 ZNAK＝6: 用于指明最后的报头由于许多原因是非法的。 ZABORT＝7: 接收器发送这个帧以指明会话将终止。 通常发送这个帧响应用户发出的取消操作。 ZFIN＝8: 当发送器再没有文件传送时发送这个帧。 接收器在退出前以它自己的ZFIN帧回答。ZMODEM 规范的特别之处是， 在接收由接收器发送的 ZFIN 之后， 是发送器发两个字符 （00） 。&& ZRPOS＝9: 接收程序在任何时候都可以发送这个帧。4 个字节的偏移填充到报头信息的 4字节中。偏移量是接收器从文件的某个位置开始发送数据的请求。若要进行恢复，或在传输期间在到来的数据流中检测到错误，可在文件传输开始时发送这个帧。& ZDATA＝10: 这个帧的 4 个报头字节包含跟随数据文件偏移量。可跟随任意个数据子包。& ZEOF＝11: 这指明所有文件数据都已经发送了。4 个报头字节包含 EOF 的偏移量。这个选项增加了协议的可靠性，以免目标文件上过早出现 EOF 的可能性。& ZFERR＝12: 如果在访问文件时发生错误，发送器或接收器都可以发送这个帧。接收这个帧字节使会话终止。& ZCRC＝13: 接收器发送这个帧，对用 ZFILE 帧指明的文件请求 32 位 CRC。发送器发送这个帧，使 CRC32 包装到 4 个报头字节中。& ZCHALLENGE＝14:发送器使用这个帧测试质询接收器。把随即数包装到报头的4 字节数据中。然后接收器负责回送相同的4 个数字到另一个 ZCHALLENGE帧。这个帧类型用于帮助防止未经接收器统一就把文件恶意下载到系统中。& ZCOMPL＝15: 当 ZCOMMAND 请求完成时接收器发送这个帧。4 个报头字节包含命令返回的状态码。& ZCAN＝16: 至少 5 个 CAN，请求临时的接收传送。& ZFREECNT＝17: 发送器可以向接收器请求默认卷上可用的空间的计数。 接收器用 ZACK 帧响应，它以字节为单位，并使空闲空间数量包装到 4 个报头直接中。& ZCOMMAND＝18: 这个帧为发送器提供把命令发送到接收系统的能力。 如果ZF0设置为0，接收器执行命令并在完成时返回 ZCOMPL 帧。如果 ZF0 设置为 ZCACK1，接收器立即返回ZCOMPL 包。 1.3.1 ZF0 转换选项 ZF0 可以设置为下列值之一，它们指明存储文件数据时使用的转换方法。& ZCBIN＝1: 二进制传输，数据不需要转换。& ZCNL＝2: 使用本地约定转换接收行的结尾。 这个选项在UNIX和MS－DOS之间发送ASCII文件是有用的。& ZCRESUM＝3: 从中断的文件传输中恢复。 接收器检查目标文件是否比发送的文件短。 若是，文件传输可在异常终止的地方重新开始。
1.3.2 ZF1 管理选项& ZF1 可以设置为以下的数值。& ZMNEW＝1: 只有在源文件更新或更长时覆盖目标文件。& ZMCRC＝2: 对比源文件和目标文件的 CRC。如果数值相同，传输文件，否则跳过传输。& ZMAPND＝3: 把源文件追加到目标文件。& ZMCLOB＝4: 如果目标文件存在，则无条件的覆盖目标文件。& ZMSPARS＝5: 如果目标文件存在，只有文件比较新才覆盖目标文件。& ZMDIFF＝6: 如果目标文件存在，只有文件的长度或日期不同才覆盖目标文件。& ZMPROT＝7:& 这个选项与 ZMCLOB相对。 它告诉接收器只有在目标文件不存在时才传输文件。 1.3.3 ZF2 传输选项& ZF2 可以设置为以下的数值。& ZTLZW＝1: 要传输的数据经过 UNIX压缩程序压缩的。在应用例中不支持这个选项。& ZTRLE＝3: 数据是使用Run Length Encoding压缩的。 通过创建专用的RLE帧， 在ZMODEM后来的版本中，这部分规范被取代。 丢失的选项2属于 ZTCRYPT， 是在最初的 ZMODEM规范中定义， 但从未实现的加密选项。& 1.3.4 ZF3 扩展选项 ZF3 是位图，其中由条件的设置了扩充选项。在 ZMODEM 规范中定义的唯一选项是ZTSPARS 选项，它考虑到对“稀疏文件”的特殊处理。这个选项在 ZMODEM 规范中定义，但它很少得到过支持。 &1.3.5& 数据子包 跟随 ZFILE报头的数据子包包含将要传输的文件相关信息。下列字段在数据帧中是连续的：& Filename：& 文件名，是以空值终止的字符串。 Length：& 文件长度，以十六进制给出的 ASCII表示。 Data：&& UNIX格式的日期和时间。这表示自 1970 年 1 月 1 日开始、以秒为单位的当前的 &&&& 计数值。数值 0 用于指明日期是未知的。值是以十六进制给出的 ASCII表示。 Mode：&& 以 UNIX格式表示的文件模式位，同样是以 ASCII表示的实力欧进制值。对于从 &&& MS－DOS系统发送的文件，其模式设置为 0. S/N：&& 传输程序的序列号。 File left:&&& 要发送的剩余文件数。 Byte left：& 要发送的剩余字节总数。&&&文件名后面的各个字段是可选的。多数实现支持文件长度和日期，但一般不会之处更多的。这个字段使用分隔符好是特殊的位。文件名是以’\0’字符结束得，其余的字段是由空格分隔的。 1.4& 头格式 ZMODEM 帧是由报头以及可能跟随在数据子包流组成的。报头本身相对简单，它由 4 个基本成分： (1)& 报头类型字节，指明要使用 3 种可能报头类型中的那种类型。 (2)& 帧类型字节，指明要编码 18 种可能帧类型中的那种类型。 (3) 4 个数据字节。 (4)& 报头的 CRC &对于 ZMODEM 实现，报头由三种不同的变化。ZMODEM 报头可以编码为： (1)& 十六进制报头，仅使用可打印的字符对它编码。如果数据子包跟随这个报头，它们以二进制而不是十六进制。 (2) CRC16 二进制报头。为了更高效地使用带宽，跟随这个报头地数据子包也直接以二进制发送。 (3) CRC32 二进制报头。数据子包以二进制发送，使用 32 位 CRC 是为了可靠性。 &1.4.1& 十六进制报头 十六进制报头使用可以打印地字符传送，唯一的例外是 ZDLE 字符（^X 或 ASCII 的 24） 。格式是： ZPAD ZPAD ZDLE B FrameType ZF3 ZF2 ZF1 ZF0 CRC1 CRC2 CR LF XON &前面的ZPAD字符定义为’*’。为了检测帧的开始，接收器使用 ZPAD ZPAD ZDLE序列。字符 B用于表示十六进制报头。在B字符之后，在结尾的CR/LF/XON序列之前，所有字符都是十六进制编码的，这意味着每一个字节使用两个字符的可打印值，而不是纯二进制。 &在接收器响应发送器时，它完全使用十六进制报头。对于没有任何数据子包跟随着报头的任何帧，发送器也使用十六进制报头。当数据子包包含在帧中时，一般使用这两种形式的二进制报头。然而，即使在这种情形，若要求的话，发送器可以使用十六进制报头，这是以某种效率稍微降低作为代价的。 &当远程发送器开始 ZMODEM 传输时，它首先给接收器一个 ZRINIT 帧，要求一个 ZNIT帧。 1.4.2 CRC16 和 CRC32 二进制报头 十六进制报头不是发送数据的最高效的方法。为了更高效的包装信息，ZMODEM 发送器使
&用二进制报头。在二进制报头中，信息被包装为单个二进制字符而不是十六进制字符。 &两个报头的格式显示如下： 16 位：& ZPAD ZDLE A FrameType ZF3 ZF2 ZF1 ZF0 CRC1 CRC2 32 位：& ZPAD ZDLE C FrameType ZF3 ZF2 ZF1 ZF0 CRC1 CRC2 CRC3 CRC4 &32位 CRC 以某种效率的代价提供稍微高一些的可靠性。当数据子包跟随着报头时，子包的格式由报头的格式决定。跟随 16 位二进制报头（或者，还可能是十六进制报头）的数据子包将使用CRC16检查。跟随32 位二进制的数据子包将使用 CRC32 检查。只有接收器在 ZRINIT中发送CANFC32 位，才可以使用CRC32 报头。CRC16或 CRC32的值应用到帧类型和位置标志中。 1.5& 数据子包的格式 ZMODEM 取得它的最高效率在某些方面是依靠它发送数据子包的方法。紧跟着报头，ZMODEM 发送器想要发送多少数据子包可以发送多少个。数据子包由至多
个二进制字符组成，而某些字符经过编码，后面跟随一个 ZDLE和一个子包接收字符。 &有 4 种不同的子包结束字符，每个都有略微不同的目的。它们都指明 CRC16 或 CRC32 值将紧随其后。4 种不同字符还有其它意义：& ZCRCE（'h'） ：这个字符标志数据子包的结尾帧的结尾。当接收器在子包的结尾看到这个字符时，它就知道它需要开始查找下一个报头了。这个子包一般用在文件的结尾。& ZCRCG（' i'） ：这个字符终止当前子包，但指明至少还有一个子包跟随其后。接收器需要开始检查其后的 CRC 值，然后开始接收一个新的子包。 ZCRCQ（'j'） ：这个字符终止当前子包，但不终止帧。与 ZCRCE 不同，接收器必须多做一些事情，而不仅是校验子包校验值。此外，接收器发送一个 ZACK帧指明子包接收成功。发送器周期性的发送这个字符以迫使接收器响应。这有助于检测主动连接。& ZCRCW（'k'） ：这个字符以终止当前子包和帧。在检验 CRC 后，接收器可预期一个新的报头开始下一个帧。这个终止字符还指明接收器需要发送一个 ZACK以校验子包的接收。 &在正常的文件传输期间，ZMODEM 发送器仅能以一系列子包文件的方式发送整个文件，除了最后一个子包外，使用 ZCRCG 终止每个子包。最后的子包可以由 ZCRCE来终止，它使接收器确认整个帧的正确接收。在接收到 ZACK后，发送器保证所有数据都正确的接收。&&
所有这些帧均放到一起，以相对简单的方式完成文件传输。尽管 ZMODEM 在最低层是复杂的，但从高层的视点看，它具有吸引人的简单性。为了发送一个文件，只要求 9 个帧。每附加一个文件，仅对总帧数再增加 4 个帧。下表显示了进行可能最小的文件传输所必须的步骤。这个表仅仅考虑对于直接连接两个设备如何使 ZMODEM 运行，而且不会有高的出错率，也不会需要大缓冲区。 &最简单的 ZMODEM 文件传输显示如下：
以 ZCRCQ 结束子包引起的 ZACK 响应。可以使用这个响应来调整它自己的速度，以保证它不会超出接收器太远，方法在它发送另一个 ZCRCQ 接收的子包之前等待一个 ZACK。 &在读数据子包时若CRC发生错误，就发送附加帧。当发生错误时，接收器发送一个 ZRPOS帧，带有一个偏移量，来说明它想要发送器重新开始的地方。在发送 ZRPOS 帧后，接收器必须等到缓冲区中积累的数据被刷新。最终，新的 ZDATA帧开始，而它的位置应与最近的请求相匹配。&&
3.1& 软件说明 应用例程序部分主要实现 ZMODEM 的协议部分，完成文件的 Upload。底层协议的完成使用者可以不必了解，对数据存储，程序留出专门的函数，使用者仅仅需要编写使用者的存储数据的程序部分来存储 Upload 的数据。 3.2& 档案构成
3.3& 子程序说明 Spmc75_Zmodem_Init() 原&&& 形& void Spmc75_Zmodem_Init(void) 描&&& 述& 对 SPMC75F2413A的 UART 及 CMT0 初始化。 输入参数& 无 输出参数& 无 头 文 件& AN_SPMC75_0115.H 库 文 件& 无 注意事项& 默认使用 UART2 和 CMT0 例&& 子 1& Spmc75_Zmodem_Init(); //初始化 &ZmodemReceiveFile() 原&&& 形& int ZmodemReceiveFile(void) 描&&& 述& 使用 ZMODEM 协议接收文件。 输入参数& 无 输出参数& 状态信息 & 0=OK ；－1=ERROR ； -4＝NOWAKE 头 文 件& AN_SPMC75_0115.H 库 文 件& 无 注意事项& 完成文件的接收 例&&& 子& err = ZmodemReceiveFile();& //接收文件&&File_SaveToMemory() 原&&& 形& UInt16 File_SaveToMemory(char *ptrdat, UInt16 length)； 描&&& 述& 存储接收来的数据到中。 输入参数& Ptrdat：存储接收来的缓存数据块的首址 & Length：数据快的长度 输出参数& 存储数据是否成功 & OK＝0; ERROR＝－1 头 文 件& AN_SPMC75_0115.H 库 文 件& 无 注意事项& 这个函数时使用者来决定数据储存的函数，对于不同的使用可能有不同的存储介质，所以需要使用着来填充着部分程序，完成数据的存储。 注意：存储没有问题则必须返回 OK＝0，否则返回 ERROR＝－1。 这个函数在协议实现中调用。 例&&& 子& 无 OpenInputFile() 原&&& 形& UInt16 OpenInputFile(char *ptrstr); 描&&& 述& 函数在协议实现的过程中接受到 ZFILE帧后调用，这时可以得到发送文件的文件名,长度,修改日期...。使用则可以自行编写程序了解信息，作出处理。输入参数& Ptrstr：ZFILE数据帧的内容。 输出参数& 无 头 文 件& AN_SPMC75_0115.H 库 文 件& 无 注意事项& 协议实现的过程中需要调用的一个内部函数，使用者可以修改来了解传输文件的一些重要信息。不做任何处理将忽略 ZFILE数据帧所提供的信息。 例&&& 子& 无
4.1& 范例程序 示范性程序很简单，对于协议的实现可以不必关心。 //==================================================================== #include "AN_SPMC75_0115.H" //==================================================================== main() { &int err=0; & & Spmc75_Zmodem_Init();&&&&&&&&&&& //初始化 & err = ZmodemReceiveFile();&&&& //接收文件 &NOP(); &NOP(); &NOP(); &while(1); }&&
4.2& 数据存储& 协议的底层可以不必关心，但是数据储存是使用者必须关心的。 //=============================================================& // ----Functi: File_SaveToMemory() // ------Syntax: UInt16 File_SaveToMemory(char *ptrdat, UInt16 length) // -Description: 存储接收到的数据 // -------Notes: 使用者自行编辑,用于存储接收来的数据 // --parameters: ptrdat:数据块的首指针, length:数据块的大小 // -----returns: 存储数据OK/ERROR,错误请返回ERROR. //============================================================= UInt16 File_SaveToMemory(char *ptrdat, UInt16 length) { &NOP(); &NOP(); &NOP(); &return(OK); }&&
对于提供的文件信息的处理可以忽略，也可以用以决定存储是否够用，对升级日期的维护和文件名的相关管理等。 //=============================================================& // ----Function: OpenInputFile() // ------Syntax: UInt16 OpenInputFile(char *ptrstr) // -Description: 接收文件的ZFILE包的解释函数,自行处理 // -------Notes: 数据包含接收文件的文件名,长度,修改日期... // --parameters: ZFILE包数据块的指针 // -----returns: 能否接收文件,OK/ERROR,错误请返回ERROR. //============================================================= UInt16 OpenInputFile(char *ptrstr) { /*------------------------------------- /*Note. /* 可以添加对updown文件的ZFILE报头的数据 /* 子包信息的解释程序. /*-----------------------------------*/ &return(OK); }
下面将介绍在使用过程中和相关 ZMODEM 发送终端的连接。 1、 使用 PC 的超级终端的 ZMODEM 协议 Upload 数据，SPMC75F2413A来 Download 数据。 如图 5-1 所示，首先在 PC找到超级终端【开始】-&【程序】-&【附件】-&【通讯】-&【超级终端】 。&&&
2、 在打开超级终端后的对话框的提示下建立连接，如果使用 COM1 来通讯，则接下来对COM1的属性进行设置。在 SPMC75F2413A 接收程序中默认 UART 通讯的波特率为 19200BPS，其它的设置如图 5-2 所示。&&
3、 在【传送】中打开【发送文件】 ，在对话框中设置传输协议为Zmodem，在【浏览…】中找到需要传输的文件路径。如图 5-3 所示。&&
4、 确认发送，开始文件的传输，在传输的过程中显示传输的状态。如图 5-4 所示。&&
6 MCU使用资源
6.1 硬件使用资源说明
现在有1458人对本文发表评论
<form onsubmit="if(document.getElementById('content').value.length500){alert('评论不能少于三个字符，大于500个字符！');document.getElementById('content').focus();}" action="/common/comment_post.aspx" method="post">
Copyright & 2007- Corp.All Rights Reserved. 版权所有　经营许可证编号： 法律声明
维库电子旗下网站：维库电子市场网 | ChinaICMart | 维库电子开发网 | 维库电子人才网
总部：杭州市下城区朝晖路182号国都发展大厦1号楼80A
电话：9-8016 QQ： | MSN: |