引用:
--------------------------------------------------------------------------------
原本由 singwoo 发表

主要原因在于你的DEVICE上。是你的设备来不及处理主机的要求。

我的一个测试如下：
我的设备比较快，一个FRAME 中有94个bulk 包,数据量为6Kb/ms。
相当于6Mb/s。即便如此快，主机的发送请求与设备的响应(指带数据的响应，不是NAK)的比例是3：1(一个FRAME中)。可见主机的响应有多快！
--------------------------------------------------------------------------------
对不起，各位！以上的测试是有问题的。我的包分析器出了些问题，
当时我也没有仔细考虑。正确的测试如下：
一个FRAME 中有34个bulk in 请求包,NAK 为21个。其余13个为数据包。每个数据包PAYLOAD 大小64byte。数据量为13*64=832byte/ms。
相当于832KB/s。主机的发送请求与设备的响应(指带数据的响应，不是NAK)的比例是2.5：1(一个FRAME中)。所以一个FRAME中10个BULK
还是没有问题的。

再次抱歉，上次并非随意乱写的。

[QUOTE]原本由 singwoo 发表
[B]to sunkai:
   很佩服你对USB钻研的那么细。
“主机根本来不及来读取，导致设备的外存取器数据溢出（用示波器可以看到溢出信号）。
我估测了一下，这样可以达到500-600KB/s,但还是不够10个包/ms，何解？”
   我的愚见是：
BULK IN 事务的过程如下：
1。主机发送IN 令牌，EOP后，等待设备DATA包。
2。设备接到令牌后按令牌中的同步序列发送DATA，EOP。
3。主机收到DATA后，发送ACK。

同步序列由主机产生，设备必须按此同步序列来发送数据。
所以，不存在“主机根本来不及来读取”的问题。 问题在于
你的设备没有与主机同步。

 [/B][/QUOTE]

    谢谢singwoo 。
    我想说清楚点，请你继续指教。我的设备有个FIFO存储器，写存储器由A/D微转换器独立控制（假定为恒定的高速率），指示USB芯片读存储器的信号也是由转换器发出（A/D字节数到达64B时触发一次USB芯片外部中断，端点可写时firmware读入64B数据写入端点），IN令牌到达时，数据被发送。如果主机发送IN令牌的速率不够高（端点清空的速率不够高，可写的速率也随之降低），FIFO就因为读速率过低而满溢，变为不可写，A/D数据因此丢失。
    据此，我想首先要保证主机客户应用程序要维持一个速率比较高的读操作，我能做的是用一个线程专门读数据，每次的数据请求量接近传输极限，假设为15packets * 64B，我想象中的理想情况是这么多数据必须在1个frame中完成，绝对不能被分拆完成。因为我对底层协议一无所知，不敢断定每个frame的确能完成这么大的传输，同时我也不知道是否在客户驱动层（或更底层）也可以人为地控制传输速率。我的系统是按照这样的思路完成的，低速率没问题，高了就不行了，摸不准是设备硬件方面还是软件方面的原因，我甚至都怀疑有没有WINDOWS方面和主机硬件的原因了，请多多指教。

> wdm层启动了一个线程来查询获取数据
很不错的主意！我也想过这么做，但在wdm层获取的数据怎样传到应用层呢？普通的做法是把应用层的内存传到wdm层来获得数据，请指点。

[QUOTE]原本由 sunkai 发表
[B]> wdm层启动了一个线程来查询获取数据
很不错的主意！我也想过这么做，但在wdm层获取的数据怎样传到应用层呢？普通的做法是把应用层的内存传到wdm层来获得数据，请指点。 [/B][/QUOTE]
这个线程可以通知应用层来拿数据啊！

大佬，我对怎么写驱动几乎一窍不通，更别说怎么通知应用层了。先把这个很好的方案搁在一边吧，等我把手头的做完了有空了再慢慢地啃，如果斑竹有闲暇就搬点代码出来，多谢多谢。

这里我有一个问题，一帧在协议上不是说最多只能19个packet吗？你用的是不是USB2.0的协议？
能具体说一下吗？
我只做过一个USB设备，用的AVR8515，8M晶振
一帧只能传4个packet

to sunkai:
  谈不上指教，为了共同爱好而互相学习。
对于你的这个问题，我的看法如下：
  1。如果你的A/D的连续的平均数据传输量有1MB/S或1MB/S左右，那么你的这个系统就很难实现。因为BULK传输的最大传输量是1.216MB(每祯19个包),而且BULK传输的数率是无法保证的。所以，你不能期望每祯都传15个包。
 2。如果你的A/D的连续的平均数据传输量远小于1MB/S，但瞬时传输率远大于1MB/S的话。则可通过大的缓冲区来实现。其实，就是把A/D传输与USB传输分开来对待。就让A/D已恒定的高速率传进来，FIFO溢出时把数据写入缓冲区，而USB传输只对缓冲区进行操作。这样的话，只要A/D的平均传输量远小于1MB/S，USB传输就没有问题。就象一个8KHZ的麦克风照样可以在1KHZ的USB总线上传输一样。

再次说明，我对你的系统并不熟悉，以上不一定正确。

[QUOTE]原本由 singwoo 发表
[B]to sunkai:
  谈不上指教，为了共同爱好而互相学习。
对于你的这个问题，我的看法如下：
  1。如果你的A/D的连续的平均数据传输量有1MB/S或1MB/S左右，那么你的这个系统就很难实现。因为BULK传输的最大传输量是1.216MB(每祯19个包),而且BULK传输的数率是无法保证的。所以，你不能期望每祯都传15个包。
 2。如果你的A/D的连续的平均数据传输量远小于1MB/S，但瞬时传输率远大于1MB/S的话。则可通过大的缓冲区来实现。其实，就是把A/D传输与USB传输分开来对待。就让A/D已恒定的高速率传进来，FIFO溢出时把数据写入缓冲区，而USB传输只对缓冲区进行操作。这样的话，只要A/D的平均传输量远小于1MB/S，USB传输就没有问题。就象一个8KHZ的麦克风照样可以在1KHZ的USB总线上传输一样。

再次说明，我对你的系统并不熟悉，以上不一定正确。


 [/B][/QUOTE]

讲解的非常有用，多谢了。我的系统当然不需要那么高的传输速率，能达到500KB/s我就要烧高香了，受很多因素的限制目前只有可怜的100k。BULK传输的数率是无法保证的是个颇令人头痛的问题。

如果是用driverstudio开发包中的driverworks开发的驱动，可以用如下方式来设置最大传输包的长度，在OnStartDevice功能里添加代码，但要在ActiveConfigration之前，例如一个KUsbPipe变量m_bulkEp1Out，可以增加如下代码来实现，
   m_bulkEp1Out.SetMaximumTransferSize(64 * 1024);
尺寸可以自己指定。如果不设置的话系统默认的是4096B.
我试过1M的尺寸，没有问题，但不需要太大，达到一定的大小之后速度也不会提高上去，所以自己要权衡一下。

如果是用DDK开发的驱动，可以在USBD_CreateConfigurationRequestEx功能实现后来设置。

要求时间特性，干嘛用bulk传输啊，用等时传输方式才能保证时间上的特性