一个关于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]

你的driver是自己写的，还是用的microsoft 提供的USB driver

[QUOTE]原本由 Danny 发表
[B]你的driver是自己写的，还是用的microsoft 提供的USB driver [/B][/QUOTE]

microsoft 提供的USB driver 有什么明显BUG?
另外，cypress提供的GPD能满足这个吗？
谢谢

关于 Microsoft USB Driver 的问题。
我不确定Microsoft USB Driver 是否有Bug，但我有明确的根据证明这个Driver 它从不发In Token 给 Device。

用过cypress的东西的大虾闷请注意了,我用的是cypress提供的GPD,行不行?当向一个没有数据上传的设备发请求包时,驱动程序就死在EzUsb_CallUSBD()中的KeWaitSingleObject()那里出不来,难道删掉这一句吗?

楼上的兄弟们,给点答案好不好?不要也跟着问嘛.谁要是帮我搞清了这些问题,我请他喝茶.

谢谢RY2000斑主指点.
你们不觉得我提的这个问题很重要?要做一个要求严格时序的大数据量的采集系统的传输接口,谁都不能躲过这个问题.
USB1.0的带宽是12Mb/s,CYPRESS的AN2131QC的BULK传输在理论上可以达到8Mb/s多的有效数据,我在这里看到有人说:每祯就只能传一个bulk包,最多就是64B,bulk传输太慢了云云.这样理解肯定是不对的,这不是问题,关键是,凡是做数据采集卡的同行们,你们是怎么考虑和解决我前面提出的那个问题的?理论上能做到,实际上并不一定,因为一个完整的系统不光只是把数据传来传去,还要进行若干处理等等,所以人为的控制是必要的.请有经验的指教.

[QUOTE]原本由 sunkai 发表
[B]谢谢RY2000斑主指点.
你们不觉得我提的这个问题很重要?要做一个要求严格时序的大数据量的采集系统的传输接口,谁都不能躲过这个问题.
USB1.0的带宽是12Mb/s,CYPRESS的AN2131QC的BULK传输在理论上可以达到8Mb/s多的有效数据,我在这里看到有人说:每祯就只能传一个bulk包,最多就是64B,bulk传输太慢了云云.这样理解肯定是不对的,这不是问题,关键是,凡是做数据采集卡的同行们,你们是怎么考虑和解决我前面提出的那个问题的?理论上能做到,实际上并不一定,因为一个完整的系统不光只是把数据传来传去,还要进行若干处理等等,所以人为的控制是必要的.请有经验的指教. [/B][/QUOTE]
以前一直没有做大批量传输数据的实验，这两天做了一下，在我的系统中，现在能做到的速度是16kbyte/s。这个速度是指从firmware/hardware一直到windows app之间的传输。
是不是很慢啊？:) 当然我也想改进，但一个是苦于没有设备，还有就是现在没有时间了。

我这段时间也在做BULK的传输试验，也只能达到30KB/S左右而已。
我用的是PHISIPS的PDIUSBD12，我的做法是在EndPoint5的中断
服务中重复发送一个64字节的包，void main_txdone(void)
{
D12_ReadLastTransactionStatus(5); /* Clear interrupt flag */

if(MCU_SWM2)
D12_WriteEndpoint(5,&MSG1,sizeof(MSG1));

num1++;
}

PC机上是用WINDRIVER生成的测试程序
这样的速度也太慢了，不知是MCU的速度跟不上还是处理方法有误或是PC机软件慢了？我的机是CII566　64MB、WIN98SE，USB用是是PHILPS的D12　USB－EPP　EVALUATION　MAIN　BOARD

[QUOTE]原本由 sunkai 发表
[B]谢谢RY2000斑主指点.
你们不觉得我提的这个问题很重要?要做一个要求严格时序的大数据量的采集系统的传输接口,谁都不能躲过这个问题.
USB1.0的带宽是12Mb/s,CYPRESS的AN2131QC的BULK传输在理论上可以达到8Mb/s多的有效数据,我在这里看到有人说:每祯就只能传一个bulk包,最多就是64B,bulk传输太慢了云云.这样理解肯定是不对的,这不是问题,关键是,凡是做数据采集卡的同行们,你们是怎么考虑和解决我前面提出的那个问题的?理论上能做到,实际上并不一定,因为一个完整的系统不光只是把数据传来传去,还要进行若干处理等等,所以人为的控制是必要的.请有经验的指教. [/B][/QUOTE]

我的程序能到32kb/s，
应该还能再大，可是我的数据只有这么多了

昨天又实验了一下，最多可以达到350KB/S了，
瓶颈应该是在MCU上，我用89C52用PHILIPS的D12　USB－EPP演示板与演示程序测只有16KB/S左右，真的是慢！后来在24MHZ能有三十KB多了，就逐渐改FIRMWARE，后来用C达到的极限应该就是三百多了，因为在我的中断里什么都没做，只是读状态消除中断，然后也没再填数据，直接就用第一次的数据确认发送。看来要提高传送率只有换MCU或改回用汇编了。
大家有没什么好建议啊？还有问问除了W77E58，还有那些4个CLOCK或是6个COLCK的51MCU，这样在同样频率下又可以快2、3倍了。

[QUOTE]原本由 rayyang2000 发表
[B][QUOTE]原本由 sunkai 发表
[B]谢谢RY2000斑主指点.
你们不觉得我提的这个问题很重要?要做一个要求严格时序的大数据量的采集系统的传输接口,谁都不能躲过这个问题.
USB1.0的带宽是12Mb/s,CYPRESS的AN2131QC的BULK传输在理论上可以达到8Mb/s多的有效数据,我在这里看到有人说:每祯就只能传一个bulk包,最多就是64B,bulk传输太慢了云云.这样理解肯定是不对的,这不是问题,关键是,凡是做数据采集卡的同行们,你们是怎么考虑和解决我前面提出的那个问题的?理论上能做到,实际上并不一定,因为一个完整的系统不光只是把数据传来传去,还要进行若干处理等等,所以人为的控制是必要的.请有经验的指教. [/B][/QUOTE]
以前一直没有做大批量传输数据的实验，这两天做了一下，在我的系统中，现在能做到的速度是16kbyte/s。这个速度是指从firmware/hardware一直到windows app之间的传输。
是不是很慢啊？:) 当然我也想改进，但一个是苦于没有设备，还有就是现在没有时间了。 [/B][/QUOTE]

是的,16KB/S的确是慢,我现在做的一个东西到100K没问题,问题是数据到了主机不能立即画图(太费时了吧?),存盘先,然后复盘:).或者先抽样再画,现在还没有到那个时候,软件算法是个问题,:(.

[QUOTE]原本由 sunkai 发表
[B]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] [/B][/QUOTE]

兄弟们,谁行行好,请解答我的问题吧.如果真能到到17*64B/ms,就是>1000KB/s啊!,还有什么事不能干呢?总不能坐着等USB2.0到来吧.请懂得此道的大虾发个话吧,USB事务的安排怎么控制的?.

是否可以保证让host在一帧里面发若干个IN packet？

这个NAK是由USB规范规定的，USB1。0规定一般是是重新请求3次，如果全部不成功，就会停止，它不会一直请求。

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

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

[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下都是如此。

[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]

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

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

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

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

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

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