串口接收高速率数据问题
仪器发送的每帧的数据的频率是300hz，波特率38400，，每帧8字节，为什么我用vb写的程序刚开始接收还比较正常，但是过一段时间（3-5s），程序就死了，不知道是不是数据更新太快，显示不了还是数据量太大，是不是隔多少数据就该清空缓存区？那样的话不是把接收的数据也容易清除吗？ 你用串口调试器试一试，看看是不是有大量的数据涌上来？如果是CPU利用率100％，那么应该是数据过多导致
建议你读取的时候打开端口，读完了，就关闭端口。 试过了，确实是大量数据涌上来，有人说OnComm事件达不到300Hz的触发次数，那到底该如何处理这种情况呢？ OnComm不适合你这种情况，你最好还是使用轮询的方式。 程序失去响应，估计是因为来不及响应 oncomm事件。用定时器吧，比如每隔0.1秒收一次，收完再开定时器。 VB6处理TEXTBOX 添加文本用 "&"OR "+"的方式，文本长到一定程度后，会越来越慢，导致响应不过来！！！
处理办法
1。先接到字符串变量中，完全接完后，再传到TEXTBOX中去显示，就没问题了。
2.用同步字头的办法，接收端每接收一怔后，给个答复，以同步通知上位机。
3。另一办法是，发送时，发送端计算出当前已发送总长度，根据不同长度，让发送每怔，取不同的延时系数，以保证，接收端能处理响应得过来。 我刚做了个串口调试器，包含大文件或怔发送，TEXT文本可达几万行，几兆的，你看看参考下
http://download.csdn.net/detail/chzadm/3721564 串口那点数据量弄不死程序的。不过如果你的机器配置比较低，而且是比较频繁的传输数据，那么有可能出现这种程序假死的现象。因为如果是使用微软的串口控件，无论是VB还是VC，对CPU的使用率都是很高的，如果频繁传输数据，会导致CPU使用率过高，程序自然就假死了。如果是配置好点的机器，这种现象就少点，基本上能顶过来，配置差点就会顶不住。
解决这种因为硬件操作导致 CPU 使用率过高的问题方法有三种：
1、继续你的这种程序方式，换个配置更高、性能更好的机器跑，硬顶过这种资源不够的问题
2、不要用微软的控件，找个现成的多线程串口通讯接口直接使用
3、不要用微软的控件，直接用API自己写，包括通讯与多线程部分(可以自己很好的控制资源)
现成的接口我写过个，不过是给 VC 调用的静态库形式，你也可以转一下，把他用 VC 封装成
API 函数或 COM 组件或 ActiveX 控件来供 VB 调用。
这个静态库在我的资源里有，频繁通讯时，在配置比较低的 PC 上 CPU 占用率在 0%-2% 之间，
以现在大多数机器的的配置，几乎看不见它的 CPU 占用率，而且使用方便，效率也很高，测试过
一段时间，稳定性也不错。你可以下一个用用看的。
http://download.csdn.net/detail/SupermanKing/2690778 应该是数据处理,显示的太慢,造成接收缓冲区收到的数据远远大于处理掉的数据
提高数据处理能力吧.看看是什么地方慢的.vb处理不了1秒2400字节才是晕了.就算vb不能达到300Hz的oncomm处理能力,还有缓冲区.一次要是多处理几个帧,应该也能追回来吧 应该是处理、显示速度太慢。
8 比特 X 8 字节 X 300 = 19200
也就是说，你传输和处理的时间是一半一半。如果处理、显示时间超过了 1.5 毫秒，就会造成数据过载。
另外，人眼的反应速度也就是每秒 20 - 30 帧，不需要每次传输都更新显示。
你可以在 OnComm 事件中判断缓存的数据量，够几百字节再转接处理一次。
串口接收8个字节 得等一会 稍等
我基本同意该说法说法，接收的数据应做快速处理，如果使用字串连接，速度会越来越慢，建议使用引用中红色行尾提供的方法。
补充：VB , COM/DCOM/COM+
