usb协议05 USB数据流模型

第四章USB数据流模型 本章介绍了数据如何在USB中传送，将涉及到系统中关于信号的发送和协议定义的一层。 对于USB系统中这一层中各个定义的详细情况可参见第六章和第七章。本章中介绍的数据传送格式，将在第八章到第十一章中逐步扩充。所有的实现者必须阅读此章，以便了解USB中一些非常核心的概念。 4.1 实现者的视图 USB提供了在一台主机和若干台附属的USB设备之间的通信功能，从终端用户的角度看到的USB系统，可简单地用图4.1 表 关于同志近三年现实表现材料材料类招标技术评分表图表与交易pdf视力表打印pdf用图表说话 pdf 示： 图4—1 USB主机/设备的简单模型 但在实际的实现上，具体的系统要比这复杂，不同层次的实现者对USB的有不同要求，这使得我们必须从不同的层次观察USB系统。USB系统提出了一些重要的概念和情况来支持现代个人计算机所提出的可靠性要求，所以USB的分层理解是必须的。它能使不同层次的实现者只关心USB相关层次的特性功能细节，而不必掌握从硬件结构到软件系统的所有细节。USB的这种层次结构如图4-2所示， 主机 物理设备 实际通信流 逻辑通信流 需实现的区域 图4—2 USB需实现的区域 各层次的具体细节将在以后逐步介绍。特别地，有四个层次的实现是较为集中的。 ·USB物理设备(USB Physical Device)：USB上的一种硬件，可运行一些用户程序。 ·客户软件(client software)：为一个特定的USB设备而在主机上运行的软件。这种软件由USB设备的提供者提供，或由操作系统提供。 ·USB系统软件(USB system software)：此软件用于在特定的操作系统中支持USB，它由 操作系统提供。与具体的USB设备无关，也独立于客户软件。 ·USB主机控制器(USB Host Controller):总线在主机方面的接口，是软件和硬件的总和。用于支持USB设备通过USB连到主机上。 这四个USB系统的组成部分在功能上存在相互重叠的部分。为了支持主机与客户之间的坚 固可靠的通信，还需要在后面对这些部分进行细节性描述。 如图4-2所示，一台主机与一个USB设备间的连接是由许多层上的连接组成。USB总线接口层提供了在主机和设备之间的物理连接、发送连接、数据包连接。USB设备层对USB系统软件是可见的，系统软件基于它所见的设备层来完成对设备的一般的USB操作。应用层可以通过与之相配合的客户软件向主机提供一些额外的功能。USB设备层和应用层的通信是逻辑上的，对应于这些逻辑通信的实际物理通信由USB总线接口层来完成。 关于USB的物理通信在第5、6章中描述，而相关的逻辑通信在第8、9章中介绍。本章描述一些核心概念，USB系统的实现者必须先掌握它们，然后在往后几章中阅读更加详细的部分。 为了描述和管理USB通信，以下概念是很重要的： ·总线拓朴(Bus Topology)：USB的基本物理组成、基本逻辑组成，以及各组成部分之间 的相互关系。这将在4.2节中描述。 ·通信流模型(communication Flow Models):描述主机与设备如何通过USB通信，以及通信所用的四种通信类型。这将在4.3到4.8的各节中介绍。 ·总线访问管理(BUS Access)：主机面对大量的USB设备的各种通信要求，如何控制、协 调总线的访问。 ·关于同步传送的考虑：4.10节中将介绍。对要求同步传送的设备提供一些特性。非同步传送设备的实现者不必阅读此节。 4.2 总线拓朴 总线拓朴结构包括四个重要的组成部分。 ·主机和设备：USB系统的基础组成部分。 ·物理拓朴结构：描述USB系统中的各组成部分是如何连接起来的。 ·逻辑拓朴结构：描述USB系统中各种组成部分的地位和作用，以及描述从主机和设备的角度观察到的USB系统。 ·客户软件层与应用层的关系：描述从客户软件层看到的应用层的情况，以及从应用层看到的客户软件层的情况。 4.2.1 USB主机 主机的逻辑结构如图4-3，包括 ·USB主机控制器（USB Host Controller） ·USB系统软件集合：USB驱动程序，主机控制器的驱动程序，主机软件 ·客户软件 主机 实际通信流 逻辑通信流 图4—3 主机的组成 USB主机在USB系统中是一个起协调作用的实体，它不仅占有特殊的物理位置，而且对于USB以及连到USB上的设备来说，还负有特殊责任。主机控制所有的对USB的访问。一个USB设备想要访问总线必须由主机给予它使用权。主机还负责监督USB的拓朴结构。 关于主机和它的任务的更详细、更彻底的描述，请见第9章。 4.2.2 USB设备 一个USB设备的逻辑结构如图4.4所示，包括 ·USB总线接口 ·USB逻辑设备 ·应用层 物理设备 实际通信流 逻辑通信流 图4-4 物理设备组成 USB设备用于向主机提供一些额外的功能。USB设备提供的功能是多种多样的，但面向主机的接口却是一致的。所以，对于所有这些设备，主机可以用同样的方式来管理它们与USB有关的部分。 为了帮助主机辨认及确定USB设备，这些设备本身需要提供用于确认的信息。在某一些方面的信息，所有设备都是一样的；而另一些方面的信息，由这些设备具体的功能决定。信息的具体格式是不定的，由设备所处的设备级决定。 对USB设备更完备的描述，见第8章。 4．2．3 总线的物理拓朴结构 USB系统中的设备与主机的连接方式采用的是星形连接，如图4-5。 根HUB HUB HUB 图4—5 USB物理总线的拓扑 图中的Hub是一类特殊的USB设备，它是一组USB的连接点，主机中有一个被嵌入的Hub叫根Hub(root Hub)。主机通过根Hub提供若干个连接点。为了防止环状连接，采用星形连接来体现层次性，如图4-5。这种连接的形状很像一棵树。 用于提供具体功能的设备叫应用设备。许多不同功能的设备放在一起被看作一个整体，叫包。例如，键盘和轨迹球可以被视作一个整体，在它的内部，提供具体功能的设备被永久地 接到Hub上，而这个Hub被接到USB上。所有这些设备及这个Hub被看作一个复合设备，而这个Hub又被看作这个复合设备的内部Hub。在主机看来，这个复合设备和一个带着若干设备的单独Hub是一样的。图中也标出了一个复合设备。 4.2.4 总线逻辑拓朴结构 在物理结构上，设备通过Hub连到主机上。但在逻辑上，主机是直接与各个逻辑设备通信的，就好像它们是直接被连到主机上一样。这个逻辑关系如图4-6所示。与之对应的物理结构就是图4-5中的结构。Hub也是逻辑设备，但在图4-6中，为了简化起见，未被画出，虽然USB系统中的工作都是从逻辑角度来看待的，但主机必须对物理结构有个了解。例如，在处理Hub被移去的情况时，当一个Hub被移出，通过它与主机相连的设备也应一起被移去，这是由其物理结构决定的。关于Hub的更详细的讨论在第10章。 逻辑设备 主机 逻辑设备 逻辑设备 逻辑设备 逻辑设备 图4—6 USB逻辑总线的拓扑 4.2.5 客户软件层与应用层的关系 USB系统的物理上、逻辑上的拓朴结构反映了总线的共享性。操纵USB应用设备的客户软件只关心设备上与它相关的接口，客户软件必须通过USB软件编程接口来操纵应用设备。这与另一些总线如PCL，ELSA，PCMUA等不同，这些总线是直接访问内存或I/O的。在运行中，客户软件必须独立于USB上的其它设备。这样，设备和客户软件的设计者就可以只关心该设备与主机硬件的相互作用和主机软件的相互作用的细节问题。图4-7说明了在图4-6的逻辑结构下，一个设备设计者看到的客户软件与相应应用的关系的视图。 客户软件 客户软件 客户软件 应用 应用 应用 图4-7 客户软件和应用间的关系 4.3 USB通信流 USB是为主机软件和它的USB应用设备间的通信服务的，对客户与应用间不同的交互，USB设备对数据流有不同的要求。USB为此提供了更好的overall总线使用，它允许各种不同的数据流相互独立地进入一个USB设备。每种通信流都采取了某种总线访问方法来完成主机上的软件与设备之间的通信。每个通信都在设备上的某个端点结束。不同设备的不同端点用于区分不同的通信流。 图4-8是图4-2的扩充，它更详尽地描述了USB系统，支持了逻辑设备层和应用层间的通信。实际的通信流要经过好几个接口边界，从第5章到第7章，刻画了机械上、电气上以及协议上的USB接口的定义。第8章刻划了USB设备的编程接口。通过此接口，可从主机侧对USB设备进行控制，第9章介绍了两个主机侧的通信接口： ·主机控制器的驱动程序(HCD)：它位于USB主机控制器与USB系统软件之间。主机控制器可以有一系列不同的实现，而系统软件独立于任何一个具体实现。一个驱动程序可以支持不同的控制器，而不必特别了解这个具体的控制器。一个USB控制器的实现者必须提供一个支持它自己的控制器的主机控制器驱动器（HCD）实现。 ·USB驱动程序(USBD)：USB系统软件与客户软件之间的接口，提供给客户软件一些方便的使用USB设备的功能。 一个USB逻辑设备对USB系统来说就是一个端点集合。端点可以根据它们实现的接口来分类。USB系统软件通过一个缺省的控制通道来管理设备。而客户软件用通道束管理接口。通道束的一端为端点，一端为缓冲区。客户软件要求通信数据在主机上的一个缓冲和USB设备上 的一个端点之间进行。主机控制器或USB设备(取决于数据传送方向)将数据打包后在USB上传。由主机控制器(HC)协调何时用总线访问在USB上传递数据。 主机 连接 物理设备 到一个接 口的通道 束 与接口 无 缓冲 没有USB 有关 USB格式 格式 到0号端点的 缺省通道 事务 USB帧格式 每个端 USB帧 的数据 点的数 结构的 据 数据 USB 主机 （第10章） USB线路 机械的， 通道：两个水平实体之间连接 电气的， 的抽象。 协议 数据传递机制 （第6，7，8章） 被传递的数据的与USB相关的形式 图4-8 USB主机/设备的细节图 图4-9说明了数据如何在主机侧中的内存缓冲和设备中的端点中传送。在后面，将逐步介 绍端点、通道和通信流。 主机上的软件通过一系列的通信流与逻辑设备进行通信。这一系列的通信流是由USB设备 的软件和硬件设计者选择的，使设备能传送由USB提供的字符。 界面 图4-9 USB通信流 4.3.1 设备端点 一个端点是一个可唯一识别的USB设备的Portion，它是主机与设备间通信流的一个结束点。一系列相互独立的端点在一起构成了USB逻辑设备。每个逻辑设备有一个唯一的地址，这个地址是在设备连上主机时，由主机分配的，而设备中的每个端点在设备内部有唯一的端点号。这个端点号是在设备设计时被给定的。每个端点都是一个简单的连接点，或者支持数据流进设备，或者支持其流出设备，两者不可得兼。 一个端点的特性决定了它与客户软件进行的传送的类型。一个端点有以下特性： ·端点的总线访问频率要求 ·端点的总线延迟要求 ·端点的带宽要求 ·端点的端点号 ·对错误处理的要求 ·端点能接收或发送的包的最大长度 ·端点的传送类型(详见4.4节) ·端点与主机的数据传送方向 端点号不为0的端点在被设置前处于未知状态，是不能被主机访问的。 4.3.1 对0号端点的要求 所有USB设备都需要实现一个缺省的控制方法。这种方法将端点0作为输入端点，同时也将端点0作为输出端点。USB系统用这个缺省方法初始化及一般地使用逻辑设备(即设置此设备)。缺省控制通道（见4.3.2节）支持了对控制的传送(控制传送将在4.5中定义)，一旦设备接上，并加电，且又收到一个总线复位命令，端点0就是可访问的了。 4.3.1.2 对非0号端点的要求 设备可以有除0以外的其它端点，这取决于这些设备的实现。低速设备在0号输入及输出端点外，只能有2个额外的可选端点。而高速设备可具有的额外端点数仅受限于协议的定义(协议中规定，最多15个额外的输入端点和最多15个额外的输出端点)。 除缺省控制通道的缺省端点外，其它端点只有在设备被设置后才可使用，对设备的设置是设备设置过程(见第8章)的一部分。 4.3.2 通道 一个USB通道是设备上的一个端点和主机上软件之间的联系。体现了主机上缓存和端点间 传送数据的能力。 有两不同的且互斥的通道通信格式。 ·流(Stream)：指不具有USB定义的格式的数据流。 ·消息(Message)：指具有某种USB定义的格式的数据流。 USB不解释在通道中传送的数据的内容。消息通道要求数据组织成USB定义的格式，但它的内容，USB是不管的。 特别地，有下列概念与通道相关： ·对USB总线访问的申请(claim)，带宽的使用情况 ·传送类型 ·与通道相连的端点的特性，例如：端点的数据传送方向，最大数据净负荷区的长度。数据净负荷是指在总线处理事务（transaction）中，数据包中数据区的数据(总线处理事务见第7章)。由两个0号端点组成的通道叫缺省控制通道。一旦设备加电并复位后，此通道即可使用。其它通道只在设备被设置后才存在。USB系统软件在决定设备身份、设置要求和设置设备时使用缺省控制通道。当设备被设置后，这个设备的特定软件还可使用该通道。USB系统软件保留缺省控制通道的拥有权，协调其它客户软件对通道的使用。 一个客户软件一般都通过I/O请求包(IRP)来要求数据传送。然后，或者等待，或者当传送完成后被通知。IRP的细节是由操作系统来指定的。客户软件提出与设备上的端点建立某个方向的数据传送的请求，IRP就可简单地理解为这个请求。一个客户软件可以要求一个通道回送所有的IRP。当关于IRP的总线传送结束时，无论它是成功地完成，还是出现错误，客户软件都将获得通知说IRP完成了。 如果通道上没有正在传送的数据，也没有数据想使用此通道，这个通道就处于闲置状态。主机控制器对它不采取任何动作，也就是说，这个通道的端点会发现没有任何的总线动作是冲它而来的。只有当有数据在通道上时，该通道才能发现总线对它的动作。 如果一个非同步通道遇到一个迫使它给主机发STALL的情况(参见第7章)，或者在任一个IRP中发现3个总线错误。这个IRP将被中止。其它所有突出的IRP也一同被中止。通道不再接收任何IRP，直到客户软件从这个情况中恢复过来(恢复的方式取决于软件的实现)，而且承认这个中止或出现的错误，并发一个USBD Call来表明它已承认。一个合适的状态信息将通知客户软件IRP的结果———出错或中止。同步通道的运作在4.6中介绍。 一个IRP可能会需要多个数据净荷区来传递数据。这些数据区除最后一个外，都具有数据净荷区的最大长度，最后一个数据区包含了这个IRP中剩下的数据。(可参见关于传送类型的介绍，以获得更详细的了解)。对这样的一个IRP，短包(也就是说未达到最大长度的数据区)在数据输入时无法填完IRP数据缓冲区。这可能会有二种不同解释，它依赖于客户软件的情况： ·如果该客户软件可以接受变长的IRP，那么，IRP数据缓冲区未被填满，可以看作一个分限，说明一个IRP已成功结束，主机控制器可以准备接收下一个IRP了。 ·如果该客户软件只收定长的IRP。那么，我们认为发生了一个错误，这IRP将被中止，通道也会被阻塞，通道上的数据都中止。 因为对这两种情况，主机控制器会有不同的反应，而且采取何种 措施 《全国民用建筑工程设计技术措施》规划•建筑•景观全国民用建筑工程设计技术措施》规划•建筑•景观软件质量保证措施下载工地伤害及预防措施下载关于贯彻落实的具体措施 不由控制器决定，所以对每个IRP都必须说明客户软件的具体要求。 通道的端点可以用NAK信号来通知主机自己正忙，NAK不能作为向主机反还IRP的中止条件。在一个给定的IRP处理过程中，可以遇到任意多个NAK，NAK不构成错误。 4.3.2.1 流通道 流通道中的数据是流的形式，也就是该数据的内容不具有USB要求的结构。数据从流通道一端流进的顺序与它们从流通道另一端流出时的顺序是一样的，流通道中的通信流总是单方向的。 对于在流通道中传送的数据，USB认为它来自同一个客户。USB系统软件不能够提供使用同一流通道的多个客户的同步控制。在流通道中传送的数据遵循先进先出原则。 流管流只能连到一个固定号码的端点上，或者流进，或者流出。(这个号码是由协议层决定的)。而具有这个号码的另一个方向的端点可以被分配给其它流通道。 流通道支持同步传送，中断传送和批传送，这些在稍后的章节会进一步解释。 4.3.2.2 消息通道 消息通道与端点的关系同流通道与端点的关系是不同的。首先，主机向USB设备发出一个请求；接着，就是数据的传送；最后，是一个状态阶段。为了能够容纳请求/数据/状态的变化，消息通道要求数据有一个格式，此格式保证了命令能够被可靠地传送和确认。 消息通道允许双方向的信息流，虽然大多数的通信流是单方向的。特别地，缺省控制通道也 是一个消息通道。 USB系统软件不会让多个请求同时要求同一个消息通道。一个设备的每个消息通道在一个时间段内，只能为一个消息请求服务，多个客户软件可以通过缺省控制通道发出它们的请求，但这些请求到达设备的次序是按先进先出的原则的。设备可以在数据传送阶段和状态阶段控制信息流，这取决于这些设备与主机交互的能力(参见第7章)。正常情况下，在上一个消息未被处理完之前，是不能向消息通道发下一个消息的。但在有错误发生的情况下，主机会取消这次消息传送，并且不等设备将已收的数据处理完，就开始下一次的消息传送。在操作通道的软件看来，一个IRP中的错误，使这个IRP被取消，并且所有正排队等待的IRP一同也被取消。申请这个IRP的客户被通知IRP结束，且有出错提示。 消息通道后有两个相同号码的端点，一个用于输入，一个用于输出。两个号码必须相同。 消息通道支持控制传送，这将在4.5中进行介绍。 4.4 传送类型 USB通过通道在主机缓冲区与设备端点间传送数据。在消息通道中传递的数据具有USB定义的格式，它的数据净荷区中包含的数据允许具有设备指定的格式。USB要求任何在通道上传送的数据均被打包，数据的解释工作由客户软件和应用层软件负责。USB提供了多种数据格式，使之尽可能满足客户软件和应用软件的要求。一个IRP需要一个或多个总线处理事务来完成。 每个传送类型在以下的几个传送特征上会有不同： ·USB规定的数据格式 ·信息流的方向 ·数据净荷区的长度限制 ·总线访问的限制 ·延时的限制 ·出错处理 USB设备的设计者可以决定设备上每个端点的能力。一旦为这个端点建立了一个通道，这个通道的绝大多数传送特征也就固定下来了，一直到这个通道被取消为止。也有部分传送特征可以改变，对这样的特征，将会在介绍每个传送类型时作出说明。 USB定义了4种传送类型： ·控制传送：可靠的、非周期性的、由主机软件发起的请求或者回应的传送，通常用于命令事务和状态事务。 ·同步传送：在主机与设备之间的周期性的、连续的通信，一般用于传送与时间相关的信息。这种类型保留了将时间概念包含于数据中的能力。但这并不意味着，传送这样数据的时间总是很重要的，即传送并不一定很紧急。 ·中断传送：小规模数据的、低速的、固定延迟的传送。 ·批传送：非周期性的，大包的可靠的传送。典型地用于传送那些可以利用任何带宽的数据，而且这些数据当没有可用带宽时，可以容忍等待。 这些传送类型将在后面的四个大节中进行讨论。IRP的数据均放在数据包中的数据区被传送，这将在7.4.3中介绍。关于与具体传送类型有关的一些协议细节在第7章中介绍。 4.5 控制传送 控制传送允许访问一个设备的不同部分。控制传送用于支持在客户软件和它的应用之间的关于设置信息、命令信息、状态信息的传送。控制传送由以下几个事务组成：(1)建立联系，把请求信息从主机传到它的应用设备；(2)零个或多个数据传送事务，按照（1）事务中指明的方向传送数据；(3)状态信息回传。将状态信息从应用设备传到主机。当端点成功地完 成了被要求的操作时，回传的状态信息为“success”。7.2中将介绍控制传送的细节，例如， 什么样的包，什么样的总线事务和总线事务的顺序。而第8章将介绍USB定义的USB命令字。 USB设备必须实现缺省控制通道，并将它实现成一个消息通道。这个通道由USB系统软件使用。USB设备的确认信息、状态信息以及控制信息由该通道传送。如果需要的话，一个应用设备可以为端点实现额外的控制通道。 USB设备框架(见第8章)定义了标准的，设备级的或由销售商提供的请求，这些请求可操作设备的状态。USB设备框架又定义了一些描述器（descriptor），用于存放USB设备的各种信息。控制机制提供访问设备描述器和请求操作设备的机制。 控制传送只能通过消息通道进行。所以，使用控制传送的数据必须具有USB定义的数据格式(见4.5.1节)。 应用层和相应的客户软件不能为控制传送指定总线访问频率和带宽。这由USB系统软件从全局优化角度加以决定。USB系统软件会限制设备要求的访问频率和带宽，这些限制在4.5.3和4.5.4中介绍。 4.5.1 控制传送类型的数据格式 Setup包的数据格式属于一个命令集，这个集合能保证主机和设备之间正常通信。这个格式也允许一些销售商对设备命令的扩展。Setup包后的数据传送也具有USB定义的格式，除非这个数据是销售商提供的信息。回传的状态信息仍然具有USB定义的格式。7.5.8节和第8章将介绍控制传送的Setup定义和数据定义。 4.5.2 控制传送的方向 控制传送使用的是消息通道上的双向信息流。所以，一旦一个控制通道被确认之后，这个通道就使用了具有某个端点号的两个端点，一个输入，一个输出。 4.5.3 控制传送包的大小的限制 控制传送的端点决定了它所能接收或发送的最大数据净负荷区长度。USB为高速设备定义的最大数据净负荷区长度为8、16、32或64字节，低速设备的数据净负荷区的长度只能是8字节。Setup后的所有数据包都要遵守这个规定，这个规定是针对这些数据包中的数据净负荷区的，不包括包中的协议要求的额外信息，Setup包实际上也是8字节。控制通道(包括缺省控制通道)总是使用w Max Packet Size的值。 端点在自己的设置信息中 报告 软件系统测试报告下载sgs报告如何下载关于路面塌陷情况报告535n,sgs报告怎么下载竣工报告下载 自己允许的最大净负荷区长度。USB不要求数据净负荷区必须达到最大长度，当长度不够时，不必填充到最大长度。 主机控制器对高速设备的控制通道端点支持8、16、32、64字节的最大长度，对低速设备支持8字节的长度。它不能支持更大的或更小的其它长度。 对于缺省控制通道的最大数据区长度，USB系统软件要从设备描述器的头8个字节中读出，设备将这8个字节放在一个包中发出，其中的七个字包含了缺省通道的wMaxPacketSize。对其它的控制端点来说，USB系统软件在它们被设置后，获得此长度，然后USB系统软件就会保证数据净负荷区不会超长。另外，主机总是认为数据净负荷区的最大长度至少为8。 端点所传的数据净负荷区长度必须小于或等于其wMaxPacketSize(参见第8章)，当一个数据区不能容纳所传数据时，就分几个区来传。除最后一个区外，其它区都应达到最大长度。最后一区包含最后剩下的数据。 当端点做了以下两件事时，控制传送的数据阶段可被认为结束： ·已传了由Setup阶段指定的数据量。 ·传了一个数据包，它的长度为0或它的数据区长度小于最大长度。 数据阶段结束后，主机控制器进入状态阶段，而不是开始另一个数据传诵。如果它不这样做，端点会认为通道脱线而中止通道(通道脱线见4.3.2)。如果主机在状态阶段时，主机收到一个大于最大长度的数据区，那么请求这次传送的IRP将被中止。 当数据全部传完，主机与端点之间的控制传送的数据阶段结束。如果其间，端点收到了超过最大长度的数据区，它将中止通道。 4.5.4 控制传送的总线访问的限制 无论低速设备还是高速设备都可以使用控制通道。 端点没法指明控制通道对总线访问频率的要求。USB权衡所有控制通道的总线访问频率和正等待的IRP，从全局优化，提供一个“最佳”传送 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 。 USB要求数据帧中的一部分被留给控制传送使用。 ·如果被引发的控制传送(引发方式由实现决定)只用了数据帧的不到10%的时间，则剩余的时间留给批传送(参见4.8节)。 ·如果一个控制传送被引发又被中止，则它的中止可在本次的帧内，也可在以后的帧内。也就是说，引发和中止不必在同一个帧内。 ·如果留给控制传送的时间不够用，但恰好有一些同步和中断传送的帧时间未用，则主机控制器利用这些时间进行额外的控制传送。 ·如果对可用的帧时间有太多的控制传送在等待，那么就对它们进行排序然后传送。 ·如果各个控制传送申请的是不同的端点，主机控制器根据公平访问原则决定它们的访问顺序。公平访问原则的具体内容决定于主机控制器的实现。 ·如果一个控制传送事务频繁地被中止，不能认为给它的总线访问时间是不公平的。 这些要求使得控制传送一般可以在总线上进行规则地、最优化地传送。 对某个端点的控制传送的速率是可以变化的，USB系统软件控制这些离散的变化。端点和其客户软件不能想当然的认为其有一个固定的传送速率，端点可能发现在一帧内有零个或若干个传送。一个端点和它相应的客户软件可占用的总线时间会因为其它设备进入或退出系统或者本设备上的其它端点进入或退出系统而改变。 总线频率和帧定时决定于一个帧内可传送的控制传送的最大个数。在任一个USB系统内，一个帧内的8字节高速数据区须少于29个，8字节低速数据区须少于4个。表4-1是关于不同规格的高速的控制传送的情况，以及在一帧内可能的最大的传送数目。这张表有两个默认的前提，即控制传送有一个数据传送阶段而且这个数据传送阶段有一个长度为0状态阶段，表4-1还指出了出现两个数据区都达不到最大长度的情况，表中不包括用于管理的一些额外的位。 表4-1 高速控制传送限制 协议开销（46字节） （9 SYNC bytes, 9 PID bytes, 6 Endpoint+CRC bytes, 6 CRC bytes, 8 Setup data bytes, and a 7_byte interpacker delay(EOP, etc.)) 数据净荷区 最大带宽 （字节/秒） Frame带宽/传送 最大传送数 剩余字节 有用数据 字节/Frame 1 32000 3% 32 23 32 2 62000 3% 31 43 62 4 120000 3% 30 30 120 8 224000 4% 28 16 224 16 384000 4% 24 36 384 32 608000 5% 19 37 608 64 832000 7% 13 83 832 Max 1500000 1500 因为一个帧内只留10%的时间给非周期性传送，所以当一个系统的总线时间被排满的时候，这个系统内的所有控制传送只能去竞争每个帧内的三个控制传送名额。因为除了客户软件会要求控制传送外，USB系统要用控制传送来传送设置信息，所以对某个客户和它的应用就不能指望它们的控制传送像它们想的一样进行。主机控制器可以自由地决定如何将某个具体的控制传送在总线上进行，可以在一个帧内，也可以跨几个帧。一个端点可能发现一个控制传送的各个总线处理事务在同一帧内或分在几个不连续的帧内。由于具体实现的不同，主机控制器可能不能提供理论上的每帧的最大控制传送数目。 低速控制传送与高速控制传送都是竞争同样多的可用帧时间。低速控制传送只是要用更多的时间来传送罢了。表4-2列出了不同规格的低速包的情况，以及一帧内允许的最大包数。这张表同样没包括进管理用的开销。无论低速与高速，由于一个控制传送都由几个包组成，所以都可能要用几个帧才能完成传送。 表4-2低速控制传送限制 协议开销（46字节） 数据净荷区 最大带宽 字节/Frame Frame带宽/传送 最大传送数 剩余字节 有用数据 字节/Frame 1 3000 25% 3 46 3 2 6000 26% 3 43 6 4 12000 27% 3 37 12 8 24000 29% 3 25 24 Max 187500 187 4.5.5 控制传送的数据顺序 要进行控制传送，先要由主机向设备发一个总线建立（Setup）信息。它描述了控制访问的类型，设备将执行此控制访问。这个阶段之后，是零个或多个控制数据信息的传送，这是进行访问的具体信息。最后，由状态信息的传送来结束这次控制传送，允许端点将这次控传的状态回送给客户软件。这次控传完成之后，可以进行对这个端点的下一个控传，如4.5.4节所述，每次控传何时在总线上进行由主机控制器的具体实现决定。 在数据传送阶段和状态信息回传阶段，可能由于设备自身的原因，设备处于“忙”状态。此时端点可设法表明自己正忙(见第7、8章)，主机将试着在稍后时间重传一次。 如果在上一个控传结束之前，端点又收到一个总线建立信息，设备将结束现未完成的传送，转而处理新的控传。正常情况下，是不会早发总线建立信息的，不过当上一个控传因错误而被中止后，主机可发下一个控传的总线建立信息。在端点看来，这是在上一个控传结束前过早发出的。 一旦主机遇到一个引起中止的条件或检测到一个错误，端点可以通过接收下一个Setup包的 PID来恢复，也就是说，不一定必须从别的通道进行恢复。对于缺省控制通道，如果端点收不到Setup的 PID时，最终会要求设备复位来清除中止条件或错误条件。 在控传中，USB提供了强大的错误检测功能和错误恢复和重传功能。传送器和接收器可以保持阶段的同步，既关于他们在控传的哪个阶段这个问题上保持同步。并且以最小的代价恢复。接收器可以识别一个数据重传包或状态信息重传包，因为包中带有数据重传的指示。一个发送器可以通过对方给它发的握手信息确知它发的数据重送包和状态信息包已被成功接收，除了Setup包以外，协议可以将一个重送的包与原来的包区分开来，Setup包可以因为出错而重传，但无法说明此包是重传的，还是原来的。 4.6 同步传送 在非USB的环境下，同步传送意味着恒定速率、错误容忍(error-tolerant)的传送。在USB环境下，要求同步传送能提供以下几点： ·固定的延迟下，确保对USB带宽的访问。 ·只要数据能提供得上，就能保证通道上的恒定数据传送速度。 ·如果由于错误而造成传送失败，并不重传数据。 当USB同步传送类型被用来支持同步的源和目的时，使用这个传送类型的软件并不要求是同步的，4.10中将详细介绍USB上的同步数据的处理。 4.6.1 同步传送的数据格式 对于同步传送的通道(同步通道)，USB并不对数据格式做要求。 4.6.2 同步传送的方向 同步通道是一种流通道，所以是单方向的。在对端点的描述中指明了与它相连的通道的数据流方向。如果设备要同步的双向流的话，只好用两个同步通道，一个流进，一个流出。 4.6.3 同步传送中包的大小的限制 同步通道的端点确定了数据区的最大长度，USB在设置端点期间，使用这一个信息，看是否可在每帧内为最大长度的数据区留下足够的时间。如果可以，设置端点成功；否则，不成功。 USB系统软件可为一个控制传送的通道调整最大数据区长度，但无法为同步通道进行如此调整。在确定的USB设置下，同步通道要么被支持，要么不被支持。 USB限制了同步通道的最大数据区长度为1023字节，表4-3列出了不同规格的同步传送，以及一帧内可能的最大传送数。表中未包括管理开销的字节。 表4-3同步传送限制 协议开销（9 字节） （2 SYNC bytes, 2 PID bytes, 2 Endpoint+CRC bytes,2 CRC bytes, and a 1_byte interpacket delay) 数据净荷区 最大带宽 字节/秒 Frame带宽/传送 最大传送数 剩余字节 有用字节 字节/Frame 1 150000 1% 150 0 150 2 272000 1% 136 4 272 4 460000 1% 115 5 460 8 704000 1% 88 4 704 16 960000 2% 60 0 960 32 1152000 3% 36 24 1152 64 1280000 5% 20 40 1280 128 1280000 9% 10 130 1280 256 1280000 18% 5 175 1280 512 1024000 35% 2 458 1024 1023 1023000 69% 1 468 1023 Max 1500000 1500 并不是每一次的数据区都要达到最大长度。数据区的长度由发送者(客户软件或应用软件)决定，每次可以不同。USB可保证主机控制器看到的包有多长，在总线上传的包就有多长。数据的实际长度由发送者决定，可以小于早先协商好的最大长度。总线错误可以使接收者看到的长度比实际长度有了变化。但这些错误可被检测到。具体地讲，或者通过数据上的CRC码，或者让接收者预先知道实际应该的长度，以此进行检测。 4.6.4 同步传送的总线方向限制 只有高速设备可以使用同步方式。 USB设备要求一个帧内不能有超过90%的时间用于周期性传送(同步传送或中断传送)。 同步通道的端点描述自己的总线访问频率。所有的同步通道一般在一帧内传一个包(也就是说，1ms一个包)。但总线上的错误或者操作系统对客户软件调度上的延迟会造成一个帧内一个包也没有的情况。此时，设备将一个错误指示信息作为状态信息返回给客户软件。设备可以通过跟踪SOF（帧开始）信号来测到此类错误。如果两个SOF信号间无数据包，则出错。 总线频率和帧定时限制了一个帧内的同步传送的上限，在任何USB系统内，最多有150个单字节的数据区。但由于实现上的原因，主机控制器可能无法支持到理论上的最大传送数。 4.6.5 同步传送的数据顺序 同步传送不支持因总线错误而进行的重传。接收器可以判断是否发生了一个错误，低级的USB协议不允许有握手信号给同步通道的发送者。一般情况下，是可以有握手信号来通知发送者包是否被成功地接收。对于同步传送来说，定时比正确性和重传更重要。考虑到总线的错误率较低，协议就认为传送一般均能成功。同步接收者可以判断自己是否在一个帧内错过了一些数据，而且能知道丢失了多少数据。4.10节将有关于此的具体介绍。 因为没有用来指示引起中止的条件的握手信号，所以同步传送的端点从不途停止。虽然，错误信息可作为IRP的状态来报告，但同步通道不会因此停下。错误即使被查到，主机仍继续处理下一帧的数据。因为同步传送的协议不支持每次事务都进行握手，所以错误检测的功能可以相对弱一些。 4.7 中断传送 中断传送是为这样一类设备设计的，它们只传或收少量数据，而且并不经常进行传送，但它们有一个确定的服务周期，对中断传送有以下要求： ·通道的最大服务期得到保证。 ·由于错误而引起的重发在下一服务期进行。 4.7.1 中断传送的数据格式 USB对中断通道上的数据流格式无要求。 4.7.2 中断传送的方向 中断通道是一种流通道，所以是单向的。端点描述信息指明了通道的数据流方向。 4.7.3 中断传送对包的长度的限制 中断通道的端点决定自己能接收和发送的最大数据区长度，高速设备允许最大不超过64字节(或更少)的数据区，而低速设备只允许不超过8个(或更少)字的数据区，这个数字不包括协议要求的附加信息。USB并不需求所有的包都到最大长度。如果不到的话，不用加字节填充。 所有的主机控制器都要示支持高速设备的64字节数据区和低速设备的8字节(或更少)的最大数据区，对超过最大值的数据区则不要求支持。 USB系统软件设置中断通道的最大数据区长度。在设备设置期间，这一信息将被使用，只有此设置有效，这个数值是不会改变的。在设置有效期间，USB系统软件根据此数值来看分给这个通道的总线时间是否充分。如果充分，则通道建立，否则不建立。与控制通道不同，USB系统不为中断通道调整总线时间。所以对给定的USB系统，要么支持此通道，要么不支持。实际传送的数据区长度由发送器决定，可以小于最大长度。 端点所发的数据区中的数据长度不能超过端点的w Max Packet Size的值。而设备可以通过中断传送来传比此值多的数据。客户软件可以通过中断传送的IRP来接收这批数据，这个中断传送要求多个总线处理事务来完成，且要求每个事务后都有IRP完成的信号。可以设置一个缓冲区，它的长度为w Max Packet Size的整数倍，再加上一个零头。对需要的多个总线事务来说，除最后一个外，前面的事务都传递w Max Packet Size长度的包，后一个传剩下的零头。这些总线处理事务都在为通道建立的服务周期内进行。 如果一个中断传送要传的数据不能放在一个数据区中，就分几个区，前几个区都是最大长度，最后一个包含剩下的长度。当出现以下情况时，认为中断传送结束： ·已传的数据量恰好与期望的数据量同。 ·传了一个有一个数据区的包，此包的长度小于w Max Packet Size或传了一个长度为零的包。 如果一个中断传送完成，那么主机控制器结束当前的IRP，并开始下一个IRP。如果数据区的长度比预料的长，当前IRP中止，并且只有等到出错条件被确认且清除后，才能开始后面的IRP。 4.7.4 中断传送对总线访问的限制 高速设备和低速设备均可使用中断传送。 USB要求不能有多于90%的顺时间用于阶段传送(同步传送或中断传送)。 总线频率和帧的定时限制了一帧内能传的最大中断传送数。对任一USB系统来说，高速单字数据区少于108个，低速单字节数据区少于14个。由于实现上的原因，主机控制器不一定能够支持此理论上的上限。 表4-4列出了不同规格的高速中断传送的情况，以及一帧内可能的最大传送数。表4-5列的是对低速设备的相关情况。它们均不包括管理开销的字节。 表4-4 高速中断传送限制 协议开销（13 字节） （3 SYNC bytes, 3 PID bytes, 2 Endpoint+CRC bytes, 2 CRC bytes, and a 3_byte interpacket delay) 数据净荷区 最大带宽 （字节/秒） Frame带宽/传送 最大传送数 剩余字节 有用数据 字节/Frame 1 107000 1% 107 2 107 2 200000 1% 100 0 200 4 352000 1% 88 4 352 8 568000 1% 71 9 568 16 816000 2% 51 21 816 32 1056000 3% 33 15 1056 64 1216000 5% 19 37 1216 Max 1500000 1500 中断通道的端点可以指明它要求的总线访问周期。高速设备要求的时间周期可以1ms到255ms，而低速设备从10ms到255ms。在设置期间，USB系统软件根据它们的要求来决定一个服务周期长度。USB提供的服务周期长度可能比设备要求的要短些，但不会少于最短的1ms。客户软件和设备只能够确定两次传送之间的时间长度不会比要求的周期时间长。但如果传送中出现错误，那么周期时间必然要越界。当客户软件有一个中断传送的IRP时，端点只是被选中。如果总线轮到此中断传送使用时，没有IRP处于待发状态，则端点没有机会在此时间传数据，一旦一个IRP出现了，它的数据在下一个轮到它的时间时被发出。 表4-5 低速中断传送限制 协议开销（13字节） 数据净荷区 最大带宽 Frame带宽/传送 最大传送数 剩余字节 有用数据 字节/Frame 1 13000 7% 13 5 13 2 24000 8% 12 7 24 4 44000 9% 11 0 44 8 64000 11% 8 19 64 Max 187500 187 要在USB上进行中断传送，必须在每个周期对端口进行访问。主机无法知道何时一个端口准备好了一个中断传送，除非它访问这个端点，并同时请求一个中断传送，等待回答。如果端口无数据需要中断传送，就对其请求回送一个NAK信号。如果端口传送数据的会有中断情况发生，一定要用中断传送，以防中断产生时，客户软件误以为IRP结束。长度为0的数据净负荷区的传送是合法的，而且对某些实现是很有用的。 4.7.5 中断传送的数据顺序 中断传送可以利用0/1跳变位（toggle位）的机制，当成功的进行了一个传送，该位就跳变一次。 主机总是认为设备是遵守完备的握手协议和重发协议(参见第7章)。但如果无论传送成功否，设备都在Data1/Data 0间跳变 PID，就忽略主机发来的握手信号。但这时，客户软件会丢失一些包。因为有错误发生时，主机控制器会把设备发的下一个包当作上一个包的重发。 一旦在中断通道上检测到一个引起中止的条件，或收到设备发来的STALL握手信号，所有正等待的IRP都会中止。由软件通过独立的控制通道来消除中止条件。清除后，设备和主机都复位到Data 0的状态。如果总线上出现了一个影响传送的错误，则中断处理事务会停止。 4.8 批传送 为了支持在某些在不确定的时间进行的相当大量的数据通信，于是设计了批传送类型。它可以利用任何可获得的带宽。批传送有以下几点特性： ·以可获得带宽访问总线。 ·如果总线出现错误，传送失败，可进行重发。 ·可以保证数据必被传送，但不保证传送的带宽和延迟。 只当有可获得的带宽时，批传送才会发生。如果USB有较多的空闲带宽，则批传送发生地相对频繁，如果空闲带宽较少，可能有很长时间没有批传送发生。 4.8.1 批传送的数据格式 USB没有规定批通道上数据流的格式。 4.8.2 批传送的方向 批通道是一种流通道，所以总是单方向的。如果要进行双向传送，必须用两个通道。 4.8.3 批传送对包长度的限制 批传送的端点决定自己可以接收或传送的最大数据净负荷区长度。USB规定最大的批数据净负荷区的长度为8、16、32或64字节。这个最大长度是指数据包中数据区的最大长度，不包括协议要求的一些管理信息。 批端点必须支持规定的最大长度中的一个，这个长度将在端点的设置信息中说明。USB并不要求每个数据净负荷区都达到最大长度，即如果不够长度的话，不必填充至最大长度。 所有主机控制器必须分别支持8、16、32或64作为最大长度，而对更大或更小的长度可以不必支持。 在设备设置期间，USB系统软件读取端点的最大数据净负荷区长度，以保证以后传送的数据净负荷区不会超长。 端点传送数据区的包不能超过端点的w Max Packet Size的值。如果一个批传送的IRP要传送的数据大于一个数据区的最大长度，那么要分几个数据净负荷区来传，除最后一个区外，前几个都达到最大长度。而最后一个包含剩下的数据。如果出现以下情况，则认为批传送结束： ·已传的数据量恰好等于期望传送的量。 ·传了一个不到w Max Packet Size长度的包或传了一个长度为0的包。 一旦批传送结束，主机控制器中止当前的IRP，并开始下一个IRP。如果收到的一个数据净负荷区超长，则所有在等待此端点的批传送IRP都将被中止/取消。 4.8.4 批传送对总线访问的限制 只有高速设备可以使用批传送。 端点无法提出对批通道的总线访问频率的要求。USB会协调所有批传送和正等待的IRP的总线访问请求，以获得在客户软件和应用层之间的“最佳”传送效果。总线上的控制传送的优先级比批传送高。 对于控制传送，有可保证的传送时间，而对批传送，没有。只有当有可用的总线带宽时，批传送才发生。如果有段时间没有被用于其他目的，这段时间将用于批传送。如果正等待的各个批传送是要往不同的端点去的，主机控制器将根据公平访问原则，安排它们的顺序。至于公平访问原则的具体内容，由主机控制器的实现决定。 系统中的所有批传送是竞争同一个可用的总线时间的，所以USB系统软件可以改变对某个特定端点进行的批传送所占有的总线时间。所以端点和它的客户软件不能够期望有一个特定的批传送的速度。当有设备被加进或移出USB系统或出现对其它设备上端点的请求时，端点和它的客户软件可获得的总线时间将起一定变化。但客户软件不能主观地认为批传送与控制传送的顺序，有时，批传送会在控制传送之前进行。 总线频率和帧定时限定了在一帧内可进行的最大批处理事务的数量，即一帧内8字节数据净负荷区须少于72个，表4-6列出了不同规格的批处理事务的情况，以及一帧内可能的最大的事务数。数据中不包括管理开销的字节。 表4-6批传送限制 协议开销（13字节） （3 SYNC bytes, 3 PID bytes, 2 Endpoint+CRC bytes, 2 CRC bytes and a 3_byte interpacker delay) 数据净荷区 最大带宽 Frame带宽/传送 最大传送数 剩余字节 有用数据 字节/Frame 1 107000 1% 107 2 107 2 200000 1% 100 0 200 4 352000 1% 88 4 352 8 568000 1% 71 9 568 16 816000 2% 51 21 816 32 1056000 3% 33 15 1056 64 1216000 5% 19 37 1216 Max 1500000 1500 对于某个批传送，主机控制器可以自由地决定它们的各个事务在某帧或某几个帧中被传送。端点可能在一帧内看到某个批传送的各个事务，或发现它们跨几个不同的帧。由于实现上的原因，主机控制器可能无法支持到理论上的每帧最大事务数。 4.8.5 批传送的数据顺序 批传送利用toggle位机制来保证接收器和发送器同步，即使在有错发生的情况下，也是如此。当端点被适当的控制传送设置过后，批传送被初始定位在DATA0，主机也将从DATA0开始第一个批传送。如果传送错误而导致出现一个能引起中止的条件或设备发了一个STALL握手信号，所有等待的IRP将被取消。软件通过一个独立的控制通道来清除中止条件，恢复之后，主机和设备的数据toggle都被定位在DATA0。 如果出现了一个影响事务的总线错误，批传送将被中止。 4.9 传送的总线访问 要完成主机与USB设备间的任何数据传送，必须要使用一定的USB带宽。要想支持从同步设备到异步设备的各种传送，必须要能满足它们对传送的不同要求。分配总线带宽给设备的工作叫做传送管理。主机上有几个部分是用于协调USB上的信息流的，它们是：客户软件、USB驱动器（USBD）和主机控制器驱动器（HCD）。实现这些部件必须要了解关于总线访问的一些核心概念： ·传送管理：用于支持USB上信息流的各实体和各对象 ·事务跟踪：一种USB机制，跟踪在USB系统中的事务 ·总线时间：总线传一个信息包的时间 ·设备/软件缓冲区大小：支持一个事务所需要的空间。 ·总线带宽归还：被分配给其它传送的总线带宽未被使用时，可以重新给控制传送和批传送使用。 前几节主要着重于客户软件如何与它的应用层进行联系和什么是两实体之间的逻辑流。这节介绍主机上的不同部分如何相互协调工作来支持USB上的数据传送，对设备实现者来说，这个信息也是有用的，他们可以由此知道当客户请求传送时主机该做什么，以及传送请求是如何被发给设备的。 4.9.1 传送管理 传送管理涉及以下几个为不同目标工作的部分，它们共同工作使数据能在总线上传送： ·客户软件：通过对USBD界面发出调用（calls）和响应调用（calls backs）的IRP请求，消费从应用端点来的数据或生产到消费端点去的数据。 ·USBD(USB驱动器)：通过对合适的主机控制器驱动器(HCD)的调用（calls）和响应调用（callbacks），将从设备端点来的或到设备端点去的IRP中的数据进行一定转换。一个客户IRP可能会需要几个传送来完成。 ·主机控制器驱动器(HCD)：将IRP转换成事务或将事务转换成IRP(按照主机控制器的要求)，并对它们进行组织，以使主机控制器进行操作。HCD和它的硬件间的互相作用与它的实现有关，不在USB说明的范围内。 ·主机控制器：进行事务，为每个事务在总线上通过包传送数据。 图4-10说明了当在客户软件和USB间有信息流动时，这些部分是如何工作的。它们之间的界面是我们了解的目标。 USBD界面 HCD界面 事务表 图4-10 从客户软件到总线的USB信息转换 4.9.1.1 客户软件 客户软件决定某个应用应该用何种传送类型。它通过操作系统指定的界面来请求IRP。客户软件知道它用来操作应用的通道(接口)的存在；客户知道总线访问和带宽的限制，并且遵守它们。客户软件将自己的请求发给USB驱动器接口。 有些客户通过操作系统提供的另一些设备级接口来操作USB功能，而不直接进行USBD的调用（calls）。但总要有一些低级的客户进行直接的USBD 的调用（calls），以便将IRP传给USBD。所有这些提交的IRP必须遵守通道建立时定下的带宽限制。如果一个设备从一个非USB环境进入USB，客户软件将通过主存和I/O访问直接操作这个设备的硬件。USB系统中的最低级的客户软件和USBD相互作用，来操纵USBD的USB功能。 当客户软件要求一个与它的应用层间的数据传送，而且又被满足后，客户软件将收到一个关于IRP完成状态的通知。如果传送中有应用层到主机的数据，客户软件收到IRP完成的通知后，可在数据缓冲区中取到所要的数据。 USBD的接口在第9章中介绍。 4.9.1.2 USB驱动器(USBD) USBD将在两个主要的时间介入总线访问： ·在设备接上主机的设置期间 ·在正常传送中 当设备被接上，并被设置时，USBD将确认设备的设置是否与总线兼容，USBD从设置软件处获得设置请求，它描述了要进行的设置：端点、传送类型、传送周期、数据长度等。USBD根据可用带宽的大小以及总线是否与请求的类型兼容来决定接受还是不接受这个设置。如果接收，USBD就为请求者建立一个相应类型的通道，自然也带有这个传送类型所应有的各种限制。在设备设置期间，不一定必须为周期性的端点作带宽分配。做过的带宽分配也可以放弃，而并不影响设备的设置。 对USBD的设置是典型地由操作系统决定的，而且反过来影响操作系统的设置特征。这样做可免除一些多余的接口。 一旦设备被设置，客户软件就可以通过IRP来请求与应用端点进行数据传送。 4.9.1.3 主机控制器驱动器(HCD) HCD负责跟踪IRP，并确保USB带宽和帧最大时间不被突破。当有IRP要求通道时，HCD将它们加入事务表中，当IRP结束，HCD将把它的完成状态通报给发它的客户软件，如果IRP中涉及应用设备向主机的传送，来的数据将被放在客户指定的数据缓存中。 IRP的定义依靠于一定的操作系统。 4.9.1.4 事务表 事务表描述了当前需要被做的事务。它与HC（主机控制器）的实现有关。只有HCD和它的HC可以访问这些特殊的描述。这些描述包括了事务的各种参数。例如，数据长度(字节)。设备地址、端点号，以及发出数据和存放收到数据的主存区域。 事务表和HCD与HC间的接口是依赖于实现的，不能作为USB说明的一个部分而作出明确的定义。 4.9.1.5 主机控制器(HC) HC可以访问事务表，并根据此表引起总线的动作。特别地，HC提供的报告机制使事务的状态(完成、等待、中止等)是可以知道的。HC将事务变成相应的总线动作(这种转换依赖于具体的实现)，这些动作又引起了在以根 Hub为根的总线拓朴结构上的USB包的传递。 HC可以保证协议规定的对总线访问的限制都被遵守了，例如：包间时限、超时等，HCD的接口向HC提供了参与决定是否允许一个新的通道访问总线的途径。这是因为HC的实现中有对两个事务间最小间隔的限制，这种限制支持了总线事务的组合。 事务表与HC的接口是被隐藏在HCD和HC的实现中的。 4.9.2 事务的跟踪 USB应用设备看到的总线上的数据是放在包中的。(参见第7章)。HC利用某种与实现有关的表示方法来跟踪包，跟踪的信息包括这个包是什么包，到哪个端点去/从哪个端点来，在什么时间传送，有什么顺序。绝大多数客户软件不愿直接与被打了包的数据流打交道，因为这造成了一定的复杂性和对连接的依赖性，从而又限制了实现方法。USB系统软件(USBD和HCD)提供了将客户对数据运动的要求加到包上的方法。对组成一个客户软件和应用层间的数据传送的各个事务，HC利用IRP来跟踪它们。图5-11简要说明了事务是如何被组织成四种传送类型的IRP的。关于传送的详细协议规定，可见第7章。关于客户软件对IRP的使用的更详细信息可见第9章和特定操作系统的系统说明信息。 图4-11 通信流的传送方式 虽然IRP要跟踪传送数据的总线事务，HC仍可自由地选择如何传送这些事务，但必须遵守USB定义的限制，即一帧内只可有一个同步传送的事务。一般情况下，端点看到的各个事务的顺序与它们出现在IRP中的顺序是一样的，除非发生了错误。例如，图5-12表示了两个IRP，每个IRP有3个事务，用2个通道。对任何传送类型，HC可在第一帧内先传第一个IRP的第一事务，再传第二个IRP的第一个事务；同时在第二帧内先传第二IRP的第二事务，再传第一IRP的第二事务；如图中所示。 通道 通道 图4-12 IRP组织成事务/帧 如果有同步传送，HC的自由度也就到此为止了。但对控制传送和批传送，HC可以在这两帧中的任一帧内多传或少传几个第一IRP或第二IRP的事务。 4.9.3 计算总线事务的时间 当USB系统软件允许在总线上新建一个通道，它必须计算对一个给定的事务需要多少总线时间。这个时间是按照端点报告的最大包长度来计算的，同时也必须包括协议规定的开销、信号强加的位填充的开销、协议规定的包间时间的开销、事务间的时间的开销等等。计算的结果用来检查帧内可用的时间是否够用的，以下是计算用的各方程。 KEY: Data_bc The byte count of data payload Host_Delay The time required for the host to prepare for or recover from the transmission; Host Controller implementation-specific Floor() The integer portion of argument Hub_LS_Setup The time provided by the Host Controller for hubs to enable low-speed ports; measured as the delay from the end of the PRE PID to the start of the low-speed SYNC; minimum of four full-speed bit times BitStuffTime Function that calculates theoretical additional time required due to bit stuffing in signaling; worst case is (1.1667*8*Data_bc) 由以上方程计算出的总线时间的单位是纳秒，而且计算结果包含了由于主机和设备之间的延迟而造成的传播延时，这些方程是典型的用于计算总线时间的方程，但实现时可选用一些较粗糙的近似计算。 某个特定的事务实际所用的总线时间总是小于计算出的总线时间，因为位填充的开销是与数据有关的，最糟的情况是位填充的时间是原时间的1.1667(7/6)倍(方程中用8*1.1667乘以Data-bc)。这就是说，当所有规则安排的事务完成后，总有些总线时间是未用的(服从于数据模式的指定)，这些未用的时间可以被重新用于别处，参见4.9.5节。 方程中的Host-Delay项是与HC及系统有关的，它允许HC由于申请访问造成的延迟或其它与实现有关的延迟的原因多要求一点额外时间。通过HCD接口提供的传送管理功能，这项被包括在方程的实现中。方程的实现可采用USBD和HCD软件的共同工作来完成，这些方程的结果决定了一个传送或通道是否被USB设置所支持。 4.9.4 应用层及软件对缓冲区大小的计算 客户软件和应用设备必须给正在等待传送的数据事务提供缓冲区。对非同步传送，这个缓冲区的大小必须恰好能装下下一个数据包，如果不止一个事务在等待同一个端点，必须为一个事务提供数据缓冲区。由于在应用层与客户软件间的事务的出现，应用可能需要一定大小的缓冲区，关于这个区的精确的最小绝对长度的计算是不在USB说明的范围之内的。 HC能够支持的等待事务的数量应是不受限的，但实际上，要受限于可用内存缓冲的大小和描述器的空间大小等。对同步通道，4.10.4节描述了影响主机侧和设备侧的缓冲要求的一些细节。一般说来，缓冲区应容纳约等于1ms中能传的数据量的两倍大小的数据。 4.9.5 总线带宽归还 USB带宽和总线访问的允许都是从最糟的情况考虑的。由于不同传送类型的限制以及被算作常数的位填充的时间实际是数据相关，所以在每帧内，与计算出的时间相比，总有些时间剩余。为了提高带宽利用率，这些时间可以用于控制传送或批传送。HC具体如何去做是与实现相关的。HC可以考虑等待的IRP的传送类型和剩余时间的情况来决定如何使用这些被归还的时间。 4.10 关于同步传送的一些特别考虑 系统的同步传送的能力是由USB支持的。在USB上进行可靠的同步数据传送必须注意一些细节。同步传送可靠性由几个USB部分分别负责： ·设备/应用 ·总线 ·主机控制器(HC) ·一个或多个软件代理商 因为时间对于同步传送是很重要的，所以USB的设计者必须了解USB中的这些部分是如何处理时间问题的。 所有的同步设备必须以各自的描述器的形式来报告自己的能力。同时这些能力也要以某种形式向客户说明，让他们决定该设备是否能解决他们的问题。设备各有不同的专门功能，所以它们的价格也有差异。 在任何通信系统内，发送器和接收器必须同步，也能保证数据传送正确。如果是异步系统，发送器可检测接收器是否收到数据，并且可在出错时，进行简单的重发。 而如果是同步系统，接收器和发送器必须保持时间上和数据上的同步，才能使数据传送正确。USB不支持同步数据的重发，所以可以使分给同步传送的带宽达到最小。也不会因为重发而丢失同步。然而，重要的是，接收器与发送器不仅在正常情况下要保持同步；在错误发生时，也要能保持同步。 在许多系统，使用一个全局时钟，所以部件与它同步。一个例子就是PSTN(公共交换电话网)，考虑到接到USB上的设备有不同的固有频率，不可能有一个时钟在满足大众化PC产品的价格要求的同时，还能满足系统上所有设备和软件的同步要求。USB定义了一个时间模式，在有较合理价格的前提下，使各色设备在总线上共存。 本节提供了几种选择供端点使用，使其能够尽量缩小一个设备的非USB实现与USB实现间的差异，后面有一例子说明设备的非USB应用与USB应用间的相似和相异。 本节最后还介绍以下一些重要概念： ·USB时间模型：USB系统中使用的时钟，它影响着同步数据传送。 ·USB帧时钟与应用时钟同步的方法：USB帧时钟如何与应用时钟发生联系。 ·SOF跟踪：关于SOF令牌和USB的帧，以及同步端点的责任和机会。 ·数据预缓冲：在数据生成、传送和消费前，对数据积累的要求。 ·出错处理：对于同步传送的出错处理的细节。 ·为速率匹配而做的缓冲：可用方程计算同步端点所需的缓冲区大小。 4.10.1 典型的非USB同步应用 这个例子是具一般性的例子。更复杂或更简单的情况都是有可能的。相关的USB特性可能用的不太适当。 例子中有一个8KHz的单声道麦克风，通过一个送进入数据流的混合器驱动器（Mixer Driver）连上一个44KHz的立体声扩音器。混合器期望发送和接收的数据有一个确定的取样速率和编码。在输入、输出口的速率匹配器驱动器（Rate Matcher Driver）将固有取样频率和编码变为混合器期望的取样速率和编码，图4-13说明了这个例子。 PC中的主控时钟(由被实时时钟驱动的软件提供)用来提醒混合器向输入源要输入数据和向输出提供输出数据。这个例子中，假设此时钟每20ms提醒一次。麦克风和扬声器的采样时钟各不同步，且与主控混合器时钟也不同步。麦克风的固有速率为1秒8000次取样，一次取样结果为一个字节，它以此速度生产数据。扬声器的固有频率为1秒44100次采样，一次采样结构为4字节，它以此速度消费数据，系统中的这三个时钟会产生浮动和抖动，速率匹配器的时钟可以与这三种时钟(混合器时钟，源时钟，目的地时钟)均不相同。 速率匹配器一直监视设备的数据速率，不时插入一个额外采样或将两个采样合并为一个，来调整设备的时钟，向主控混合器时钟看齐。调整工作可以每两秒做一次，但一般都是不定期的，不频繁的。速率匹配器提供几个额外的缓冲来完成速率匹配工作。 注意：有些应用不能进行采样的调整。这时或者用一些方法来消除主时钟与设备时钟的不一致；或者用一些方法使两时钟同步，不让不一致发生。 混合器总是精确地从它的输入设备处收到一个服务周期的数据(20ms)或为它的输出设备产生一个服务周期的数据。对混合器的延迟不能超过一个服务周期的长度。混合器认为这些延迟不会积累起来。 当输入设备和输出设备处理完一个服务周期的数据后，要能对DMA发的硬件中断做出发数据或收数据的反应。他们总是发或收一个服务周期的数据。输入设备每个服务周期(20ms)产生160个字节(10个取样)。输出设备每20ms的服务周期消费3528个字节(882个采样)。DMA控制器在主机缓存和设备传一个采样的速率比这些设备的采样速率都要快。 输入、输出设备都提供能容纳两个服务周期数据的系统缓存。一个给DMA控制器处理，另一个备用，以防第一个被取空。如果当前的缓存正被逐步取空，硬件中断将提醒设备驱动器，该驱动器要求速率匹配器给它一个缓存。在当前缓存被取空以前，设备驱动器会为新给的缓存申请一个新的IRP。 设备提供的数据缓存两个取样长度那么长，以保证当系统区对前一个采样做反应时，总可以为下一个采样同时做处理。 驱动器的服务周期可在操作系统中的中断延迟之后继续。不同的操作系统环境要求不同的服务周期来保证可靠的操作。服务周期长度的选择要能够使系统的中断负荷最小，因为系统中还有别的软件会要求处理时间。 混合器 驱动器 速率匹配器 速率匹配器 麦克风 麦克风 驱动器 驱动器 传送结束 传送结束 的中断 的中断 DMA 软件 控制器 硬件 传统的总线 （例如 PCI，ISA，…..） 单取样的传送 单声道 CD立体声 麦克风 扬声器 图4-13 非USB同步的例 4.10.2 USB时钟模型 USB系统中的时间是由时钟体现。实际上，USB系统中有多个时钟： ·取样时钟：这个时钟决定了客户软件与应用设备间传数据取样的固有频率。在非USB和USB实现中，这个时钟不必不一样。 ·总线时钟：这个时钟频率为1KHZ。总线上SOF包的时间体现了此时钟。这个时钟相当于非USB的例子中的8KHZ时钟。在USB系统中，总线时钟一般比采样时钟频率低。在非USB系统中，总线时钟一般比采样时钟频率高。 ·服务时钟：它取决于客户软件服务IRP的速度，这些IRP可能在两次执行之间积压下来。在非USB和USB系统中，这个时钟可以相同。 如果每个设备驱动器在高速取样的每次取样后都要被中断，现存的操作系统是无法支持变化很大的各种同步通信流的。因此，一般等有多个取样或多个取样包后，再将其交由客户软件处理，然后送给HC，根据事先约定的总线访问要求在总线上排队。图4-14提供了一个USB系统时钟环境下的例子，与图4-13的非USB系统例子相对照。 图4-14表示了一个典型的信息环路，麦克风作为输入设备，扬声器作为输出设备。涉及的时钟、包、缓存也标在了图中。在以后的几节后，图4-14将被进一步详细地说明。 这个例子的重点是突出USB与前一个非USB例子的不同。不同之处在于缓存的区域，USB总线时钟的同步和延迟，。设备驱动器上的客户软件在大多数情况下可不受影响。 混合器 驱动器 速率匹配器 速率匹配器 麦克风 麦克风 驱动器 驱动器 传送结束的中断 传送结束的中断 队列缓冲 USB 队列缓冲 SW 主机 控制器 HUB 单声道 CD立体声 麦克风 扬声器 图4-14 USB同步的例 4.10.3 时钟同步 为了可靠地传送同步数据，前面提到的三个时钟必须同步。如果不这样，就会出现一些不希望看到的时钟间的问题： ·时钟漂移：两个应正常同步的时钟，因为实现上的问题，在走很长一段时间后，可能会走得快慢不一。如果不及时校正，则与其中一个作为标准的时钟相比，另一个时钟就会导致数据过多或过少。 ·时钟抖动：由于温度等的原因，时钟频率会发生改变，也造成了数据实际发出的时刻与它被期望发出的时刻不同。 ·时钟间相位差异：如果两个时钟不被锁相，由于时钟的错位，在不同的时间点上会收到不一样多的数据。这会造成量化/取样的不真。 总线时钟提供了一个中心时钟，USB硬件设备和软件可以向它同步。但在大多数PC的操作系统中，仅靠实时调度的支持，软件并不能精确地锁相、锁频到总线时钟上。软件知道USB上的数据是打包的。对同步传送，在一帧内只传一个包，而帧时钟是相对精确的，软件可以凭实际花费的帧时间调整它处理数据的量。 4.10.4 同步设备 USB为同步设备提供了一个框架，定义了同步类型及同步端点如何提供数据速率反馈，以及同步端点如何被连结到一起。同步设备包括被取样的模拟设备(如：声音设备、电话设备)和同步数字设备。对端点同步类型的分类的依据是它们将自己的时钟同步到与它们相连设备的能力。反馈信息能指出什么是要求的时钟频率。进行连接的能力依赖于想要的连接质量、端点的同步类型，以及进行此连接的主机应用程序的能力。额外的设备级信息是需要的，要多少取决于应用程序。 注意：数据是个一般性的词，可代表取样过的模拟信号(如声音)，也可指抽象的信息。数据速率可以指模拟信号被取样的速率，也可以指数据时钟的速率。 以下信息用于决定如何连接同步端点： ·同步类型 ——异步：不同步、但目的（sink）能提供数据速率反馈 ——同步：同步到USB的SOF时钟 ——可调：用反馈或feed forward 的数据速率信息实现同步 ·可获得的数据速率 ·可获得的数据格式 同步类型和数据速率信息决定了源和目的之间的速率是否匹配，如果有可接受的转换过程存在，就允许它们相连。应用程序有责任决定在可获得的处理资源的限制和其它限制(如延迟)下，是否支持一个连接。具体的USB设备级定义了如何描述同步类型和数据速率。 数据格式匹配和转换也是需要的，但不是仅对同步连接才要求。关于数据格式转换的细节在其它文件中可找到。 4.10.4 同步类型 有三个明显的同步类型，表4-7列出了它们各自的端点的同步特征(作为源或目的)。这三个类型的排列是根据它们的能力逐步增强的顺序进行的。 表4-7 同步特性 源 目的 异步 自由地安排Fs 提供隐式的feed forward（data stream） 自由地安排Fs 提供显式的反馈（中断通道） 同步 Fs与SOF同步 使用隐式的反馈（SOF） Fs与SOF同步 使用隐式的反馈（SOF） 可调 Fs与SOF同步 使用显式的反馈（控制通道） Fs与数据流同步 使用隐式的feed forward（data stream） 4.10.4.1.1 异步 异步不能向SOF或其它USB范围内的时钟同步。它们的源和目的的同步数据流都是在一个固定的数据速率上(单数率端点)，有一个有限的数据率的个数(32KHZ,44KHZ,48KHZ)，或一个 连续的可编程的数据率。如果可编程，是在同步端点的初始化时候进行的，异步设备需在它们的端点描述器中报告自己的可编程能力。数据速率是锁到一个USB的外部时钟或一个内部的自由时钟上的。这些设备将进行速率匹配的任务留给了USB环境中的其它部分。异步源端点通过它们每帧的生产的采样个数隐式地体现了自己的数据速率信息，异步目的端点必须用显式地反馈向一个可调的驱动器说明自己的数据率(见4.10.4.2)。 异步源的一个例子是CD播放器，它依据自己的内部时钟或共振器来提供数据，另一个例子是数字声音广播(DAB)的接收器或数字卫星接收器(DSR)，它们的取样速率取决于广播侧而不是USB的控制，异步目的端点可以是低价格的扬声器，用自己的内部取样时钟。 另一个情况USB上有两个或更多的设备要求对SOF的产生拥有控制权以便能够作为同步设备运作。例如有两个电话设备，有各自的外部时钟。一个电话可被接到Private Branch Exchange(PBX)上，PBX不与ISDN同步。另一个电话直接接到ISDN上，每个设备向网上产生或接收数据都是用自己的外部驱动速率。因为只有一个设备可获得SOF的控制权，另一个设备的数据速率就只能与SOF异步。这个例子表明，每个有能力控制SOF的设备都可能被迫成为异步设备。 4.10.4.1.2 同步 同步端点可有自己的时钟系统，但此系统可被SOF同步所控制。这些端点可以： ·将自己的取样时钟作为SOF时钟（1ms１次）的奴隶(通过一个可编程的PCL)。 ·控制USB的SOF产生速率，显而易见，这样的话，它们的时钟自然与SOF同步。如果这些终点不被给予SOF的控制权，它们降级到异步模式。 同步端点发出或接收同步数据流的数据速率有以下几种情况。可以使用一个固定的数据速率(单频率端点)，或有限个数的几个速率(32KHZ，44.1KHZ，48KHZ)，或一个连续的可编程的数据速率。如果可编程，在同步端点的初始阶段进行设定。在一系列的USB帧中产生的采样数或数据单元数是可确定的和周期性的。同步设备须在端点描述器中报告自己的可编程能力。 同步源的一个例子是数字麦克风。它向SOF同步自己的取样时钟，并在每个帧内产生同样多的声音采样。另一种可能是从ISDN 的“Ｍodeｍ”中来的64kb/s的位流。如果USB的 SOF产生时钟被同步到PSTN的时钟(也许通过同一个ISDN设备)，数据的产生也会被同步到SOF，且端点将产生一个稳定的64kb/S的数据流，以SOF时钟为参照。 4.10.4.1.3 可调 可调的端点是能力最强的端点，它们可以在自己的操作范围内产生和接收任意速率的数据。对可调的源端点来说，数据产生速率是被数据的目的端点所控制的。目的给源一个数据速率的反馈(见4.10.4.2)。这样源就知道了目的要求的速率。可调的端点可以和任何类型的目的通信。对可调的目的端点来说，数据速率的信息是被包含在数据流中的。在一个确定的平均时间段内接收的平均取样数目决定了瞬时的数据速率。如果在操作中，这个数目发生了变化，则数据速率就作出相应的调整。 数据速率的变化范围是以某个速率为中心(例如8KHZ)，它是从几个可编程的速率或自动检测的数据速率(32KHZ，44.1KHZ，48HZ)中选择出来的，速率也可以是一个或几个范围(如5KZ-12KHZ或44KHZ-49KHZ)，可调端点也必须在它们的端点描述器中报告自己的可编程能力。 可调源的一个例子是CD播放器。它包括一个完全可调的取样速率转换器(SRC)，所以输出取样的速率不必为44.1HZ，而可以是在SRC控制范围内的任何值。可调目的端点包括高端（High-end）数字扬声器，耳机等。 4.10.4.2 反馈 异步目的向可调源提供一个反馈，来表明它想要的数据速率(Ff)是多少。要求的数据速率必须精确到1秒1个取样(1HZ)以上，这才能够使源速率达到一个高质量，并能容忍反馈中的延迟和错误。 Ff的值包括一个小数部分和一个整数部分，小数部分是为了达到1KHZ频率帧的分辨率，整数部分给出了每帧内的最小取样数目。在1KHZ的帧频率下，小数部分要求有10位来表示一个取样(1000/2^10=0.98)。这是一个十位的小数部分，可以用无符号的定点二进制0.10格式表示。整数部分也需要10个位(2^10=1024)来表示每帧内1023个单字节取样。10位的整数用无符号的定点二进制格式10.0表示。两部分合在一起的Ff值可用无符号的定点二进制格式10.10。此格式需要3字节(24 bits)。因为最大的整数值是1023，数10.10格式的数被向左靠齐成为24位，所以它的格式为10.14，小数点后的头十位被承认，剩下的低4位被可选地用于扩展精度，或者可以被看作0。第7章中还会介绍其它的多字节区中定义的位和字节的顺序。 每帧中，可调源将Ff加到从前一帧中剩下的小数部分上，然后产生总数中整数部分大小的取样，将小数部分的取样再算到下一帧。源可以通过许多帧的Ff的情况来确定一个更精确的速率。 目的端点可以通过以下方法确定Ff。它在2^(10-P)帧的时间内(P为整数)，以Fs*2^P的频率数时钟的周期。P的经验取值在［0，10］的范围内，因为没有点（point）用比Fs更慢的时钟，且没有点（point）企图在一帧内更新不止一次。计数器被读入Ff,并且每2^(10-P)帧时间后复位一次。只要没有时钟被漏掉，计数在很长一段时间内将是很精确的。端点只要保证计数器的位数即可，这个位数要能容纳它的最大Ff。 数字电话端点通过将64KHZ的时钟分频(P=3)来得到自己的8KHZ Fs。64KHZ是它用于数据流串行的时钟。64KHZ的时钟相位可以作为一个额外的位来提高精确度，相当于取了P=4。这使Ff每2^(10-4)=64帧刷新一次。所以就需要一个13位的计数器来保存Ff,3位表示每帧8个取样，10位表示小数部分。13位的格式为3.10，因为它在10.14 Ff值格式下，所以其余的位置设为0。 P的选择是与端点有关的，选P有以下的指导原则： ·P在［1，9］的范围内 ·P的值越大越好，因为这样可以减少帧计数器的大小而提高Ff刷新的速度。高的刷新速度会保证对源端数据速率的更好控制，减少了用于处理Ff变化的缓存的大小。 ·P必须比10小，这样保证了至少两帧以上才会刷新一次，避免了SOF的抖动。 ·P不能为0，这样可保证在一次Ff值丢失的情况下，与产生的采样数的偏离小于1。 从反馈寄存器中读Ff由同步传送来完成。每2^(10-P)要保告一次反馈信息。Ff在每个刷新周期必须被报告至少一次。如果一个刷新周期内将一个同样的Ff值报告一次以上，不会有什么用处。端点只有在Ff值与上次比有变化时才报告一下。 经过一个很长的阶段，源可能会多发一个或少发一个采样。这可能是因为测量Ff的错误或误差的积累。目的端必须有足够的缓冲能力处理这些情况。一旦目的端发现这些情况，应当将报告的Ff调整正确。对时钟的相对漂移，调整也是必须的，这种校正处理的实现与端点有关，不被指定。 在双向通话的连接中，可调源可以获得可调目的的数据速率，但该源是采用目的端的身分获取此速率的，所以，此时不需要反馈通道。 4.10.4 连接 连接模型被用来详细描述源到目的的连接过程。这个模型涉及到的各个不同的组成部分及它们如何互相作用来完成连接。 模型提供了多个源和多个目的的情况，图4-15说明了一个典型的情况(高度浓缩的及不完全的)，物理设备通过不同的物理层、软件层接到主机应用软件上(USB说明中描述)。在客户界面层、应用层看到一个虚拟设备。从应用层的角度看，只有虚拟设备存在。物理设备与虚拟设备的关系由设备驱动器和客户软件决定。 CD-ROM 物理源 同步通道 同步通道 虚拟源 USB环境 同步通道 虚拟目的 同步通道 物理目的 硬盘 图4-15 源与目的的典型连接 设备制造商(或操作系统销售商)必须提供设备驱动器软件和客户界面软件，以便将物理实现转变为一个USB需要的软件实现(虚拟设备)。如前所述，以加入软件的功能为基础，虚拟设备可以展现物理设备的不同同步行为。然而，同步的分类对物理设备和虚拟设备是一样的。所有的物理设备都必须属于3种类型中的一种。所以，加入设备驱动器或客户软件的功能应与物理设备的功能一样。名词“应用”必须被换成“设备驱动器/客户软件”，当物理源被联系到虚拟源，“虚拟源设备”应被换成“物理源设备”，“虚拟目的设备”应被换成“虚拟源设备”。当虚拟目的联系到物理目的，“虚拟源设备”必须被换成“虚拟目的设备”，“虚拟目的设备”应被换成“物理目的设备”。 将速率调节器(RA)功能加到设备驱动器/客户软件层上有明显的好处，它可将所有应用独立起来，使设备不必关心与速率调节有关的一些规定和问题。多速率的应用也会退变为简单一些的单速率系统。 注意：这个模型并不局限于USB设备。例如，一个包含44.1KHZ的声音的CD-ROM驱动器可以作为异步、也可作为同步或可调的源。异步操作时，CD-ROM以它读盘的速率来填充自己的缓冲区、驱动器根据它的USB服务的间隔来取数据。同步操作时，驱动器根据USB服务的间隔(10ms)和名义上的取样速率(44.1KHZ)决定每个USB服务周期时输出441个取样。可调操作时，建一个取样速率转换器来匹配CD-ROM的输出速率和各种不同的目的端的取样速率。 使用这个参照模型，可以定义在不同的源和目的间建立连接所必须的操作。而且，这个模型还指出了这些操作必须或可以在哪层发生。第一阶段，物理设备被映射到虚拟设备，这由驱动器和/或客户软件完成，基于软件的能力，物理设备可被映射成具有完全不同的同步类型的虚拟设备。第二阶段，是对虚拟设备的应用，在软件栈的驱动器/客户层加入数据匹配功能后，与虚拟设备通信的应用就可以不必为连上它的每个设备作速率匹配工作。一旦虚拟设备的特性定了下来，实际的物理设备的特性就不必关心了。 作为一个例子，考虑在源侧将一个混合器应用连到不同的源上，每个源以各自的频率和时钟工作。在混合发生前，所有的流都必须被转换成同一个频率，并锁到一个参考时钟上。这个工作可以在物理到虚拟的映射层做，也可以在应用层为每个源单独处理。相似的工作在目的侧也要做，如果应用将混合的数据流送到不同的目的设备，它可以为每个设备做速率匹配的工作，也可以把这个工作留给驱动器/客户软件去做(如果可能的话)。 表4-8表明了将源端点连到目的端点时，应用必须做的工作。 表4-8 连接的要求 源端点 目的端点 异步 同步 可调 异步 异步的源/目的间的RA 参见注释1。 异步的SOF/目的的RA 参见注释2。 数据+反馈 Feedthrough 参见注释3。 同步 异步的源/SOF的RA 参见注释4。 同步RA 参见注释5。 数据 Feedthrough +应用反馈 参见注释6。 可调 数据Feedthrough 参见注释7。 数据Feedthrough 参见注释8。 数据 Feedthrough 参见注释9。 注释： 1. Asynchronous RA in the application. Fs i is determined by the source, using the feedforward information embedded in the data stream. Fs o is determined by the sink, based on feedback information from the sink. If nominally Fs i = Fs o , the process degenerates to a feedthrough connection if slips/stuffs due to lack of synchronization are tolerable. Such slips/stuffs will cause audible degradation in audio applications. 1：应用中的异步速率调节器。Fsj由源决定。源利用数据流中包含的feedforward信息来做决定Fs0由目的决定。它的决定依据是从目的来的反馈。如果Fs0由目的决定。它的决定依据是从目的来的反馈。如果Fs0=Fsj，且由于缺少同步而引起的slips/stuffs可以被容忍的话，处理将退化成为一个feedthrough连接。这样的slips/stuffs在声音应用中将引起可听出来的声音质量下降。 2. Asynchronous RA in the application. Fs i is determined by the source but locked to SOF. Fs o is determined by the sink, based on feedback information from the sink. If nominally Fs i = Fs o , the process degenerates to a feedthrough connection if slips/stuffs due to lack of synchronization are tolerable. Such slips/stuffs will cause audible degradation in audio applications. 2：应用中的异步速率调节器。Fsj由源决定，但必须锁到SOF上。FS0是由目的决定的，但要基于来自目的的反馈信息。如果Fsj=FS0，且由于缺少同步而引起的slips/stuffs可以被容忍的话，这个过程退化为一个feedthrough连接，这种slips/stuffs在声音应用中将引起可听的出来的声音质量下降。 3. If Fs o falls within the locking range of the adaptive source, a feedthrough connection can be established.Fs i = Fs o and both are determined by the asynchronous sink, based on feedback information from the sink. If Fs o falls outside the locking range of the adaptive source, the adaptive source is switched to synchronous mode and Note 2 applies. 3：如果FS0落在可调源的锁定范围内，一个feedthrough可以被建立。Fsj=Fs0，它们都由异步目的决定，但要基于从目的来的反馈信息。如果Fs0落在可调源的锁定范围外，可调源转变成同步模式，注释2适用。 4. Asynchronous RA in the application. Fs i is determined by the source. Fs o is determined by the sink nd locked to SOF. If nominally Fs i = Fs o , the process degenerates to a feedthrough connection if lips/stuffs due to lack of synchronization are tolerable. Such slips/stuffs will cause audible degradation n audio applications. 4：应用中的异步RA。Fsj由源决定，FS0由目的决定并锁到SOF上。如果Fs0=Fsj,且由于缺乏同步而引起的slips/stuffs可被容忍的话，这个过程退化成一个feedthrough连接。在声 音应用中，这些slips/stuffs将引起声音质量下降。 5. Synchronous RA in the application. Fs i is determined by the source and locked to SOF. Fs o is determined by the sink and locked to SOF. If Fs i = Fs o , the process degenerates to a loss-free feedthrough connection. 5：应用中的同步RA。Fsj由源决定，且锁到SOF上。FS0由目的决定，并锁到SOF上。如果Fsj=FS0，这个过程退化为允许丢失的feedthrough连接。 6. The application will provide feedback to synchronize the source to SOF. The adaptive source appears to be a synchronous endpoint and Note 5 applies. 6：应用提供反馈来将源同步到SOF上。可调源看成一个同步端点，注释5适用。 7. If Fs i falls within the locking range of the adaptive sink, a feedthrough connection can be established. Fs i = Fs o and both are determined by and locked to the source. If Fs i falls outside the locking range of the adaptive sink, synchronous RA is done in the host to provide an Fs o that is within the locking range of the adaptive sink. 7：如果Fsj落在可调目的的锁定范围，则一个feedthrough连接可以被建立。Fsj=Fs0，且它们都由源决定，并锁定到源上。如果Fsj落在可调目的的范围外，同步RA由主机完成，主机再提供一个Fs0落在可调目的的范围内。 8. If Fs i falls within the locking range of the adaptive sink, a feedthrough connection can be established.Fs o = Fs i and both are determined by the source and locked to SOF. If Fs i falls outside the locking range of the adaptive sink, synchronous RA is done in the host to provide an Fs o that is within the locking range of the adaptive sink. 8：如果Fsj落在可调目的的锁定范围内，一个feedthrough连接可被建立。Fs0=Fsj，且都由源决定，并锁定到SOF上。如果Fsj落在可调目的的锁定范围外，同步RA由主机完成，主机再提供一个落在可调目的的锁定范围内的Fs0。 9. The application will use feedback control to set Fs o of the adaptive source when the connection is set up. The adaptive source operates as an asynchronous source in the absence of ongoing feedback information and Note 7 applies. 9：当连接建立时，应用可以用反馈控制来设定可调源的Fs0，没有反馈时，可调源变成一个异步源，此时注释7适用。 在需要RA但RA不可得时，速率调节过程只能被模拟一下，即采用漏掉一两个采样或填充一两个采样的方法。此时，连接有可能被建立，但可能会有一个对质量不佳的警告；或者，连接根本不能建立。 4.10.4.3.1 音频连接 当以上所说的一般连接应用到音频连接上时，RA过程就被取样速率转换所取代，这是一种速率调整的特殊形式。不用错误控制，而用某种形式的取样插补来匹配输进和输出的取样速率。依靠这种手段，谈话的声音质量(扭曲(distortion)、信噪比等)均有很大改善。一般地来说，更强的处理能力带来更好的质量。 4.10.4.3.2 同步数据连接 在同步数据连接中，我们使用RA。对许多实现了差错控制的应用来说，偶尔的slips/stuffs是可以接受的，差错控制包括差错检测和丢弃(discard)，差错检测和重发，或者前向纠错。slips/stuffs的发生速率主要看源的时钟和目的时钟误差的大小，它们是信通上最主要的差错来源。如果差错控制足够强大的话，连接仍可建立)。 4.10.5 数据预缓存 USB要求设备在处理和传送数据前要将数据预缓存一下，这样主机在处理各个通道的事务时就具有更大的灵活性。 从设备到主机的传送中，端点必须在帧x期间积累采样，直到收到帧X+1的SOF信号。它将帧x的数据锁到它的包缓冲中，准备好将包含这些取样的包在帧x+1期间发出去。至于在帧内的何时将发送这些数据只能由HC(主机控制器)决定，而且对每一帧的情况可以不同。 从主机到设备的传送中，在帧Y期间，端点收到从主机来的包。当它收到帧Y+1的SOF信号后，它才可以开始处理在帧Y期间收到的数据。 这个机制允许端点将SOF令牌用作打入时钟(stable clock)，而且抖动和/或漂移都很小。当HC在总线上传包时，这个机制也允许HC可以精确地改变在一帧内何时将包传出。与到每帧的SOF距离相同的总线访问相比，这种预缓存会造成端点准备好数据和数据真正在总线上传送的时间之间的额外延迟。 图4-16说明了设备到主机之间的传送的时间序列(IN process)，数据D0在Ti处的帧Fi期间积聚，在帧Fi+1期间发给主机。相似的，从主机到设备的传送(OUT process)，数据Do由端点在帧Fi+1期间收到，在帧Fi+2期间处理。 Time: Ti Ti+1 Ti+2 Ti+3 ... Tm Tm+1 ... Frame: Fi Fi+1 Fi+2 Fi+3 ... Fm Fm+1 . .. Data on Bus: D0 D1 ... D2.. D0 D1 OUT Process: D0 D1 ... D0 ... IN Process： D0 D1… D0… 图4-16 数据预缓冲 4.10.6 SOF跟踪 支持同步通道的应用设备必须要能够接收和理解SOF令牌才能支持预缓存。由于SOF可能会被破坏，所以设备必须能从从被破坏的SOF中恢复。这个限制使得只有高速设备才可使用同步传送，因为低速设备不能发现总线上的SOF。因为SOF包可能在传送中被毁坏，所以支持同步传送的设备需有合成SOF的能力，这个SOF由于总线错误而不能被他们看到。 同步传送要求适当的数据在适当的帧内被传送。USB要求当同步传送被显示给HC时，它必须指出它的第一帧的帧号。HC不会在指定的帧前开始传第一个事务。如果当前的帧内无事务在等待传送，HC在同步通道上就什么都不传。如果同步传送要求的帧已经过去了，HC会跳过(即不传)前面的事务直到对应当前帧的事务到来。 4.10.7 差错处理 同步传送不进行数据包的重发(即接收方不发握手信号给发送方)，所以数据传送的同步不会被打乱。但数据传送的代理商有责任知道何时发生了一个错误以及该错误如何影响通信流。特别地，对于数据包序列(A，B，C，D)，USB有够的信息。所以一个漏掉的包(A， ，C，D)是可以被测的，并且不会在不知道的情况自动变成不正确的数据或时间序列(A，C，D)或(A ， ，B，C，D)。协议提供了4种机制来支持这个想法：一帧一包；SOF；CRC以及总线事务超时。 · 同步传送要求在正常的操作中，一帧只能有一个数据事务。USB并不干涉每帧内是什么样的数据。数据发送器（源）决定提供什么样的数据。这种数据每帧(data-perframe)结构很规则，它提供了一个框架，这个框架是丢失数据的错误检测的基础。在总线传送期间事务的任何一个阶段都可能有破坏。第7章将介绍每种错误对协议的影响。 ·因为每帧前都有一个SOF，接收器会在总线上看到SOF。接收器可以凭此发现在两个SOF之间，它期望的帧没有出现。特别地，SOF也有可能被破坏，所以设备必须能够重建被漏掉的SOF(见4.10.6)。 ·数据包可能在总线上被损坏，所以CRC保护可以让一个接收器发现它收到的数据包是否被破坏了。 ·当接收器成功收到一个令牌包后，如果发现有总线事务超时，它可以不再准备去接收数据包。这些细节都在协议中有定义。 一旦接收器决定不再接收某个数据包，它必须知道被丢掉的这个包的数据长度，才能在做出相应的错误后的恢复。如果每帧的数据流都是一样的长度，这个值就是一个已知的常数。然而，有些情况，帧与帧的数据长度不同。这时，接收器和发送器要有一个机制来决定丢失的包的长度，这个机制是与它俩的具体实现有关。 总的来说，不管一个事务是否成功地被传送了，接收器和发送器均会以每帧一个事务的速度继续它们的数据/缓冲流。这样才能保证数据在时间上的同步。以上描述的一些机制，用于检测、跟踪、和报告被破坏的事务，让设备或它的客户软件可以对这种破坏以合适的方式做出反应。关于设备和应用对此如何反应是不在USB说明的范围内的。 4.10.8 为匹配速率而做的缓冲 如果USB上有许多不同的时钟在影响着同步数据流，为了使USB上的数据流的速率的相互匹配，缓冲是必不可少的。设备上的每个端点都必须有缓存。主机上的客户软件也必须拥有缓存，数据在被传送之前可以存放在缓存中。如果已知设备的数据速率，需传的数据包的最大长度就是可计算的，图4-17给出了几个方程，用于决定设备和主机上的缓存大小以及在给定的数据速率下可能出现的最大包长。 图4-17进行速率匹配的同步传送的包长和缓冲大小的计算 设备和客户软件利用这些方程来设计服务时钟速率(变量x)，取样时钟速率(变量C)，和取样的长度(变量S)。USB只允许一个总线时钟对应一个事务。这些方程提供的信息可成为端点选择合适的包长，或信息/端点和它的客户软件选择合的缓存的依据。图4-14就是了一个典型的同步例子的实际缓存值、包长、时钟值。 USB数据模式认为设备有自己的取样的大小和取样的速率。USB支持包的传送，这个包应当是取样长度的整数倍，这样有利于对总线上被损坏的同步事务的错误恢复。如果一个设备没有固有的取样长度或它的取样长度超过了一个包的长度，它应将它的取样长度描述为一字节。如果一个取样被分为几个包，当任一个包被丢掉后，对错误的恢复比一般情况要困难。在有些情况中，数据同步会丢失，除非接收器知道取样的各个部分将在帧号为几的帧中被传。而且，如果由于时钟校正造成取样的个数发生变化(例如一个non-derived的设备时钟)，将很难知道取样的一个部分何时被传，因此USB不会将一个取样分几个包传。 USB设备 USB主机 USB 总线接口 USB 逻辑设备 应用 USB 主机控制器 USB 系统软件 客户软件 客户软件 USB 系统软件 USB 主机控制器 应用 USB 逻辑设备 USB 总线接口 主机 设备 设备 复合设备 设备 设备 设备 设备 包 事务 传送 IRP 数据 客户软件 USB驱动器 主机控制器驱动器 事务 USB 主机控制器 事务 控制传送首先是一个OUT方向的Setup事务，然后是多个IN方向或OUT方向的数据事务，最后是一个与数据反向的Status事务。 事务 事务 事务 IRP 额外的 控制传送 Status 事务 数据 事务 Setup 事务 IRP 控制传送 所有的传送都是由一个或多个事务组成。一个IRP又可由一个或多个传送组成。 数据流类型 一个批传送是一个或多个IN/OUT方向的数据事务。 事务 事务 事务 IRP 批传送 一个同步传送是一个或多个IN/OUT方向的数据事务。 事务 事务 事务 IRP 同步传送 一个中断传送是一个或多个IN/OUT方向的数据事务。 事务 事务 IRP 中断传送 令牌，数据， 握手 （1-1） 令牌，数据， 握手 （2-1） 帧2 令牌，数据， 握手 （2-0） 令牌，数据，握手 （1-0） 帧1 事务 2-2 事务 2-1 事务 2-0 IRP2 IRP1 事务 1-2 事务 1-1 事务 1-0 2*4字节缓冲（2个取样） 8KHz取样时钟 （1字节/取样） 44．1KHz取样时钟 （4字节/取样） 2*1字节的缓冲（2个取样） 8KHz的总线时钟 一次取一个样 一次取一个样 2*160 字节的缓冲 （2 个服务，每个服务有160个取样） 2*3528 个字节的缓冲 （2 个服务，每个服务有882个取样） 20ms服务周期 20ms服务周期 主时钟 一个扬声器DD的服务周期 （n sample） slop buffer 每个DD有独立的设备速率 1*3字节缓冲（1个包） （44+45+1+1）*4 字节的缓冲 （2个包） 8KHz取样时钟 （1字节/取样） 44．1KHz取样时钟 （4字节/取样） 8+9字节的缓冲（2个包） 7-9字节的包 每包有7-9个取样 反馈信息，3字节的包 172-184字节的包， 每个包有43-46个取样 1KHz的总线时钟 2*161字节的缓冲 （2 个服务，每个服务有159-161个取样，即20个包） 2*3532字节的缓冲 （2 个服务，每个服务有881-883个取样，即20个包） 1*3字节的缓冲（1个服务，每个服务有一个反馈，1个包/服务） 能容纳一个取样的slop buffer 20ms服务周期 20ms服务周期 主时钟 一个扬声器DD的服务周期 （n sample） slop buffer 每个DD有独立的设备速率 客户 设备 驱动器 客户 目的 设备 驱动器 目的 设备 驱动器 客户 应用 源 设备 驱动器 客户 源 设备 驱动器 客户 设备 驱动器 客户 通过缓冲来匹配同步速率（时钟） X服务的时钟 M = (2 * N * P) Byte Buffer for 2 Services, N = (CEIL(1KHz / X)) packets per service 1KHz的总线时钟 P = (CEILk (C / 1KHz) * S) Byte Pacets C 取样时钟 （S byte/sample） B = 2 * P Byte Buffer (2 Packets) USB总线接口 SIE 主机控制器 SIE USB USB帧格式 接口 的数据 事务 USB 设备 （第9章） USB System SW 管理设备 USB 逻辑设备 端点的集合 端点0 Client SW 管理一个接口 应用 接口的集合 接口X 端点 USB逻辑设备 通道 客户软件 主机 缓冲区 通信流