USB1.1协议中文完整在线版
当前位置: USB开发网 > USB技术文档 > USB专题 > USB1.1协议中文完整在线版

5.10 关于USB同步传输的一些特别考虑

  系统的同步传输的能力是由USB支持的。在USB上进行可靠的同步数据传输必须注意一些细节。同步传输可靠性由几个USB部分分别负责:

•设备/应用
•总线
•主机控制器(HC)
•一个或多个软件代理商

  因为时间对于同步传输是很重要的,所以USB的设计者必须了解USB中的这些部分是如何处理时间问题的。

  所有的同步设备必须以各自的描述器的形式来报告自己的能力。同时这些能力也要以某种形式向客户说明,让他们决定该设备是否能解决他们的问题。设备各有不同的专门功能,所以它们的价格也有差异。

  在任何通信系统内,发送器和接收器必须同步,也能保证数据传输正确。如果是异步系统,发送器可检测接收器是否收到数据,并且可在出错时,进行简单的重发。

  而如果是同步系统,接收器和发送器必须保持时间上和数据上的同步,才能使数据传输正确。USB不支持同步数据的重发,所以可以使分给同步传输的带宽达到最小。也不会因为重发而丢失同步。然而,重要的是,接收器与发送器不仅在正常情况下要保持同步;在错误发生时,也要能保持同步。

  在许多系统,使用一个全局时钟,所以部件与它同步。一个例子就是PSTN(公共交换电话网),考虑到接到USB上的设备有不同的固有频率,不可能有一个时钟在满足大众化PC产品的价格要求的同时,还能满足系统上所有设备和软件的同步要求。USB定义了一个时间模式,在有较合理价格的前提下,使各色设备在总线上共存。

  本节提供了几种选择供端点使用,使其能够尽量缩小一个设备的非USB实现与USB实现间的差异,后面有一例子说明设备的非USB应用与USB应用间的相似和相异。

  本节最后还介绍以下一些重要概念:

•USB时间模型:USB系统中使用的时钟,它影响着同步数据传输。
•USB帧时钟与应用时钟同步的方法:USB帧时钟如何与应用时钟发生联系。
•SOF跟踪:关于SOF令牌和USB的帧,以及同步端点的责任和机会。
•数据预缓冲:在数据生成、传输和消费前,对数据积累的要求。
•出错处理:对于同步传输的出错处理的细节。
•为速率匹配而做的缓冲:可用方程计算同步端点所需的缓冲区大小。

5.10.1 典型的非USB同步应用

  这个例子是具一般性的例子。更复杂或更简单的情况都是有可能的。相关的USB特性可能用的不太适当。

  例子中有一个8KHz的单声道麦克风,通过一个送进入数据流的混合器驱动器(Mixer Driver)连上一个44KHz的立体声扩音器。混合器期望发送和接收的数据有一个确定的取样速率和编码。在输入、输出口的速率匹配器驱动器(Rate Matcher Driver)将固有取样频率和编码变为混合器期望的取样速率和编码,图5-13说明了这个例子。

  PC中的主控时钟(由被实时时钟驱动的软件提供)用来提醒混合器向输入源要输入数据和向输出提供输出数据。这个例子中,假设此时钟每20ms提醒一次。麦克风和扬声器的采样时钟各不同步,且与主控混合器时钟也不同步。麦克风的固有速率为1秒8000次取样,一次取样结果为一个字节,它以此速度生产数据。扬声器的固有频率为1秒44100次采样,一次采样结构为4字节,它以此速度消费数据,系统中的这三个时钟会产生浮动和抖动,速率匹配器的时钟可以与这三种时钟(混合器时钟,源时钟,目的地时钟)均不相同。

  速率匹配器一直监视设备的数据速率,不时插入一个额外采样或将两个采样合并为一个,来调整设备的时钟,向主控混合器时钟看齐。调整工作可以每两秒做一次,但一般都是不定期的,不频繁的。速率匹配器提供几个额外的缓冲来完成速率匹配工作。

  注意:有些应用不能进行采样的调整。这时或者用一些方法来消除主时钟与设备时钟的不一致;或者用一些方法使两时钟同步,不让不一致发生。

  混合器总是精确地从它的输入设备处收到一个服务周期的数据(20ms)或为它的输出设备产生一个服务周期的数据。对混合器的延迟不能超过一个服务周期的长度。混合器认为这些延迟不会积累起来。

  当输入设备和输出设备处理完一个服务周期的数据后,要能对DMA发的硬件中断做出发数据或收数据的反应。他们总是发或收一个服务周期的数据。输入设备每个服务周期(20ms)产生160个字节(10个取样)。输出设备每20ms的服务周期消费3528个字节(882个采样)。DMA控制器在主机缓存和设备传一个采样的速率比这些设备的采样速率都要快。

  输入、输出设备都提供能容纳两个服务周期数据的系统缓存。一个给DMA控制器处理,另一个备用,以防第一个被取空。如果当前的缓存正被逐步取空,硬件中断将提醒设备驱动器,该驱动器要求速率匹配器给它一个缓存。在当前缓存被取空以前,设备驱动器会为新给的缓存申请一个新的IRP。

  设备提供的数据缓存两个取样长度那么长,以保证当系统区对前一个采样做反应时,总可以为下一个采样同时做处理。

  驱动器的服务周期可在操作系统中的中断延迟之后继续。不同的操作系统环境要求不同的服务周期来保证可靠的操作。服务周期长度的选择要能够使系统的中断负荷最小,因为系统中还有别的软件会要求处理时间。 

非USB同步的例
 
图5-13 非USB同步的例

5.10.2 USB时钟模型

  USB系统中的时间是由时钟体现。实际上,USB系统中有多个时钟:

•取样时钟:这个时钟决定了客户软件与应用设备间传数据取样的固有频率。在非USB和USB实现中,这个时钟不必不一样。
•总线时钟:这个时钟频率为1KHZ。总线上SOF包的时间体现了此时钟。这个时钟相当于非USB的例子中的8KHZ时钟。在USB系统中,总线时钟一般比采样时钟频率低。在非USB系统中,总线时钟一般比采样时钟频率高。
•服务时钟:它取决于客户软件服务IRP的速度,这些IRP可能在两次执行之间积压下来。在非USB和USB系统中,这个时钟可以相同。

  果每个设备驱动器在高速取样的每次取样后都要被中断,现存的操作系统是无法支持变化很大的各种同步通信流的。因此,一般等有多个取样或多个取样包后,再将其交由客户软件处理,然后送给HC,根据事先约定的总线访问要求在总线上排队。图5-14提供了一个USB系统时钟环境下的例子,与图5-13的非USB系统例子相对照。

  图5-14表示了一个典型的信息环路,麦克风作为输入设备,扬声器作为输出设备。涉及的时钟、包、缓存也标在了图中。在以后的几节后,图5-14将被进一步详细地说明。
这个例子的重点是突出USB与前一个非USB例子的不同。不同之处在于缓存的区域,USB总线时钟的同步和延迟,。设备驱动器上的客户软件在大多数情况下可不受影响。 

USB同步的例子
 
 

5.10.3 时钟同步

  为了可靠地传输同步数据,前面提到的三个时钟必须同步。如果不这样,就会出现一些不希望看到的时钟间的问题:

•时钟漂移:两个应正常同步的时钟,因为实现上的问题,在走很长一段时间后,可能会走得快慢不一。如果不及时校正,则与其中一个作为标准的时钟相比,另一个时钟就会导致数据过多或过少。
•时钟抖动:由于温度等的原因,时钟频率会发生改变,也造成了数据实际发出的时刻与它被期望发出的时刻不同。
•时钟间相位差异:如果两个时钟不被锁相,由于时钟的错位,在不同的时间点上会收到不一样多的数据。这会造成量化/取样的不真。

  总线时钟提供了一个中心时钟,USB硬件设备和软件可以向它同步。但在大多数PC的操作系统中,仅靠实时调度的支持,软件并不能精确地锁相、锁频到总线时钟上。软件知道USB上的数据是打包的。对同步传输,在一帧内只传一个包,而帧时钟是相对精确的,软件可以凭实际花费的帧时间调整它处理数据的量。

5.10.4 同步设备

  USB为同步设备提供了一个框架,定义了同步类型及同步端点如何提供数据速率反馈,以及同步端点如何被连结到一起。同步设备包括被取样的模拟设备(如:声音设备、电话设备)和同步数字设备。对端点同步类型的分类的依据是它们将自己的时钟同步到与它们相连设备的能力。反馈信息能指出什么是要求的时钟频率。进行连接的能力依赖于想要的连接质量、端点的同步类型,以及进行此连接的主机应用程序的能力。额外的设备级信息是需要的,要多少取决于应用程序。

  注意:数据是个一般性的词,可代表取样过的模拟信号(如声音),也可指抽象的信息。数据速率可以指模拟信号被取样的速率,也可以指数据时钟的速率。

  以下信息用于决定如何连接同步端点:

•同步类型
——异步:不同步、但目的(sink)能提供数据速率反馈
——同步:同步到USB的SOF时钟
——可调:用反馈或feed forward 的数据速率信息实现同步
•可获得的数据速率
•可获得的数据格式

  同步类型和数据速率信息决定了源和目的之间的速率是否匹配,如果有可接受的转换过程存在,就允许它们相连。应用程序有责任决定在可获得的处理资源的限制和其它限制(如延迟)下,是否支持一个连接。具体的USB设备级定义了如何描述同步类型和数据速率。

  数据格式匹配和转换也是需要的,但不是仅对同步连接才要求。关于数据格式转换的细节在其它文件中可找到。

5.10.5 同步类型

  有三个明显的同步类型,表4-7列出了它们各自的端点的同步特征(作为源或目的)。这三个类型的排列是根据它们的能力逐步增强的顺序进行的。

 

目的

异步

自由地安排Fs
提供隐式的feed forward(data stream)

自由地安排Fs
提供显式的反馈(中断通道)

同步

Fs与SOF同步
使用隐式的反馈(SOF)

Fs与SOF同步
使用隐式的反馈(SOF)

可调

Fs与SOF同步
使用显式的反馈(控制通道)

Fs与数据流同步
使用隐式的feed forward(data stream)

 5.10.5.1.1 异步

   异步不能向SOF或其它USB范围内的时钟同步。它们的源和目的的同步数据流都是在一个固定的数据速率上(单数率端点),有一个有限的数据率的个数(32KHZ,44KHZ,48KHZ),或一个 连续的可编程的数据率。如果可编程,是在同步端点的初始化时候进行的,异步设备需在它们的端点描述器中报告自己的可编程能力。数据速率是锁到一个USB的外部时钟或一个内部的自由时钟上的。这些设备将进行速率匹配的任务留给了USB环境中的其它部分。异步源端点通过它们每帧的生产的采样个数隐式地体现了自己的数据速率信息,异步目的端点必须用显式地反馈向一个可调的驱动器说明自己的数据率(见5.10.5.2)。

   异步源的一个例子是CD播放器,它依据自己的内部时钟或共振器来提供数据,另一个例子是数字声音广播(DAB)的接收器或数字卫星接收器(DSR),它们的取样速率取决于广播侧而不是USB的控制,异步目的端点可以是低价格的扬声器,用自己的内部取样时钟。

   另一个情况USB上有两个或更多的设备要求对SOF的产生拥有控制权以便能够作为同步设备运作。例如有两个电话设备,有各自的外部时钟。一个电话可被接到Private Branch Exchange(PBX)上,PBX不与ISDN同步。另一个电话直接接到ISDN上,每个设备向网上产生或接收数据都是用自己的外部驱动速率。因为只有一个设备可获得SOF的控制权,另一个设备的数据速率就只能与SOF异步。这个例子表明,每个有能力控制SOF的设备都可能被迫成为异步设备。

5.10.5.1.2 同步

   同步端点可有自己的时钟系统,但此系统可被SOF同步所控制。这些端点可以:

  •将自己的取样时钟作为SOF时钟(1ms1次)的奴隶(通过一个可编程的PCL)。
  •控制USB的SOF产生速率,显而易见,这样的话,它们的时钟自然与SOF同步。如果这些终点不被给予SOF的控制权,它们降级到异步模式。

  同步端点发出或接收同步数据流的数据速率有以下几种情况。可以使用一个固定的数据速率(单频率端点),或有限个数的几个速率(32KHZ,44.1KHZ,48KHZ),或一个连续的可编程的数据速率。如果可编程,在同步端点的初始阶段进行设定。在一系列的USB帧中产生的采样数或数据单元数是可确定的和周期性的。同步设备须在端点描述器中报告自己的可编程能力。

   同步源的一个例子是数字麦克风。它向SOF同步自己的取样时钟,并在每个帧内产生同样多的声音采样。另一种可能是从ISDN 的“Modem”中来的64kb/s的位流。如果USB的 SOF产生时钟被同步到PSTN的时钟(也许通过同一个ISDN设备),数据的产生也会被同步到SOF,且端点将产生一个稳定的64kb/S的数据流,以SOF时钟为参照。

5.10.5.1.3 可调

   可调的端点是能力最强的端点,它们可以在自己的操作范围内产生和接收任意速率的数据。对可调的源端点来说,数据产生速率是被数据的目的端点所控制的。目的给源一个数据速率的反馈(见5.10.5.2)。这样源就知道了目的要求的速率。可调的端点可以和任何类型的目的通信。对可调的目的端点来说,数据速率的信息是被包含在数据流中的。在一个确定的平均时间段内接收的平均取样数目决定了瞬时的数据速率。如果在操作中,这个数目发生了变化,则数据速率就作出相应的调整。

   数据速率的变化范围是以某个速率为中心(例如8KHZ),它是从几个可编程的速率或自动检测的数据速率(32KHZ,44.1KHZ,48HZ)中选择出来的,速率也可以是一个或几个范围(如5KZ-12KHZ或44KHZ-49KHZ),可调端点也必须在它们的端点描述器中报告自己的可编程能力。

   可调源的一个例子是CD播放器。它包括一个完全可调的取样速率转换器(SRC),所以输出取样的速率不必为44.1HZ,而可以是在SRC控制范围内的任何值。可调目的端点包括高端(High-end)数字扬声器,耳机等。

5.10.5.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。第8章中还会介绍其它的多字节区中定义的位和字节的顺序。

   每帧中,可调源将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调整正确。对时钟的相对漂移,调整也是必须的,这种校正处理的实现与端点有关,不被指定。

   在双向通话的连接中,可调源可以获得可调目的的数据速率,但该源是采用目的端的身分获取此速率的,所以,此时不需要反馈通道。

5.10.6 连接

  连接模型被用来详细描述源到目的的连接过程。这个模型涉及到的各个不同的组成部分及它们如何互相作用来完成连接。

  模型提供了多个源和多个目的的情况,图5-15说明了一个典型的情况(高度浓缩的及不完全的),物理设备通过不同的物理层、软件层接到主机应用软件上(USB说明中描述)。在客户界面层、应用层看到一个虚拟设备。从应用层的角度看,只有虚拟设备存在。物理设备与虚拟设备的关系由设备驱动器和客户软件决定。

 

源与目的的典型连接.png
 
 

  设备制造商(或操作系统销售商)必须提供设备驱动器软件和客户界面软件,以便将物理实现转变为一个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不可得时,速率调节过程只能被模拟一下,即采用漏掉一两个采样或填充一两个采样的方法。此时,连接有可能被建立,但可能会有一个对质量不佳的警告;或者,连接根本不能建立。

5.10.6.3.1 音频连接

  当以上所说的一般连接应用到音频连接上时,RA过程就被取样速率转换所取代,这是一种速率调整的特殊形式。不用错误控制,而用某种形式的取样插补来匹配输进和输出的取样速率。依靠这种手段,谈话的声音质量(扭曲(distortion)、信噪比等)均有很大改善。一般地来说,更强的处理能力带来更好的质量。

5.10.6.3.2 同步数据连接

  在同步数据连接中,我们使用RA。对许多实现了差错控制的应用来说,偶尔的slips/stuffs是可以接受的,差错控制包括差错检测和丢弃(discard),差错检测和重发,或者前向纠错。slips/stuffs的发生速率主要看源的时钟和目的时钟误差的大小,它们是信通上最主要的差错来源。如果差错控制足够强大的话,连接仍可建立)。

 5.10.7 数据预缓存

  USB要求设备在处理和传输数据前要将数据预缓存一下,这样主机在处理各个通道的事务时就具有更大的灵活性。

  设备到主机的传输中,端点必须在帧x期间积累采样,直到收到帧X+1的SOF信号。它将帧x的数据锁到它的包缓冲中,准备好将包含这些取样的包在帧x+1期间发出去。至于在帧内的何时将发送这些数据只能由HC(主机控制器)决定,而且对每一帧的情况可以不同。

  从主机到设备的传输中,在帧Y期间,端点收到从主机来的包。当它收到帧Y+1的SOF信号后,它才可以开始处理在帧Y期间收到的数据。

  这个机制允许端点将SOF令牌用作打入时钟(stable clock),而且抖动和/或漂移都很小。当HC在总线上传包时,这个机制也允许HC可以精确地改变在一帧内何时将包传出。与到每帧的SOF距离相同的总线访问相比,这种预缓存会造成端点准备好数据和数据真正在总线上传输的时间之间的额外延迟。

  图5-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…
 图5-16 数据预缓冲

5.10.8 SOF跟踪

  支持同步通道的应用设备必须要能够接收和理解SOF令牌才能支持预缓存。由于SOF可能会被破坏,所以设备必须能从从被破坏的SOF中恢复。这个限制使得只有高速设备才可使用同步传输,因为低速设备不能发现总线上的SOF。因为SOF包可能在传输中被毁坏,所以支持同步传输的设备需有合成SOF的能力,这个SOF由于总线错误而不能被他们看到。

  同步传输要求适当的数据在适当的帧内被传输。USB要求当同步传输被显示给HC时,它必须指出它的第一帧的帧号。HC不会在指定的帧前开始传第一个事务。如果当前的帧内无事务在等待传输,HC在同步通道上就什么都不传。如果同步传输要求的帧已经过去了,HC会跳过(即不传)前面的事务直到对应当前帧的事务到来。

5.10.9 差错处理

  同步传输不进行数据包的重发(即接收方不发握手信号给发送方),所以数据传输的同步不会被打乱。但数据传输的代理商有责任知道何时发生了一个错误以及该错误如何影响通信流。特别地,对于数据包序列(A,B,C,D),USB有够的信息。所以一个漏掉的包(A, ,C,D)是可以被测的,并且不会在不知道的情况自动变成不正确的数据或时间序列(A,C,D)或(A , ,B,C,D)。协议提供了4种机制来支持这个想法:一帧一包;SOF;CRC以及总线事务超时。

• 同步传输要求在正常的操作中,一帧只能有一个数据事务。USB并不干涉每帧内是什么样的数据。数据发送器(源)决定提供什么样的数据。这种数据每帧(data-perframe)结构很规则,它提供了一个框架,这个框架是丢失数据的错误检测的基础。在总线传输期间事务的任何一个阶段都可能有破坏。第8章将介绍每种错误对协议的影响。
•因为每帧前都有一个SOF,接收器会在总线上看到SOF。接收器可以凭此发现在两个SOF之间,它期望的帧没有出现。特别地,SOF也有可能被破坏,所以设备必须能够重建被漏掉的SOF(见5.10.6)。
•数据包可能在总线上被损坏,所以CRC保护可以让一个接收器发现它收到的数据包是否被破坏了。
•当接收器成功收到一个令牌包后,如果发现有总线事务超时,它可以不再准备去接收数据包。这些细节都在协议中有定义。

  一旦接收器决定不再接收某个数据包,它必须知道被丢掉的这个包的数据长度,才能在做出相应的错误后的恢复。如果每帧的数据流都是一样的长度,这个值就是一个已知的常数。然而,有些情况,帧与帧的数据长度不同。这时,接收器和发送器要有一个机制来决定丢失的包的长度,这个机制是与它俩的具体实现有关。

  总的来说,不管一个事务是否成功地被传输了,接收器和发送器均会以每帧一个事务的速度继续它们的数据/缓冲流。这样才能保证数据在时间上的同步。以上描述的一些机制,用于检测、跟踪、和报告被破坏的事务,让设备或它的客户软件可以对这种破坏以合适的方式做出反应。关于设备和应用对此如何反应是不在USB说明的范围内的。

5.10.10 为匹配速率而做的缓冲

  如果USB上有许多不同的时钟在影响着同步数据流,为了使USB上的数据流的速率的相互匹配,缓冲是必不可少的。设备上的每个端点都必须有缓存。主机上的客户软件也必须拥有缓存,数据在被传输之前可以存放在缓存中。如果已知设备的数据速率,需传的数据包的最大长度就是可计算的,图5-17给出了几个方程,用于决定设备和主机上的缓存大小以及在给定的数据速率下可能出现的最大包长。
 


4-17进行速率匹配的同步传输的包长和缓冲大小的计算
 

  设备和客户软件利用这些方程来设计服务时钟速率(变量x),取样时钟速率(变量C),和取样的长度(变量S)。USB只允许一个总线时钟对应一个事务。这些方程提供的信息可成为端点选择合适的包长,或信息/端点和它的客户软件选择合的缓存的依据。图5-14就是了一个典型的同步例子的实际缓存值、包长、时钟值。

  USB数据模式认为设备有自己的取样的大小和取样的速率。USB支持包的传输,这个包应当是取样长度的整数倍,这样有利于对总线上被损坏的同步事务的错误恢复。如果一个设备没有固有的取样长度或它的取样长度超过了一个包的长度,它应将它的取样长度描述为一字节。如果一个取样被分为几个包,当任一个包被丢掉后,对错误的恢复比一般情况要困难。在有些情况中,数据同步会丢失,除非接收器知道取样的各个部分将在帧号为几的帧中被传。而且,如果由于时钟校正造成取样的个数发生变化(例如一个non-derived的设备时钟),将很难知道取样的一个部分何时被传,因此USB不会将一个取样分几个包传。
 

展开全文
------分隔线----------------------------
百合电子工作室版权所有
Copyright @ baiheee electric studio
渝ICP备09006681号-4
联系方式




-->