转载自http://blog.163.com/zhsh_email/blog/static/19786900200611259521640/
usb作为一种串行接口，应用日益广泛。如同每个工程设计人员必须掌握I2C,RS232这些接口一样，我们也必须掌握usb.
但是usb的接口协议实在有点费解，linux uhci驱动作者之一Alan Stern曾经就说过“The USB documentation is downright evil. Most of it is just crap, written by a committee. You're better off ignoring most of it ”。
本文将从整体上介绍usb协议，包括usb host ,usb hub,usb function。希望能给读者一个总体上的了解。也因此，文章将分成相应的三部分讲解 。
一。usb function
1。初识usb.usb是一种串行接口协议，它靠d+,d-两条数据线构成的差分线来进行数据传输，这让我们非常感兴趣它到底和我们通常熟悉两线rs232/485有何区别。了解这种区别有助于我们对usb作一个深入的了解。那么让我们回想一下到底一个两线rs232的数据是如何传送的，如图一：
在这里我们的重点在于，我们发现要在串行口传送数据一个最体码的要求恐怕就是：要知道数据传输何时开始，何时结束。即如何delimit.那么rs232怎么做的。显然，在idle（空闲）时，即无数据传送时，数据线处于高电平，等到有数据开始传送，发送方首先拉低数据线（start)，表示数据传输开始，接受端也因为这个“start”信号开始准备接受即将到来的数据，类似一次握手，随后，在两者之间的数据传送开始，结束后主方再次拉高数据线，表示结束传输，自此两者重新进入Idle状态。等待下一轮传送开始。
了解了rs232,那么我们自然想到usb如何做到这个呢，既然是串行位流传输，也理所当然的解决这个问题。没错，Usb协议必然要解决这个问题，让我们作一个类似rs232的比较吧！类似于rs232,usb的传输桢如图二：
（这里我们暂时忽略这个传输所代表的意义）为了说明问题，我们对一些问题简化，我们定义这样几个状态：
假设D+,D-分别表示usb信号线的电平信号。那么对于usb full speed function(high speed ,low speed是不同的),我们定义差分数据线上可能出现的四个状态：
Data J state:D+=1，D-=0；
Data K state:D+=0，D-=1；
SE0：D+=D-=0;
SE1：D+=D-=1;
那么上面的图中，相应的也可表示为图三：
这个对usb full speed function来说，idle状态将处于Data J state，se0表示一桢结束。看这个图是不是很像我们熟悉的rs232。没错！！！他们确实很相似。在无数据传输时，它们都处于Idle状态，当要开始传输数据时，先发一个sync(同步信号，rs232为start,usb为一sync字节，见协议说明）信号进行“握手”，而后开始传输，当传输要结束时，发一stop信号（usb为一个se0状态表示要结束传输），最后又进入idle态等待新的传输。不过，你可能更加注意到，他们还是不同的。不同在于usb是按"packet" 进行传输的，就是说它传输的最小单位是packet，而rs232是按字节传送的，也即它的最小传送单位是字节。既然是按pakcet传送，想想我们相较于rs232的按字节单位传输，我们可以得到哪些“好处”。想想看，pakcet的好处不就在于我们可以灵活的定义数据的传送格式，传送方式，从而可以适应各种各样的串行设备，这不就是所谓的“通用串行总线”吗？
简介：从本节开始，我们将介绍usb的传输机制。这节先介绍usb现有传输方式的背景知识，做为对下节将要展开的四种传输类型，描述符，等相关知识的一个导引。
2。usb传输。
我们在上一节中了解到了usb的“packet”的感念，了解到了usb传送一个packet总是以sync开始，以eop结束，这个称为delimiter,即标记packet的始末。有了packet，我们就可以在usb总线上传输数据了。但是这还不够，比如数据传送方向，即传回usb主机还是传下usb从机，数据传送的地址，数据传送的类型（这些后面我们将会知道）这些信息在传输之前是必须搞清楚的，那么这个信息如何得知呢，看来这就需要我们定一套基于packet的“协议”了。主机与从机在传输中均遵循这套“协议”，那么这些问题就可以迎刃而解。事实上，usb的一次数据传输总是遵循这样的“协议”的:
首先，主机发第1个packet给从机，声明数据传送方向，数据传输地址，数据传输类型。
其次，主机发第2个至第n个packet载有实际数据
最后，从机返回一个packet是一个ACK包，报告数据传输的结果，比如接受出错或成功等信息，这样主机就可以借此了解到这次传输情况，从而有可能来作出相应措施如决定是否重发。
这里我们考虑的是主机发数据给从机的情况，那么从机发数据给主机时，是不是也可以这样呢？当然可以，比如从机要发数据给主机时，也可以采取同主机类似的方式：
首先，从机发第1个packet给主机，声明数据传送方向，数据传输地址，数据传输类型。
其次，从机发第2个至第n个packet载有实际数据
最后，主机返回一个packet是一个ACK包，报告数据传输的结果，比如接受出错或成功等信息，这样从机就可以借此了解到这次传输情况，从而有可能来作出相应措施如决定是否重发。
基本上可以归结为一个“三段式”传输
这里有人可能注意到了，对这样一个传输机制，从机和主机的功能将是一样的，因为这样的实现机制，从机可能在某一时刻是主机，某一时刻又可能是从机，因为他们要实现同样的功能。这样实现起来的复杂性也将是一样的。
注：这里概念或许容易混淆，其实，我们这里的主机(master)和从机(slaver)是一个transceiver,即可收可发。相应的，在某一时刻，master在发数据，我们称其为transmitter,在接受时我们称为receiver.对slaver同样。
我们可能还注意到了,usb这种按pakcet传输的方式在实现时已经很复杂了（至少比rs232要复杂多吧），至少我们目前看来主从机功能一样这样的实现方式似乎还是可行，但是后面我们谈到usb host时将会了解到host的功能是如何的复杂，以至于让一个usb function 也带上如此的功能成本和实现复杂性将陡然上升。作为面向广范应用的usb，这是我们不允许的。我们期望的是一个使用usb 的udisk,使用usb的光驱，使用usb的耳麦等等这些东西不要因为usb而变得昂贵，复杂。
正是因为这个原因，usb从机的传输发式便由上面的方式改成了下面的方式进行：
首先，主机发第1个packet给从机，声明数据传送方向，数据传输地址，数据传输类型。
其次，从机收到主机送来的第一个packet后，再发第2个至第n个packet载有实际数据
最后，主机返回一个packet是一个ACK包，报告数据传输的结果，比如接受出错或成功等信息，这样从机就可以借此了解到这次传输情况，从而有可能来作出相应措施如决定是否重发。
而对于usb 主机传输方式保持不变。
对于这样的改变，我们马上就有疑问了：这个改变的传输方式是和未改变之前的等价吗。当然，不全等价。问题在哪里？仔细观察一下便知，两者区别在于第一个packet是由谁发起的。未改变之前，第一个packet总是由要传送数据的一方发起，而改变之后的第一个Packet总是由主机发起。这样，就变成如果从机要发送数据给主机时，总是由主机发起（第一个packet),然后从机开始传送。
可能初次接触我们会感觉怪怪的，怎么从机要给主机发送数据前反而要主机先发packet给从机。 这样行吗，我们要说这样是可以的，因为通常一次传输交互的产生，并非无来由的产生，这些都是由程序员控制的，控制usb何时收，何时发，及发给谁！！！
这里我们就注意到了，usb function(总是作为从机）的功能一下从原来与主机具有相同功能的tranceiver变成了现在仅具发送（或接收）功能的transmitter（或Receiver）实现的复杂性及成本可想而知也就相应得减小了。
简介：本节介绍usb full speed function的四种传输类型。
上节中我们了解到了usb host 与usb function 之间采用的是一种“非对称”的传输，也就是说，无论usb接受数据还是发送数据，都是由usb host首先发起。即传输的第一个packet总是由usb host发出的。这个packet将声明本次即将进行的数据传输方向，数据传输地址和数据传输类型。
: 或许你已经注意到了，一个usb host端口并不是仅仅支持一个Usb function.如图1，
通过usb hub,一个usb host端口可以连接usb鼠标，usb键盘，Usb写字板......。要连接这么多东西在同一个usb host上，我们通常会有一个基本问题，即usb host如何识别这些被连接在它的端口上的设备呢。正如通常的主从式通讯系统一样，如rs485多机通讯,我们通常是用一个特定的地址标志每一个从设备。对这里的usb,我们采用同样的方法，将为每个挂接在该usb host上的usb function指定一个特定地址，通过这个特定地址来识别每个usb function.看来这将是一个usb function在数据传输之前必须解决的问题--得到它的地址分配。
这个“地址指定”的过程需要usb host通知usb function才能完成，这个交互过程就是一个控制式传输。通过这个“控制式传输”，usb host将指定地址给usb function ,以为即将进行的正式通讯做好准备工作。这里细心的读者可能已经注意到了，既然usb host总要分配地址给usb function才能进行正式的数据传输工作，那么usb host将如何与一个初始时未分配地址的usb function进行交互来分配地址呢。这里，是这样解决的：usb协议保留了一个“通用地址”0,usb host 通过这个地址0来和初始未分配地址的usb function进行通讯，进行一些初始的准备工作，诸如这里的为它非配一个特定地址。后面我们就会了解到，usb除了配置地址外，还有一些其它参数需要事先主从双方达成共识。这些参数也都是通过控制式传输完成的。一个Usb 的控制式传输如图二示：
一个Usb的控制式传输总是分为两个或三个阶段进行传输：setup stage,data stage（视情况而定）,status stage。
如此，整个控制式传输结束。 你或许有疑问，data stage为什么进行了多次而非一次完成？实际上，usb总是将一批大量的数据分成了许多小段来进行传输，称为一个pay load。这样传输的目的是容易对传输进行控制。既然一次大量的数据总是被分成一段一段来分次传输，那么这里就出现了一个需要事先确定的参数（wMaxPacketSize）：即每次这个小段有多大。这个参数如地址指派一样，正式传输之前需要事先达成共识。通过控制式传输，现在我们已经完成了usb function的地址指定等参数的设置工作，下一步可以进行正式的数据传输了。
我们终于等到usb function 配置完成，现在我们的任务是要传送一批数据,这里可以使用批量数据传输(bulk Transactions)。 一个批量传输总是按照如图所示方式进行，
这里的疑问依然是为什么一次可能传完的数据为什么分成多次进行传输,原因在上次介绍控制式传输式已经说明。后面我们就会明白，为什么这样可以方便控制传输过程。 仔细看看控制式的data stage采用的传输方式，是否就是批量传输方式呢？！注意，每次payload data的“牵头人”（preamble)在轮番掉换，最先是data1,接着data0,再是data1,......如此接替，只要有一次交互出现问题，这个接替规则就会被打破进而被Usb host识别而发现传输异常。所以这个交替的“牵头人”规则是可靠数据传输的所采取的措施之一。
在批量数据传输中，触发一次批量数据传输总是“被动”的，就是说需要数据传输时Usb host并不会主动发起传输，而是需要得到你的指令。当你告诉它：“一切ok，让我们开始吧！” 这时它才开始数据传输。这种方式显然在某些情况下并不适合。比如音视频流，你无法要求它听从你的“指挥”，让它等你发指令给usb host,然后开始一次传输。我们需要的是一种“及时”传输。一个好的方案就是设置一个timer,按照tick发起usb传输。这个tick通常以1ms(usb full speed)为最小单位。这时，可以设置为每次1ms tick出现，usb host“自动”发起一次数据传输。那么这种方案具体如何来实现呢？看来最基本的要素便是一个发出tick的timer，而这个“timer”需要usb host和usb function（事实上还要包括usb hub)双方均能“看到”，从而协调工作，否则单方面的timer又有何意义？这个"timer"(或tick)在usb中使用一个特殊的packet实现，即是SOF。这个SOF由USB HOST 相当精确的以每1.00 ms ±0.0005 ms的时间周期发送给usb device，来在二者之间定时。从而usb function能够“及时”的了解到“现在时刻”。 现在我们在usb host和usb function之间建立起了“对时”机制。那么接下来看看刚才设想的“自动”传输如何实现。事实上，一旦usb host及usb function双方建立了一种时间机制，那么这种“自动”传输是很容易实现的。usb 实现同步式传输或中断式传输总是以一种类似于批量数据传输的方式进行的，唯一不同的是传输的触发不再是“被动”的，而是由SOF所建立的tick触发。
如此重复上述步骤,即usb host等待下一个tick到达，并开始新一轮的交互。
这里我们注意到了，同步式传输和中断式传输二者虽然都是时间触发，但是中断式传输需要ack应答，而相反，同步式传输不需要。这个最大的区别决定了同步式传输是一种非可靠传输，但是因此换来了更多的usb传输时间。也因此,同步式传输的 payload data（对应wMaxPacketSize ）通常相较于其他传输方式比较大,因为它消掉了ack所占有数据传输时间。这里还有一个地方值得注意的是tick的设定，这个tick也是需要事先usb host 和usb function达成共识的参数之一。
