发现一个spcomm的问题，接收的时候会因为对方发送时间间隔过小而不同（10ms左右）--欢迎讨论

[s_delhpi]

实验环境，本机串口2，3短接，用于本机发送，本机接收。

发送数据程序自己编写，很简单，就是发送10个字符，如果手动发送没问题，

但是用程序以10ms一次连续发送，接收的地方会看到一大片一大片的接收到数据，而不是像循环那样一次一次发送的。

手动发送，接收响应时间短，收到的数据情况：01 02 03 04 05 06 07 08 09 0A

程序连续发送（10ms），响应时间长：，收到的数据情况：01 02 03 04 05 06 07 08 09 0A01 02 03 04 05 06 07 08 09 0A01 02 03 04 05 06 07 08 09 0A01 02 03 04 05 06 07 08 09 0A01 02 03 04 05 06 07 08 09 0A01 02 03 04 05 06 07 08 09 0A01 02 03 04 05 06 07 08 09 0A01 02 03 04 05 06 07 08 09 0A

根据观察数据是没有丢的，只是会一起接收到，不知道大家有没有碰到过

[tigerii]

正常现象

[s_delhpi]

自己测试了一下，

把这些属性设为Flase：
TxContinueOnXoff := False;
Outx_XonXoffFlow := False;
Inx_XonXoffFlow := False;

就好了，基本可以发送一次收到一次，请问这个有什么分别吗？

[jimmy_sun]

串口通讯时间和波特率密切相关，如间隔时间非常接近通讯所需时间甚至小于，通讯就可能出现问题

[ljq900]

spcomm说过来跟mscomm还是有差距
有可能是写线程只执行写而不做同步检查，这样每收到一个发送指令就执行把数据也搞乱了
不管跟波特率有没有关系
这应该说是一个缺陷

[Jethill]

这个原因也有可能是缓冲区的大小问题造成的，类似的问题见到过。

[numbbb]

SPCOMM会根据设置的Timeout缓冲数据，如果Timeout大于10ms（以楼主的例子），就会缓冲到很多帧，直到缓冲区满了才会触发接收消息，通常修改readTimeout会解决这个问题，楼主修改的那几个属性是用于流控的，通常应该是false

[shangchao]

没用过spcomm,用过ComPort,

[fox1999]

RS232/485/422 是流的通訊方式，不做邊界檢查的。(事實上也不可能像UDP 那樣做成包的方式，因為使用環境決定的。) RS232 是種很底層的通訊方式，不做邊界檢查，不保證數據正確，不保證數據次序正確。
所以的這些都要在用戶協議中來保證。常見的做法就是定義一個協議，我一般這樣定。

[Packet Head] 固定 1 Byte
[Packet Length] 1 Byte ，表整個 Packet 長度,最大 255 字節
[Data] n Bytes (0-251 Bytes)
[CRC16] 2 Byte 高位在前

[ly_liuyang]

这个根本不是问题啊,正常现象
还需要另外的处理队列来处理数据的~
你在接收事件中直接处理是不正确的

[s_delhpi]

我现在是在队列中处理数据，只要有接收到数据我就执行

new(p);
p^.gData:= Str; //str是接收到的数据，已经把16进制转成了字符串
gQueue.Push(p);

另外有一个线程专门检测gQueue，检测到有数据就POP，然后按之前定义的协议（包头、包尾、长度、CRC）来解析出完整的包。

现在解析包没有问题。但是程序时间一长就会有一个I/O 32错误，还有就是关闭程序的时候会有个异常出现，但是不是每次都有，我现在正为这个发愁，请指点一下

[s_delhpi]

偶尔会出现这个错误，请高手指点一下，

Exception EOSError in module Project1.exe at 0000FC96.
System Error. Code: 5.
拒绝访问.

[阿三]

关注，学习

[etmsg]

调整下spcom的接包时间，间隔就可以了

[knowledge_Is_Life]

有问题请先GOOGLE,BAIDU