本来对ＵＳＢ接口缓冲区的知识等于零，因为在前想图点省事曾请教关于串口编程的知识而不得（并无怨言，与芯片结构无直接关联的内容理当自己去学习），就不得不去广泛查找相关的知识，当然因此诱发了这个讨论就是意外的收获了。

　　这里要探讨的不是串口通讯，借用控件“MSComm”数据缓冲区读写（同时清空）的功能，自己编写的程序就可以源源不断地读取串口通讯后台存贮的数据，而不必随时照料芯片什么时间填充这些存贮空间。

　　具体地说就是同样在一个ＣＨ３４１芯片结构中，既然串口传输已经成功地啮合到操作系统控件的数据缓冲区中，用户只要在没有发生溢出之前及时取走现存的数据，就不会造成数据损失，那么并口照样也可以轻易地做到，所差不过是把ＡＰＩ结构中由应用软件直接调用读写的操作，改变为操作系统直接进行罢了。

　　例如我在那篇《[原创]巧用CH341评估板测试并口接收速率 》帖子中阐明的那样，实测选择了最大限度选择了4096字节的缓冲区，也只能做到每毫秒22到23组32字节（总数大约700左右）的接收速率。虽然对比芯片公开的数据还是明显不足，但至少是现实能够达到的标准；而因为实际运用中再大的缓冲区也难以满足需要，再次调用同样的ＡＰＩ指令就存在衔接的问题，甚至因为不能确定硬件实际传输效益，为避免帧间数据的损失不得不再降低标准保守使用。

　　这样的改变对芯片用户而言就有莫大的好处。后台操作的结果是芯片及配套的ＡＰＩ只要面对操作系统，或者简单地说就是最大限度地不断填充系统内存划拨出来的缓冲区，而用户则只要随时从缓冲区取走数据而不管你的填充速度。于是只要１Ｋ而不是现在上限的４Ｋ就足够无限量连续采集而不怕传输遗失了。

　　其实发表这个讨论的题目还真不是一时兴致所致，而是经历了许多艰辛劳动得出的一些数据总结出来的。年前曾借用CH341评估板的VB程序做了些修改，试图通过不断调用缩小到1帧可能容纳的最大限度再降低一格标准，来完成连续采集的需要，结果是取到2A0H（21组）就已经不能保证可靠性了， 继续减少不过提高那么一点半点也无完全的保证。所以，如果按上述的做法就可以在保证最大效益的基础上保证采集数据的完整性，当然外设的单片机程序也是必不可少的缓冲机制，就不在这个话题的讨论范围了。

　　正因为没有可靠的保证，才不得不选择速度要慢得多的串行传输，也因此感觉到那几条指令确实能够解决实际的问题。具体的说就是只有缓冲区里边有数据，无论多少都可以一次读出来同时空闲出原来的位置，只要取值的间隔远远小于填充的速度就可以，而无须关注这个差异是否过大。

　　换句话说，就是现在的做法是主动型，一次索取多少就是多少（而并非说明的那样“返回实际数量”），你没满足我将一直等待你的完成，“其余的事情什么也干不了”或者可以接受，但完成的时间恰好进入下一帧，就不是简单地浪费了已经占用的时间，而是在剩余的时间必须眼睁睁白白地等待！于是你就只好考虑牺牲那么一两组数据的时间来迁就，却总也难免意外的情况发生。相反，我这里要说的方式就是改主动为被动，人家有多少就拿多少，大不了多“跑”几次，偶尔“跑空”罢了，不在每次有多少收获，只要保证没有遗漏就好。

　　这个问题应该不局限于ＣＨ３４１，其他ＣＨ３７Ｘ系列也应该存在相同的因素……