串口接收GPS模块发送的信息，接收上丢失数据

ljwilliam

回复 100# EZWORD


    但是软流控不就是发送多余的XON/XOFF来控制流速么。。。难道这段英文不是这个意思。。。。

ljwilliam

回复 97# smalloc


    之前有说尝试no-FIFO。结果是效果更差了。FIFO还是需要的。
   硬件流控看起来是不可能了，没有多余的管脚，串口只有RX和TX。
   这里我想问的是软件流控的话是不是只需要发送和接收端都支持这个软流控，然后双方都开起来就可以了？ 比如串口的那方只需要像设置成硬件流控那样，设置termios里面的cflag为相应开启就可以了，而不需要在上层或者内核驱动里面做改变。另外管脚的话只有RX和TX也是可以软流控的对吧，不需要别的管脚了？
   还有，我不是很明白 如果有流控而且不overrun数据总有出错 ，这句的数据出错是什么意思。
   暂时没法PK他，毕竟能不能流控，他上面还要看。

EZWORD

唉，为什么每次我的回复你都不仔细的看，明显100楼说的是硬件流控。
软件流控需要两方的支持，不需要硬件的支持。

smalloc

回复 102# ljwilliam


    我觉得如果真是流控问题.那么他的给的方案就是有问题的.你提出问题对他们是好事.毕竟他的东西是要卖的.
>>如果有流控而且不overrun数据总有出错 ，这句的数据出错是什么意思。
我是这样理解的:串口数据传输的有流控的情况下overrun的值应该总是0, 这个时候数据还总出错,意味着错误有:接受某字节时校验出错后被丢弃.或者接收数据不丢弃但是内容与发送字节不匹配.
-----为什么出现这样的情况呢?因为我看硬件连线上没有确认/重传信号线.而软件上也没有发送确认/重传的控制字-类似流控控制字那样.
那么只能彻底认为串行数据是不可靠数据. 所以做可靠传输必须保证硬件上有极其低的错误率. 因为你认为他传输必须完全正确. 假如有一天你收到一个错误字节还是当正确数据处理. 你的系统可能彻底出错重新启动.
对于NO FIFO方式如果有错误. 如果是中断下只取一字节. 可能原因:

1没有流控-注意这里说的所有流控都是说的自动流控,就是在必要的时候硬件能自己发送控制信息.
2有流控但是收到一个错误数据仍然被你读取了.--这个能从接受的状态字里面知道是否是一个校验错误的字节--这种情况很多,那么确实可证明硬件工作在一个很不可靠的状态.=按道理串口是有线而且这么短距离出错几率应该非常小的.
3有流控 但是硬件在接受一个错误字后直接丢弃.你读不到

2 3区别能在显示的数据中直接看出来.一个是字节长没变化.而字节内容错误 一个是少了若干字节.
没有流控的可能性大点 理由还是硬件出错几率应该很小的
无论软流控是自动还是非自动 都必须有双方直接.这个你最好直接找他们确认下

ljwilliam

回复 103# EZWORD


    我不是没看。。。只是我觉得那段英文给我的是那个意思。。。我现在比较混乱。。。

ljwilliam

回复 104# smalloc


    流控的事情，我们还在持续的跟进。
   最新的情况，发现去掉了很多加载的模块之后，overrun就没有出现了。。。这是说明中断被打断了嘛？

smalloc

回复 106# ljwilliam


    中断只能被中断打断.或者被关闭中断的操作延时-当然也包括一些关闭中断的hander.
这一切在没有流控的环境下都必要导致概率的overrun.
所以可以检查去掉的模块是否是带中断或关中断的代码
即使现在没有overrun了.你的程序也在理论上运行在一个不可靠的传输环境中.
另外即使加了流控使得overrun永远为0,那个时候你的数据的完整性仅仅依赖硬件-假设这个出错极低,数百W错一次....但无论如何还是有错,上层软件应该建立点容错机制.比如重启等.

另外存在一种可能: overrun也许在保存数据上有点时间限制.即使有流控比如定时到一定时间就丢弃数据.去接受新的数据.
在这种情况下,连有流控也是不能保证的.当然时间的延迟还是源于中断响应的影响

smalloc

回复 106# ljwilliam


    overrun不出现是不是就没有错误发生?

ljwilliam

回复 107# smalloc


    我也在想中断被打断的问题。 但是linux的中断是没有优先级别的吧？别的中断是在下半部才有可能抢先被处理的（不知道这里的理解对不对）。
   至于关中断，我不是很了解。
   的确，如你所说，即使加了流控，其实系统本身就不稳定，何况去掉的模块是必须使用的，也就是说除非找到这和被去掉的模块和串口驱动的冲突原因，否则即使加了流控也是出现类似overrun的丢失数据的问题。
   还有，就是8250的寄存器提示有overrun的时候，我也同时去查看了FIFO寄存的状态，发现FIFO未必是满的。假设我查看的结果的时候，这两个寄存器指示的状态没有被改变过的话，那么这个overrun的标识的出现就和FIFO本身没有太大的关系了。
   另外，我发现，这里FIFO一直处在一个超过门限（8字节）的状态，也经常会使得FIFO满（但是未必会导致overrun）。
   最后，没有了overrun之后，数据就没有了丢失。

smalloc

回复 109# ljwilliam


    在硬中断hander中读FIFO到内存的可能性比较大.
所以可以认为延时或打断只与硬中断hander有关.所以只考虑硬中断
在注册硬中断有个标志位可以标志这个hander执行时时候是开中断的.前面帖子里已经给出.
如果是开的则这个中断hander能被别的中断打断,前面已经提到提高UART优先处理的 办法:别的尽量允许打断.而UART不允许打断.

>>何况去掉的模块是必须使用的，也就是说除非找到这和被去掉的模块和串口驱动的冲突原因，否则即使加了流控也是出现类似overrun的丢失数据的问题。
1.我的意思是即使找到这个冲突原因也无法解决.所以这个不是最终办法.只能减小概率. 因为你linux不是实时系统,就无法保证uart中断及时运行.
2.加了流控是否会overrun,取决于:流控是否正常工作,以及上面帖子提到的,"可能存在的"数据保留超时.

>>就是8250的寄存器提示有overrun的时候，我也同时去查看了FIFO寄存的状态，发现FIFO未必是满的
上面提到的数据保留超时是一个"可能的"原因.即发送中断-FIFO满-等待读-超时丢弃所有的字节-重新接受数据.
如此一来overrun和FIFO半满同时发生了.

>>我发现，这里FIFO一直处在一个超过门限（8字节）的状态，也经常会使得FIFO满（但是未必会导致overrun）。
这个就应该是以前帖子里提到的.你8字节门限,中断中去读状态自然FIFO有大于8的可能. 满而不overrun很正常事情-在有流控的情况下