我开始也是用iso,不久就发觉不能很好地控制它,数据时对时错,改成bulk,起码保证数据完全正确,这时出现丢点的现象,正如你说的,我采取了缓存的办法,就不会丢了,这是我上面建议里的第3.4点.
inbuf的大小是固定的64byte,可设置用pairing乒乓.inbuf是不能不断地写入,只有在!busy时才能写入,这是丢点的原因,所以要有个ram缓冲,用fifo是个不错的选择,这样只要成功控制fifo不会满就不会丢点了.iso inbuf是1024,本身就采取双buffer乒乓方式工作

我公司硬件人员对数据完全正确兴趣不大
只要稳定，您评估一下ISO可以长时间稳定运行吗？

说到这里,我不得不承认并非高手,只不过经历长了一点,失败的次数多一点,说道理论方面的东西还得要真正的高手襄助.从架构和协议来说无论哪种传输方式都应该保证可以长期稳定运行(显然是一句废话).

我在杭州出差,从南京来

这样的话
我们先明确：

固件的程序因其 短小，结构简单 一旦可以正常传输
就可以一往无前的工作下去

就可以断定问题出在host端
驱动我是用的开发板的
应该也没问题

应用上，
1、IOCTL_Ezusb_RESETPIPE
2、IOCTL_EZUSB_START_ISO_STREAM
3、象EzMr一样，建立一个线程，不断的IOCTL_EZUSB_READ_ISO_BUFFER

有漏洞吗？

设备是被动的,要主机每ms都去读一次,数据才能回来,你怎样让os保证每ms都能执行一次deviceioctrl?显然不可以,用死循环不可以,用线程做也不可以,我测试过,做不到这一点,进出一次不只1ms,接收的数据是断断续续的.

有两个例子,我最开始采用的和你现在的一样,后来改用IsoStream,结果都不理想.

分给完了，被系统骗了2分

关键是硬件方面坚持不用FIFO
而且我对数据正确性没有要求

我刚才又试了一下，10ms读一次，也不行
如果我在采集的时候同时启动一个大程序
采集停掉，最后的几秒出现好像很难读的样子！（和以前一样）

这就是我说的不能保证主机准时发in请求的原因,分时系统嘛,你要想定时收发,它可不这样想.

硬件不做好,一切白扯,采集系统不要数据正确,耍我还是蒙人? :)

比如USB网眼
您说他是什么传输？
我用一个工具软件看我的EC300使用的是ISO
他其中的一帧数据出错不影响我的整体监视
我的系统也是这样
我不在乎其中有一段数据丢失、损毁
关键是系统可以稳定的运行

哦,这样啊,非要用c++builder么?实在不行就先用vc做个dll,ezmr好用就搬过来,用c++builder调用如何