usb中断传输的真实含义

呵呵。大家好！
 ;)
我想请教一个问题：
usb中断传输，调用函数UsbBuildGetInterruptOrBulkTransferRequest
后，数据是怎样通过底层软件的轮询，被传输到缓冲区的。
是不是上层驱动程序完全不需要关心这个轮询的过程？
轮询过程已经被完全封装了？

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

回答的好！！又是两位高人。

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传输。

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

对于控制传输，通常没有数据阶段传输的要在50ms内完成，如果有数据阶段则第一个数据包要在500ms内发送给主机，之后的一次增加500ms
对于批量传输，如果驱动程序没有超时控制，则什么时候响应都行
如果有则要在超时控制的时间范围内完成
对于中断传输，和批量传输基本一样
对于ISO传输，应该是立即响应吧，要不然怎么能保证同步数据流呢？

 

对于控制传输，通常没有数据阶段传输的要在50ms内完成，如果有数据阶段则第一个数据包要在500ms内发送给主机，之后的一次增加500ms
对于批量传输，如果驱动程序没有超时控制，则什么时候响应都行
如果有则要在超时控制的时间范围内完成
对于中断传输，和批量传输基本一样
对于ISO传输，应该是立即响应吧，要不然怎么能保证同步数据流呢？

有道理。
iso传输在竞争带宽的时候，容易获得成功。iso传输
最大可获取90%的可用带宽。在这种情况下，需要iso传输
的另外一个设备的传输请求有可能会失败。

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卡的问题。

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

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

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

有启发，谢谢各位！

windrv,我觉得pengenwen说的"在中断传输中，驱动一般需要维持一个永不完成的URB，以便驱动不断地从固件查询数据，然后通过事件方式通知应用程序"没有什么不对的啊，通常在usb驱动中处理中断传输都可以用这种实现方式的啊。我觉得他说的东西跟你说的不是一个侧重点。在Oney的书中也是用的这种方式。
想请教您一个问题，中断传输只能获取in的数据么？如果我有host向usb设备发出的用户数据，但是usb设备只有一个控制端点和2个interrupt端点，能否实现out数据？谢谢！

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