一个关于bulk的问题

cypress的技术文档中这样说：当用bulk管道传输数据时,(假设firmware由于某些原因,比如时序配合,本身错误或硬件缺陷),bulk端点的数据没有准备好时,不能及时响应来自主机的IN数据请求,主机就会得到来自设备的NAK,并重发这个请求.请问这个重发的机制是由USB规范决定的,还是由用户驱动程序决定的.如果始终没有数据来应付这个请求,这个重发会延续到什么时候?可不可以在第一次(或确定的次数)得到NAK时就放弃继续请求?
因为在调试阶段经常会碰到各种错误,如果仅仅是因为时序配合,可能要等待一点时间,是觉察不到,这很正常,如果一直没有准备好数据上传,就会一直等待,跟死机一样,需要重启主机,不胜其烦.请问大虾们:可否在驱动程序中解决这个问题，怎样解决？呵呵,莫对我说"你把firmware和硬件都搞对不就结了"哦。
还有一个问题：cypress的AN2131QC最多能在一祯传输17个bulk包，我想每次从设备请求640字节的数据,会分成10个包传上来（10*64），请问，在没有其他USB设备时，这10个包是否确保在一祯里（1ms）就能传完?是否能由驱动程序控制每祯必须传n个数据包？
请大虾们不吝赐教。
[sunkai 编辑于 2001-08-20 20:40]

顶上来~

继续讨论啊。


sunkai 的星星和帖子数真是一绝~
 :D

好老的帖子，不知道有那位高手解决了，可以谈谈么？

我作了超时，可是更错了。请看后一个帖子。
各位想写驱动的朋友，如果只写bulk传输，也可以看看，这是最主要的部分，除了容错能力差了点，这个驱动倒没有什么不好的地方。

算了，终于回到了开始我说的，把设备和firmware搞清爽点，尽量不出任何错误，实在要死也没有法子，大不了再开机，正好休息片刻，闭目养神。*_*,:(.

[QUOTE]原本由 sunkai 发表
[B]大侠们，睡醒了发个话呀。 [/B][/QUOTE]
你这种情况，多数是firmware那头没有准备好数据。你们通讯的时序上可能有问题。
超时，就是弄个事件等待。具体的代码，你可以参考DriverWorks的源代码-KUSBLowerDevice::SubmitUrb

大侠们，睡醒了发个话呀。

[QUOTE]原本由 eric_ti 发表
[B]可能你的设备没有发出NAK信号，致使Event信号量没有被激活，你应当设一个Timeout机制，来防止Iocalldriver不成功时，driver死锁。 [/B][/QUOTE]
这就不好玩了,发NAK是规范定的,不发是USB两端的设备的错,不是我能控制的,按道理说应该不会出现这种不可预料的情况吧?
我对驱动编程一知半解,能否具体给出点代码来?谢谢啦

[QUOTE]原本由 rayyang2000 发表
[B]给你的urb设置一个超时，比如1秒钟，让它过时不候。 [/B][/QUOTE]
我看到驱动程序里有个KeWaitSignalObject(),是在这里设置吗?多谢版主.

[QUOTE]原本由 rayyang2000 发表
[B]给你的urb设置一个超时，比如1秒钟，让它过时不候。 [/B][/QUOTE]

但我怎么超时后引起“Blue Screen of Death”。

可能你的设备没有发出NAK信号，致使Event信号量没有被激活，你应当设一个Timeout机制，来防止Iocalldriver不成功时，driver死锁。

给你的urb设置一个超时，比如1秒钟，让它过时不候。

[QUOTE]原本由 shb 发表
[B]这个NAK是由USB规范规定的，USB1。0规定一般是是重新请求3次，如果全部不成功，就会停止，它不会一直请求。 [/B][/QUOTE]

请求3次大概需要多长时间？？

[QUOTE]原本由 rayyang2000 发表
[B][QUOTE]原本由 sunkai 发表
[B][QUOTE]原本由 shb 发表
[B]这个NAK是由USB规范规定的，USB1。0规定一般是是重新请求3次，如果全部不成功，就会停止，它不会一直请求。 [/B][/QUOTE]

shb:
既然不成功就会停止倒也不算是坏事,但是现在我的情况是,不成功便成仁了,死翘翘的,只得重新启动机子,这是什么原因导致的?(用bulk方式传送时发生的) [/B][/QUOTE]
说明host给device发in的时候，device根本就没有准备好数据。你应该保证device在收到in token之前就已经准备好了数据。 [/B][/QUOTE]


班主，你说的也是，一个最后的成熟的设备是肯定会有数据供应的，但在开发阶段，也有的确没有数据供应的时候，一般都会碰到这种情况的。比如说，USB接口和设备分开做的时候，USB从主机供电，设备另备电源，当忘了给设备上电时，是无论如何没有数据来源的。如果这个时候去IN一把，就出现了我说的那个情况了，死了！当然这可以避免，但是还存在很多其他的原因能导致这个状况，一次次地重新启动机器急都急死了，最好是能解决根本问题，做到：我去IN，不是没有数据吗？行，没有就算了，正常返回，告诉我一个什么错误信息就是了，别死在里面。我想班主是个驱动高手，怎么解决这个问题？我用SOFTICE跟进去过，的确是进了死循环，汇编码我看不懂了。
有个哥们不是说过NAK3次就回来吗？怎么我就这么倒霉。BULK是保证数据的正确性，但也不能太较真啊。

[QUOTE]原本由 sunkai 发表
[B][QUOTE]原本由 shb 发表
[B]这个NAK是由USB规范规定的，USB1。0规定一般是是重新请求3次，如果全部不成功，就会停止，它不会一直请求。 [/B][/QUOTE]

shb:
既然不成功就会停止倒也不算是坏事,但是现在我的情况是,不成功便成仁了,死翘翘的,只得重新启动机子,这是什么原因导致的?(用bulk方式传送时发生的) [/B][/QUOTE]
说明host给device发in的时候，device根本就没有准备好数据。你应该保证device在收到in token之前就已经准备好了数据。

[QUOTE]原本由 yalong 发表
[B]我最近一直在做USB，得到的一些结论和大家差不多，但也有一些自己的看法，可以一起讨论！
 1、51的速度肯定影响USB的传输速度，你可以测算要达到USB的实际速度（约1MB），在每一桢要传输1K的数据，那么平均到一个包（64字节）时间就是小于64ms，只有在这么短的时间内处理完所有数据，你才可以达到1M的速度。51才多快啊！等到中断，然后查询然后再去取数据。。。。。。所以，一个瓶径就在这。

 2、我用51和9603处理过，只收数据不处理，最快也就不到400KB，现在用DSP做了一下，可以到500KB，但也是不理想。再加上数据处理的程序，还要打很大的折扣！

 3、在USB。ORG上曾看到过说驱动也会影响数据传输速率，但具体怎么搞由于不是很清楚软件所以没有深入思考，但我觉得应该可以研究的！
 4、上面有说NAK的处理，对CONTROL来说，一般是三次，如果全错就不处理了！枚举的时候就能看出来这个过程！ [/B][/QUOTE]

1    我从CYPRESS的文档上看到一个不同的说法:系统瓶颈在HOST,而不在USB片子.我的感受也是这样的,数据到了HOST是要用的,一点不处理要来干什么?现在我就是这样,一边要数据,一边处理数据,还拿不准一次要多少合适,还好,可以先用个FIFO存点数据.

2    大哥,用DSP也只有区区500KB,不至于吧,你这么一说搞得我都对DSP没什么兴趣了.

4     为什么我用BULK来IN数据时,如果IN请求好象始终在等待,连个错误都不给报回来?只有重新启动机器才能再使用USB,真是不得其解.

[sunkai 编辑于 2001-09-03 17:10]

[QUOTE]原本由 shb 发表
[B]这个NAK是由USB规范规定的，USB1。0规定一般是是重新请求3次，如果全部不成功，就会停止，它不会一直请求。 [/B][/QUOTE]

shb:
既然不成功就会停止倒也不算是坏事,但是现在我的情况是,不成功便成仁了,死翘翘的,只得重新启动机子,这是什么原因导致的?(用bulk方式传送时发生的)

[QUOTE]原本由 yalong 发表
[B]我最近一直在做USB，得到的一些结论和大家差不多，但也有一些自己的看法，可以一起讨论！
 1、51的速度肯定影响USB的传输速度，你可以测算要达到USB的实际速度（约1MB），在每一桢要传输1K的数据，那么平均到一个包（64字节）时间就是小于64ms，只有在这么短的时间内处理完所有数据，你才可以达到1M的速度。51才多快啊！等到中断，然后查询然后再去取数据。。。。。。所以，一个瓶径就在这。
 2、我用51和9603处理过，只收数据不处理，最快也就不到400KB，现在用DSP做了一下，可以到500KB，但也是不理想。再加上数据处理的程序，还要打很大的折扣！
 3、在USB。ORG上曾看到过说驱动也会影响数据传输速率，但具体怎么搞由于不是很清楚软件所以没有深入思考，但我觉得应该可以研究的！
 4、上面有说NAK的处理，对CONTROL来说，一般是三次，如果全错就不处理了！枚举的时候就能看出来这个过程！ [/B][/QUOTE]
4。 枚举的时候是3次retry。但在不枚举的时候，如果用Control Transfer传输数据，根据我在USB分析仪上看到的结果，是一直retry的，而且在Win98和2K下都是如此。

我最近一直在做USB，得到的一些结论和大家差不多，但也有一些自己的看法，可以一起讨论！
 1、51的速度肯定影响USB的传输速度，你可以测算要达到USB的实际速度（约1MB），在每一桢要传输1K的数据，那么平均到一个包（64字节）时间就是小于64ms，只有在这么短的时间内处理完所有数据，你才可以达到1M的速度。51才多快啊！等到中断，然后查询然后再去取数据。。。。。。所以，一个瓶径就在这。
 2、我用51和9603处理过，只收数据不处理，最快也就不到400KB，现在用DSP做了一下，可以到500KB，但也是不理想。再加上数据处理的程序，还要打很大的折扣！
 3、在USB。ORG上曾看到过说驱动也会影响数据传输速率，但具体怎么搞由于不是很清楚软件所以没有深入思考，但我觉得应该可以研究的！
 4、上面有说NAK的处理，对CONTROL来说，一般是三次，如果全错就不处理了！枚举的时候就能看出来这个过程！

[QUOTE]原本由 shb 发表
[B]这个NAK是由USB规范规定的，USB1。0规定一般是是重新请求3次，如果全部不成功，就会停止，它不会一直请求。 [/B][/QUOTE]
是吗？以前观察Control Transfer的时候，发现host会一直等待的。
如果这样停止的话，host得到的错误代码是不是0x17(CRC错误)？