000---公开Bug

FAE exar zc周翀:
那要看看是发还是收出来的问题

红枫:
你们从流量控制的角度看，没有遇到过这种问题吗？

FAE exar zc周翀:
有可能，如果你的数据量大，还没收完，还在发，就会丢包。要解决这个问题最好的办法就是加硬件流控

红枫:
我们硬件上有做，不知道软件上有没有打开

FAE exar zc周翀:
测试一下波形就知道了

红枫:
测试CTS, DTS/ 还是测试DTR DSR ?

FAE exar zc周翀:
一般是cts和rts

- Serial port test data丢失的问题 ,客户不认可
客户无法接受贵司评估的增加Delay命令（usleep）来解决的方案。因为控制Serial Port的program（app）不是客户的，而是下游的客户进行的。因为无法针对所有客户的program增加Delay方案实际上不可实施下去的。Serial Port作为POS的最基本的、很重要的Interface，POS的主要周边设备都会接到这个port上。因此Data丢失问题必须要解决。

目前需要有COM口 apk开发经验的工程师，对上述进行一个判定

锐宝PM洪丰 锐宝ARM软件经理周锐箭 
关于Serial data损失问题，COM5是正常，只是USB to Serial的才会有问题。
是不是要修改USB to Serial 驱动？

客户反馈一次传送很多data时候没问题，而是把很多data一条一条去传送的时候才会有data丢失问题。
（比如 1传送很多data .. 2传送很多data .. 3传送很多data.. 这种方式才会有问题）

所以客户意思不是apk的问题

收到。
1 COM5 是CPU的， 是一个简易信号。其他COM 是USB to Serial的， 是全信号。
COM5这个是新的反馈，我们要搭配APK , 反复再测一下 . 这个要做线。

2 客户意思不是apk的问题， 从软件角度看，
writer 1次，数据可以很多，没有问题，
但分成多次write，快速循环，就有数据丢失。
我们感觉这种方式需要做控制，做延迟sleep。

我们先确认一下1

电话聊一下吧，看看原因在哪？tx的处理流程是不需要加延时，如果按照你们的现象看，就是对方没处理完数据，让tx晚点发咯

当前总结一下：

APK 数据量比较大, (连续发送49行数据)
用PC的串口终端看到，数据少了

APK可以通过延时，或者取消 nonblock的方式，解决这个问题

但客户不认可，
客户需要从驱动角度解决。

使用exar 参考板，

1 同样存在问题，丢失数据。 和主板上是一样的情况
2 公版参考版的 RS232芯片 全部NG , 使用TTL测试的。

如果友商的方案没有问题，那是不是exar的驱动还是要完善，
比如解决或者实现 nonblock？

CH9104也不行，数据丢失比之前V1414更严重，
APK去掉NO_NONBLOCK就不丢失数据, 也能OK.
看起来两家都有一样的问题. 目前只只有CP2102是可以的.