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

smalloc

55楼提到
没有了直接cat而导致的数据大量无故丢失的情况。谢谢指点，看起来cat是有点自身上的缺陷，不适合这里的调试。

这种结论不对.cat本身就是read write实现.你程序里read 和cat read根本没区别

没有cat时的大量丢失,也就是说概率比cat时变小了.仍然丢失?

smalloc

回复 55# ljwilliam


   >>> 那么是不是中断的时间有问题?

检查一个串口驱动注册中断处理函数 有个选项SA_INTERRUPT位 决定 handler时是否开启中断
如果你板子上还有其他比较多的外设导致中断处理程序被打断或者不能及时处理 面临同样问题
最好将其他驱动注册为中断开启.而这个注册为中断关闭.这样就保证他的优先处理权

不过话说回来真是这原因导致.那么你就不能假设你的串口工作在一个可靠的链路上了

ljwilliam

回复 60# smalloc


    哦，原来门限是这个意思，受教受教。。。那么，应该是改成小的门限是该有改进的，如果没有什么效果，就是说问题不一顶是出在这里老？

  另外确切的讲，其实我原本的问题是GPS模块通过串口丢失数据：这个问题通过改变门限什么的，没有什么作用。。。。没解决，收到的GPS数据还是丢失。
  衍生出来的问题该是，我为了看数据是哪里丢失的，而在内核中加入了数据打印的语句，但是结果出现了更大的数据丢失：这个问题在我取消掉内核的printk，而改成将数据写到文件之后，就没有这个问题了。

smalloc

回复 63# ljwilliam


    门限的意义也只是我猜想.最好看资料.我只是认为门限为1时放着15个缓冲不使用很不合情理,不过也有种可能就是:如果到达门限则阻止发送端发数据---这个我真不知道到底怎么回事

smalloc

回复 63# ljwilliam


    如果容易比较,可以尝试只cat重定向到某个文件 和 cat到中断显示 2种情况丢失是否有区别
对于2你已经测试过.只用测试一.如果不方便就算了. 如果是有改善了 则足以证明中断响应或处理不及时是丢失的原因之一

ljwilliam

回复 64# smalloc


    门限是您说的那个意思。当FIFO的数据超过门限的的时候，就一直让中断的信号active，触发中断，直到CPU读取FIFO中的数据到低于门限为止。数据是会一直写到缓冲区的，当数据写满了FIFO，而还是有数据来到时，就会overrun。

smalloc

回复 63# ljwilliam


    假设printk导致中断响应不及时而发生数据丢失
那么你的串口数据接受就是不能同步到发送端, 通知它数据满了不要再发送
因为如果能通知,那么中断在延迟也不会丢数据

如果这样.这种串口恐怕不能工作在现在的linux下.而必须工作在实时系统下.

所以可能有另外一种情况.就是你的串口或许可以设置为上面说的"同步"的

ljwilliam

回复 62# smalloc


    SA_INTERRUPT 应该是没有设置。串口的中断设置的时候就问是否是共享设置，是共享么是SA_SHIRQ，不然就是0. 应该是没有。那么就是建议我使用这个SA_INTERRUPT 将这些中断设置为快速中断？

smalloc

回复 68# ljwilliam


    这个是小事 重点在67楼. 如果是不可靠传输 只能通过上层协议保证数据正确性了

ljwilliam

回复 65# smalloc


    cat重定向到某个文件 和 cat到终端显示 2种情况都丢失，没有区别