单片机和计算机的串行通信.docx
《单片机和计算机的串行通信.docx》由会员分享，可在线阅读，更多相关《单片机和计算机的串行通信.docx（44页珍藏版）》请在冰豆网上搜索。
单片机和计算机的串行通信
数理与信息工程学院
课程设计
题目：
单片机和计算机的串行通信
专业：
班级：
姓名：
学号：
实验地点：
数理与信息工程学院电子系统设计室
指导老师：
成绩：
目录
一绪言……………………………………………………………………………1
二总体方案设计与比较…………………………………………………………1
三USB技术简介…………………………………………………………………3
四USB1.1协议……………………………………………………………………4
（一）位定序……………………………………………………………………4
（二）同步字段…………………………………………………………………4
（三）包字段格式………………………………………………………………4
（四）包格式……………………………………………………………………7
（五）事务格式…………………………………………………………………10
五基于CH371的USB串行通信软硬件电路的实现………………………………15
（一）硬件电路设计……………………………………………………………16
（二）软件设计…………………………………………………………………17
六激光多普勒血流计系统软件设计及软件容错设计…………………………20
（一）博弈技术（SoftwareSubgame）…………………………………………21
（二）冗余技术（SoftwareRedundancy）……………………………………25
七系统总体评价及改进措施……………………………………………………26
（一）运行的可靠性……………………………………………………………26
（二）系统扩展或改变的灵活性………………………………………………26
参考文献…………………………………………………………………………27
附录电路原理图…………………………………………………………………28
激光多普勒微循环检测仪USB接口的设计
一绪言
在当今社会疾病频繁发生的今天，对人体各功能的监测尤为重要。
基于社会迫切的需要，我们自制激光多普勒血流计。
利用其单片机内部的A/D转换器作为数据采集，为了使采集到的数字量放大到能使A/D准确采集05伏的电压，通过自动增益电路来实现自动调节。
采集到的数据通过积分电路调整合适积分常数一路送数码管显示，另一路利用串口把数据送到上位机在屏幕实时显示。
采用单总线通信协议格式，DS18B20温度传感器芯片对环境温度进行实时测量，从而实现对环境温度的实时测量。
由于仪器的核心是采用本系统单片机智能控制器及通信接口部分，可对测量数据进行各种计算（如数字滤波、数字调零、探头参数补偿、非线性校正等），从而排除或减少由于干扰信号和模拟电路引起的误差，大大提高了测量精度。
仪器的测量过程是对测量对象创伤非侵入的条件下进行的，因此具有安全、简单、迅速、无痛苦的优点。
对测量对象无电器接触，无精神刺激和其它生理效应，故监测是真实、安全而可靠的。
仪器采用LED显示（显示测量的微血管灌流量及环境温度的数值，使测量的数据准确直观）、直接测量方式工作、速度快、可进行即时瞬态相对量测量。
同时测量的数据与上位机通信，并在显示屏动态显示。
长时间监测并扫描全部测量过程。
一起采用薄膜键盘（仪器免办采用先进的触摸按钮，从而使仪器外表美观，结构简单，操作方便），外观美观，操作使用方便。
仪器中另一个重大突破是设计成功使用了先进的HE-NE激光管高稳定低噪声输出的激光管电源，它可使HE-NE激光管输出功率稳定度小于0.5%，噪声与通常的稳压电源相比可降低15dB，由于这一技术的成功使仪器的测量精度、稳定度、重复性得到很大提高。
仪器的光学系统也采用了先进的技术，从而使仪器调整更加方便，光导纤维采用干扰性好，传输效率高的进口优质塑料光纤，从而提高了仪器的可靠性。
随着计算机的广泛应用，我们迫切希望利用计算机对微区血流灌注流量进行实时监测。
我们利用一种新型USB通用总线接口芯片CH371实现了单片机和计算机的串行通信，利用计算机以及附加的数据采集模块设计一个灵活便捷的虚拟示波器能够满足大多数的工作、学习和开发需要，并且可以通过较低代价的硬件和软件升级实现相当复杂的信号处理功能。
医生通过虚拟示波器观测微区血流灌注流量就像看人的心跳一样，直接根据波形得出患者的病理特征。
二总体方案设计与比较
方案一:
采用PHILIPS公司开发的是纯粹的USB接口芯片PDIUSBD12，PDIUSBD12是PHILIPS在USB1.1协议设备端使用最多的芯片之一。
该芯片使用8位并行数据线连接到MCU，1位地址线用来区分写命令或读写数据。
它支持3个USB端点，内部集成了串行接口引擎（sin）、320字节的FIFO存储器、收发器和电压调整器。
它对外部MCU没有任何限制，现选择比较常用的80C51作为MCU对其进行控制。
其流程图如图2-1所示：
图1-1固件结构和数据流向流程图
方案二:
CH371是一种USB总线通用接口芯片。
该芯片具有8位数据总线以及读、写、片选控制线和中断输出，可以方便地挂接到单片机、DSP、MCU等控制器的系统总线上；在计算机系统中，通过CH371的配套软件可提供简洁易用的操作接口，从而使其与本地端的单片机通讯就如同读写硬盘中的文件一样简单。
由于CH371屏蔽了USB通讯中的所有协议，因而可在计算机应用层与本地端控制器之间提供端对端的连接。
在不需要了解任何USB协议或者固件程序甚于驱动程序的情况下，就可轻松地将并口、串口产品升级到USB接口。
其功能结构图如图2-2所示：
图1-2数据采集功能结构图
USB接口的开发以往都是一个令人头痛的问题，尽管很多设计者向往USB接口高速传输、自主供电、即插即用的优点，但较难逾越它的协议固件开发和驱动程序开发的障碍。
方案一中PDIUSBD12命令接口包括了对PDIUSBD12读写操作的所有命令．通过定义若干个子程序对应于各自不同的命令。
当固件中其它程序需要对PDIUSBD12进行读写时，需要进行相关的固体出现开发，对于初学者很难掌握由通信协议进行相关的协议固件开发和驱动程序开发。
方案二中CH371是一个USB总线的通用接口芯片，它利用硬件逻辑屏蔽了USB通讯中的所有协议，在计算机应用层与本地端控制器之间提供端对端的连接。
基于CH371，设计者不需要了解任何USB协议、固件程序以及驱动程序，可以轻松地将原来的并口、串口的产品升级到USB接口，以较低的风险和成本享用USB接口带来的优越性。
在本设计里，笔者选用了一款不需要开发协议固件和驱动程序的USB总线接口芯片。
综上所述，经周密论证，决定采用方案二。
三USB技术简介
USB是英文UniversalSerialBus的缩写，中文含义是“通用串行总线”。
它是一种应用在PC领域的新型接口技术。
自从1995年PC机带有USB接口，1998年USB接口逐步走进大规模实用阶段。
这几年，随着大量支持USB的个人电脑的普及，USB逐步成为PC机的标准接口已经是大势所趋。
在主机（host）端，最新推出的PC机几乎100%支持USB；而在外设（device）端，使用USB接口的设备也与日俱增，例如数码相机、扫描仪、游戏杆、磁带和软驱、图像设备、打印机、键盘、鼠标等等。
USB设备之所以会被大量应用，主要具有以下优点：
1.可以热插拔，告别“并口和串口先关机，将电缆接上，再开机”的动作。
2.系统总线供电，低功率设备无需外接电源，采用低功耗设备，并可提供5V/500mA电源。
3.支持设备众多，支持多种设备类，例如鼠标，键盘，打印机等。
4.扩展容易，可以连接多个设备，最多可扩127个。
5.高速数据传输，USB1.1是12Mb/s，USB2.0高达480Mb/S。
6.方便的设备互连，USBOTG支持点对点通信，例如数码相机和打印机直接互连，无需PC。
当然，USB设备也有其缺点，包括：
1.供电能力，如果外设的供电电流大于500mA时，设备必须外接电源。
2.传输距离，USB总线的连线长度最大为5m，即便是用HUB来扩展，最远也不超过30米。
USB规范：
USB的所有标准主要包括三部分：
USB基本规范，USB设备类规范和USBHOST控制器规范。
USB基本规范也就是USB1.0,USB1.1,USB2.0和USBOTG规范，如表3-1所示：
注意：
USBOTG作为USB2.0协议的补充，但并不意味着OTG芯片都支持高速传输，并且USBOTG的主要应用是在全速和低速。
本设计使用的芯片符合USB1.1协议。
下面是USB1.1协议简介。
表3-1USB主要协议版本
标准
说明
传输速度
发布日期
USB1.0
早期USB版本，主要应用在鼠标，键盘等HID设备
1.5Mbps
低速
1996-1-15
USB1.1
现在市场上大多数USB设备都采用1.1标准，应用领域非常广泛
12Mbps
全速
1998-9-23
USB2.0
现在主要应用高速数据采集场合，图像传输。
正在进一步普及
480Mbps
高速
2000-4-27
USB2.0OTG
作为USB2.0协议的补充，主要应用在点对点通信
480Mbps
2001-12-18
USB1.1OTG
作为USB2.0协议的补充，支持点对点通信
12Mbps
四USB1.1协议
从字段（Field）和包（Packet）的定义开始，由底向上地展示USB（UniveralSerialBus）协议。
接着是对不同事务（Transaction）类型的包事务格式的描述。
然后是链路层（Linklayer）流程控制（FlowControl）和事务级别的故障恢复（Faultrecovery）。
本章的最后将讨论复执同步化（Retrysynchronization），超时干扰（Babble）和总线活动丧失（Lossofbusactivity）的恢复。
（一）位定序
数据位被发送到总线的时候，首先最低有效位（LSb），跟着是下一个最低有效位，最后是最高有效位（MSb）。
在以后图表中的，包以下列形式给出，即包中单个的位和字段从左到右的顺序就是它们通过总线的顺序。
（二）同步字段
所有的包都从同步（SYNC）字段开始的，同步字段是产生最大的边缘转换密度（EdgeTransitionDensity）的编码序列。
同步字段作为空闲状态出现在总线上，后面跟着以NRZI编码的二进制串“KJKJKJKK”。
通过被定义为8位长的二进制串，输入电路以本地时钟对齐输入数据。
同步字段是用于同步的机制，在以后图表当中将不被表示。
同步字段里的最后的2位是同步字段结束的记号，并且标志了包标识符（PID-PacketIdentifer）的开始。
（三）包字段格式
在后面几节将描述标记，数据和握手包的字段格式。
包中位的定义是以未编码的数据格式给出。
为了清楚起见，在此不考虑NRZI编码和位填充（BitStuffing）的影响。
所有的包都分别有包开始（Start-of-Packet）和包结束（End-of-Packet）分隔符。
包开始（SOP）分隔符是同步字段的一部分，而包结束（EOP）分隔符用来表示包的终止。
1.包标识符字段
所有USB包的同步字段后都紧跟着包标识符（PID）。
如图4-1所示，包标识符由4位的包类型字段和其后的4位的校验字段构成。
包标识符指出了包的类型，并由此隐含地指出了包的格式和包上所用错误检测的类型。
包标识符的4位的校验字段可以保证包标识符译码的可靠性，这样包的余项也就能被正确地解释。
包标识符的校验字段通过对包类型字段的二进制的求反码产生的。
如果4个PID检验位不是它们的各自的包标识符位的补，则说明存在PID错。
图4-1PID格式
主机和所有功能部件都必须对得到全部PID字段实行完整的译码。
任何收到包标识符，如果含有失败的校验字段，或者经译码得到未定义的值，则该包标识符被假定是被损坏的，而且包的余项将被包接收机忽略（Ignore）。
如果一个功能部件（Function）收到了包含了它所不支持的事务类型或方向的合法包标识符，则不必应答。
例如，只能输入的端口（IN-onlyEndpoint）必须忽略输出标记（Token）。
表4-1列出了包标识符类型，编码及其描述。
包标识符被分为4个编码组：
标记，数据，握手和专用。
包标识符传送的前2位（PID<0：
1>）指出了其属于哪个组。
这说明包标识符编码的分布。
2.地址字段
功能部件端口使用2个字段：
功能部件地址字段和端口字段。
功能部件对地址和端口字段都需要进行译码。
不允许使用地址或端口别名（Aliasing），并且任何一个字段不匹配，此标记都必须被忽略。
另外，对未初始化的端口的访问将使得标记被忽略。
地址字段：
功能部件地址（ADDR）字段通过其地址指定功能部件，至于是数据包的发出地还是目的地，则取决于标记PID的值。
如图4-2所示，ADDR<6：
0>指定了总共128个地址。
地址字段被用于输入，建立和输出标记。
由定义可知，每个ADDR值都定义了单一的功能部件。
刚复位（Reset）和加电（Power-up）的时候，功能部件的地址默认值为零，并且必须由主机在枚举过程（EnumerationProcess）中编程。
表4-1PID类型
PID类型
PID名
PID[3:
0]
描述
标记
（Token）
输出（OUT）
输入（IN）
帧开始（SOF）
建立（SETUP）
0001B
1001B
0101B
1101B
在主机到功能部件的事务中有地址+端口号
在功能部件到主机的事务中有地址+端口号
帧开始标记和帧号
在主机到功能部件建立一个控制管道的事务中有地址+端口号
数据
（DATA）
数据0（DATA0）
数据1（DATA1）
0011B
1011B
偶数据包PID
奇数据包PID
握手（Handshake）
确认（ACK）
不确认（NAK）
停止（STALL）
0010B
1010B
1110B
接收器收到无措数据包；
接收设备部不能接收数据，或发送设备不能发送数据；
端口挂起，或一个控制管道请求不被支持。
专用
（Special）
前同步（PRE）
1100B
主机发送的前同步字。
打开到低速设备的下行总线通信。
图4-2地址字段
端口字段：
如图4-3所示，附加的4位的端口（ENDP）字段在功能部件需要一个以上端口时候允许更灵活的寻址。
除了端口地址0之外，端口个数是由功能部件决定的。
端口字段只对输入，建立和输出标记PID有定义。
所有的功能部件都必须在端口0提供一个控制管道。
对于低速（LowSpeed）设备，每个功能部件最多提供3个管道：
在端口0的控制管道加上2个附加管道。
全速（FullSpeed）功能部件可以支持最多可达16个的任何类型的端口。
图4-3端口字段
3.帧号字段
帧号字段是一个11位的字段，主机每过一帧就将其内容加一。
帧号字段达到其最大值7FFH时归零，且它仅每个帧最初时刻在SOF标记中被发送。
4.数据字段
数据字段可以在0到1,023字节之间变动，但必须是整数个字节。
图4-4为多字节显示格式。
每个字节的范围内的数据位移出时都是最低位（LSb）在前。
数据包大小随着传送类型而变化。
图4-4数据字段格式
5.循环冗余校验
循环冗余校验（CRC）被用来在标记和数据包中保护所有的非PID字段。
在上下文中，这些字段被认为是保护字段。
PID不在含有CRC的包的CRC校验范围内。
在位填充之前，在发送器中所有的CRC都由它们的各自的字段产生。
同样地，在填充位被去除之后，CRC在接收器中被译码。
标记和数据包的CRC可100%判断单位错和双位错。
失败的CRC指出了保护字段中至少有一个字段被损坏，并导致接收器忽略那些字段，且在大部分情况下忽略整个包。
为了CRC的发生和校检，发生器和检验器里的移位寄存器置成为全1（All-ones）型。
对于每个被发送或者被收到的数据位，当前余项的最高一位和数据位进行异或（XOR），然后，余项是左移1位，并且，最低一位置零。
如果异或的结果是1，余项和生成多项式作异或。
当检查的字段的最后的一位被发送的时候，发生器里的CRC被颠倒，再以最高位（MSb）在前发给检验器。
当检验器收到CRC的最后的一位,且不发生错误的时候，余项将等于多项式的的剩余。
如果剩余与包接收器中最后计算出的检验和余项（Checksumremainder）不匹配，则存在CRC误差。
对于CRC，必须满足位填充的要求，且如果前6位都是1的话，这包括在CRC的最后插入零。
标记CRC：
标记使用了5位的CRC字段，它覆盖了输入，建立和输出标记的ADDR和ENDP字段，或SOF标记的时间戳字段。
生成多项式如下：
这个多项式的二进制位组合是00101B。
如果所有的标记位都被准确无误地收到，接收机中的5位剩余将是01100B。
数据CRC：
数据CRC是作用于数据包的数据字段上的16位多项式。
产生的多项式是如下：
这个多项式的二进制位组合是1000000000000101B。
如果全部的数据和CRC位被准确无误地收到，16位剩余将是1000000000001101B。
（四）包格式
这节展示标记，数据和握手包的包格式。
这些图将以位被挪动到总线上的顺序显示包内的字段。
1.标记包
图4-5显示了标记包的字段格式。
标记由PID，ADDR和ENDP构成，其中PID指定了包是输入，输出还是建立类型。
对于输出和建立事务，地址和端口字段唯一地确定了接下来将收到数据包的端口。
对于输入事务的，这些字段唯一地确定了哪个端口应该传送数据包。
只有主机能发出标记包。
输入PID定义了从功能部件到主机的数据事务。
输出和建立PID定义了从主机到功能部件的数据事务。
图4-5标记包格式
如图4-5所示，标记包包括了覆盖地址和端口字段的5位CRC。
CRC并不覆盖PID,因为它有自己的校验字段。
标记和帧开始（SOF）包是由3个字节的包字段数据后面的包结束（EOP，EndofPacket）界定的。
如果包被译码为合法标记或SOF，但却没有在3个字节之后以EOP终止，则它被认为是无效的，并被接收器忽略。
2.帧开始（SOF,Start-of-Frame）包
主机以每1.00ms±0.0005ms一次的额定速率发出帧开始（SOF）包。
SOF包是由指示包类型的PID和其后的11位的帧号字段构成。
SOF标记组成了仅有标记的（token-only）事务，它以相对于每帧的开始精确计算的时间间隔发送SOF记号（Marker）和伴随的帧数。
包括集线器的所有全速功能部件都可收到SOF包。
SOF标记不会使得接收功能部件产生返回包；因此，不能保证向任何给定的功能部件发送的SOF都能被收到。
SOF包发送2个时间调配（Timing）信息。
当功能部件探测到SOF的PID的时候，它被告知发生SOF。
对帧时间敏感而不需要追踪帧数（例如集线器）的功能部件，仅需对SOF的PID译码；可忽略帧数和其CRC。
如果功能部件需要追踪帧数，它必须对PID和时间戳都进行译码。
对总线时间调配信息的没有特别需要的全速设备可以忽略SOF包。
3.数据包
如图4-6所示，数据包由PID，包括至少0个字节数据的数据区和CRC构成。
有2种类型的数据包，根据不同的PID：
DATA0和DATA1来识别。
2种数据包PID是为了支持数据切换同步（DataToggleSynchronization）而定义的。
图4-6数据包格式
数据必须以整数的字节数发出。
数据CRC仅通过对包中的数据字段计算而得到，而不包括PID，它有自己的校验字段。
4.握手包
如图4-7所示，握手包仅由PID构成。
握手包用来报告数据事务的状态，能还在表示数据成功接收，命令的接收或拒绝，流控制（FlowControl）和停止（Halt）条件。
只有支持流控制的事务类型才能返回握手信号。
握手总是在事务的握手时相（Phase）中被返回，也可在数据时相代替数据被返回。
握手包由1个字节的包字段后的EOP确定界限。
如果包被解读为合法的握手信号，但没有以1个字节后面的EOP终止，则它被认为是无效的，且被接收机忽
略。
图4-7握手包
有3种类型的握手包：
●ACK表示数据包没有位填充或数据字段上的CRC错，并且数据PID被正确收到。
ACK在下列的情况下被发放，当时序位（SequenceBit）匹配且接收器能接受数据的时候，或者当时序位失配，但发送方和接收器互相之间必须再同步（Resynchronize）的时候。
ACK握手信号只适用于数据被传送且期待握手信号的事务中。
对于输入事务，ACK由主机返回，而对于输出或建立事务则由功能部件返回；
●NAK表示功能部件不会从主机接受数据（对于输出事务），或者功能部件没有传输数据到主机（对于输入事务）。
NAK仅由功能部件在输入事务的数据时相返回，或在输出事务的握手时相返回。
主机决不能发出NAK。
出于流控制的目的，NAK用于表示功能部件暂时不能传输，或者接收数据，但是最终还是能够在不需主机干涉的情况下而传输或接收数据；
●STALL作为输入标记的回应，或者在输出事务的数据时相之后由功能部件返回（见图4-9和图4-13）。
STALL表示功能部件不能传输，或者接收数据，或者不支持一个控制管道请求。
在任何条件下都不允许主机返回STALL。
STALL握手由设备用于在两个不同的场合之一。
第一种情况，是当设置了与端口相联系挂起特征（Haltfeature）的时候，称为“功能STALL（functionalstall）”。
功能STALL的特殊情况是“命令STALL（commandedstall）”。
命令STALL发生在主机显式地设置了端口的挂起特征的时候。
如果功能部件的端口被挂起，则功能部件必须继续返回STALL，直到引起停止的条件通过主机干涉而被清除。
第二种情况称为“协议STALL（protocolstall）”。
协议STALL对于控制管道是唯一的。
协议STALL和功能STALL在意义和持续时间上是不同。
协议STALL在控制传送（ControlTransfer）的数据或状态阶段（Stage）被返回，并且，STALL条件在下一个控制传送的开始终止（建立事务）。
这节的剩下的部分将提到功能STALL的一般情况。
5.握手回答（HandshakeResponse）
传输和接收功能部件必须根据从表4-2中到表4-4详细叙述的优先顺序返回握手。
不是所有的握手都是被允许，依赖于事务类型和功能部件或主机是否发出握手。
如果标记在传输到功能部件的阶段里发生了错误，则功能部件将不以任何包回应，直到下一个标记被收到并成功地译码。
功能部件对输入事务回答：
表4-2显示了功能部件作为对输入标记的反应而可能做的回答。
如果由于停止或流控制条件,功能部件不能发送数据，它将发出STALL或NAK握手。
如果功能部件能发出数据，它就发出数据。
如果收到的标记被损坏，则功能部件不应答。
主机对输入事务回答：
表4-3显示了主机对输入事务回答。
主机只能返回1种类型的握手：
ACK。
如果主机收到了损坏的数据包，它把数据丢弃且不应答。
如果主机不能从功能部件接受数据，则（出于类似内部缓冲溢出的问题）这条件被认为是错误，并且主机不应答。
主机能接受数据，并且如果数据包是完整无错地被接收到，则主机接受数据并发出ACK握手。
表4-2功能部件对输入事务的回应
收到的标记损坏
功能部件的送
端口的挂起征
功能部件能
发送数据
采取的动作
是
升级会员 