USB相关知识学习随记－相继更新

从USB基础到完整驱动开发...

1 USB标准

在新的USB2.0标准中，USB1.1的说法已经不复存在了，都被统称为USB2.0，在它下面又细分三种规格：Low-speed，Full-speed，High-speed 。乍一看这三种接口都是USB2.0但他们的传输速率相差甚远，USB2.0 Low-speed主要用于键盘，鼠标等设备，它的传输速率只有1.5Mbps；USB2.0 Full-speed就是曾经的 USB1.0，他的传输速率理论上可以达到12Mbps，适用于一些对数据传输要求不高的设备的接口； USB2.0 High-speed 才是真正意义上的USB2.0，他的传输速率理论上可达到480Mbps。

2. USB中断传输的精彩讨论

Escape ：

呵呵。大家好！ ;)

我想请教一个问题：

usb中断传输，调用函数UsbBuildGetInterrupt or BulkTransferRequest

后，数据是怎样通过底层软件的轮询，被传输到缓冲区的。

是不是上层驱动程序完全不需要关心这个轮询的过程？

轮询过程已经被完全封装了？

Jinghuiren：

对的，当你调用了IoCallDriver()后，底层驱动会按照你设置的轮询间隔（比如1ms），向设备发送in或者out令牌，直到本次调用的数据全部完成（比如64k）后返回操作方式和批量传输完全一样。

Pengenwen：

在中断传输中，驱动一般需要维持一个永不完成的URB，以便驱动不断地从固件查询数据，然后通过事件方式通知应用程序。

Windrv：

pengenwen 说的不对。

USB是共享总线，如果在USB HUB上有多个设备同时进行大数据量传输。例如设备A在传输4MB的数据，那么设备B在设备A数据传输期间有可能得不到响应。如何保证设备B在其它设备传输数据时也能及时得到响应？设备B可以设立中断传输端口，这样Host Controller会每隔一定的时间间隔(例如1ms)，保证向设备B发出IN令牌，使得B有机会发出数据。

所以中断传输的数据量不能太大，在USB 1.1中最多只能16 bytes.

USB 2.0的协议作了一些修改，中断传输与Bulk传输的区别不大，数据量的限制也没有了。不过，中断传输的上述机制还是在的。

如果USB的host controller总是被一个设备独占，那也就没有中断传输与Bulk传输的区别了。

至于pengenwen说的是USB设备驱动程序上的实现技术，与中断传输的特点无关。事实上，这个“永不完成的URB”也可以用来读Bulk传输。

Lejianz：

请教windrv一个问题，在固件编程时，USB通信一般通过外部中断来实现，如果我在做某些工作时，不能及时响应此中断，那么不响应这个中断的时间有多长？我知道总线如果在3ms里没响应，将会挂起，这段时间是否跟中断传输有关？

Jinghuiren：

对于控制传输，通常没有数据阶段传输的要在50ms内完成，如果有数据阶段则第一个数据包要在500ms内发送给主机，之后的一次增加500ms

对于批量传输，如果驱动程序没有超时控制，则什么时候响应都行

如果有则要在超时控制的时间范围内完成

对于中断传输，和批量传输基本一样

对于ISO传输，应该是立即响应吧，要不然怎么能保证同步数据流呢？

Escape：

对于控制传输，通常没有数据阶段传输的要在50ms内完成，如果有数据阶段则第一个数据包要在500ms内发送给主机，之后的一次增加500ms

对于批量传输，如果驱动程序没有超时控制，则什么时候响应都行

如果有则要在超时控制的时间范围内完成

对于中断传输，和批量传输基本一样

对于ISO传输，应该是立即响应吧，要不然怎么能保证同步数据流呢？

有道理。

iso传输在竞争带宽的时候，容易获得成功。iso传输

最大可获取90%的可用带宽。在这种情况下，需要iso传输

的另外一个设备的传输请求有可能会失败。

Windrv：

USB是主从通讯模式，由Host controller控制何时与哪个设备的哪个端口通讯。当它需要从某个EP读入数据时，它会发一个IN令牌给此端口。端口收到令牌后，必须在某一时间间隔内把数据发给Host Controller然后返回一个"OK"令牌；如果端口在此时间内无法返回数据，也必须返回一个NAK令牌，那么Host Controller下次会继续发IN令牌给此端口。如果端口在此时间间隔内没有任何令牌返回，Host Controller会把这端口标为STALL，下次不再查询此端口。

对于lejianz所说的问题，我觉得firmware在做某些工作时，在3ms内没有返回NAK token以响应总线的IN token，所以被总线挂起，即STALL。 不过，挂起了也还可以用ResetPipe()恢复此端口。

EZUSB做的比较好，它的USB core在数据没有Ready的时候会自动返回NAK令牌，不占CPU的资源。所以，在批量/中断传输时，什么时候响应都行。

不过，对于这类总线挂起的问题，最好用总线分析仪去监测一下。Host Controller的生产厂商不一样，有时候是USB卡的问题。

Lejianz：

谢谢windrv大侠的精彩答复，按大侠所说，如果EZUSB设备的一个IN令牌包传输过程中，SIE能自动发也NAK，而不是STALL，那么我可以在很长一段时间里不响应此IN中断，因为有NAK说明设备在忙。这也印证我在ICE仿真时，当在中断里下断点时，设备管理器里的设备不会消失。但我想这段时间并不是jinghuiren大侠所说的500ms时间，我一直没有找到相关的叙述。windrv大侠能否再看一下。

Windrv：

只要设备能回应NAK， 读数的URB等多长时间都没有问题，通讯不会断掉。在我们的应用中，读数的URB经常会等好几个小时。

不过，你说的设备在设备管理器里消失是另外一个问题。即使EP被STALL，USB 的设备对象还是在Windows系统里的，不会消失。

Mboma：

windrv,我觉得pengenwen说的"在中断传输中，驱动一般需要维持一个永不完成的URB，以便驱动不断地从固件查询数据，然后通过事件方式通知应用程序"没有什么不对的啊，通常在usb驱动中处理中断传输都可以用这种实现方式的啊。我觉得他说的东西跟你说的不是一个侧重点。在Oney的书中也是用的这种方式。

想请教您一个问题，中断传输只能获取in的数据么？如果我有host向usb设备发出的用户数据，但是usb设备只有一个控制端点和2个interrupt端点，能否实现out数据？谢谢！

Metalwing：

WINDRV又见你了,想问你个问题.

我的板子在20MHZ(DMA读写)频率下很正常,可是我把频率提到40MHZ就不行了,无法接到总线上DMA数据传输到的中断,也无法接到DMA传输完成的中断(DMA一直在传输),我用的是ISP 1581芯片.是否是51的处理频率(12MHZ,一个工作周期是1微秒)跟不上?