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

smalloc

可不可以把8250发一个在这里.我找了很久没找到,,,

smalloc

回复 110# smalloc


    前面说的数据保存超时的可能性比较低.目前还没有在哪个文档里有描述
到是描述了overrun的意思. 在FIFO模式下, FIFO如果已经满.则新接受的数据会掩盖接收寄存器,而不会overwrite FIFO. [8.4 LINE STATUS REGISTER]
另中断识别码标志了几种类型的中断.ReceivedDataAvailable-接受数据可用 和 CharacterTimeout Indication-数据保存时间超时可用-因为没有到门限所以一直没发送中断 [TABLEIV Interrupt Control Functions]
这里可以尝试门限为1, 可能导致第2个中断发生没必要发生.
按以上 overrun的描述应该不存在overrun和 FIFO未满同时发生.除非是不同的实现.比如fifo满时overrun则清空fifo,不过特征是丢弃16个字节.或者其他原因
附加文档 PC16550D.pdf (345 KB, 下载次数: 2)

2010-11-25 21:04 上传

点击文件名下载附件

ljwilliam

回复 112# smalloc


    其实我也没有单独的8250的数据手册。我这里读到的是arm芯片整个的手册，上面关于串口的部分。
   
   This error condition occurs when there is a character waiting to be read, and the incoming shift register is attempting to move the contents of the next character into the Receiver Buffer (RBR). On UARTs with a FIFO, this also indicates that the FIFO is full as well.
     这个英文就是你的意思，overrun其实该是立马发生，只是它们覆盖的是shift register 而不是RBR。 并且有overrun意味着FIFO满。 这段英文来自wiki，应该说是可靠的。 所以我怀疑我读到的寄存器状态是不是有问题。因为无法在内核里面打印数据，所以，我采用的是在内核中写数据到文件，但是寄存器的值无法像char类型的一样直接写到文件中，我这里采用的是判断寄存器的某一位是不是符合我的条件，符合的话，就将一个我设定好的字符写到文件中。不知道有没有什么更好的方法来记录寄存器的数据。
  
  另外，我也觉得，假设我能改变这个中断的优先级，使得没有了串口的读取操作能速度能足够快，而使得overrun的状况，不可否认的是，这个状况的确是不稳定，因为中断的调用是不靠谱的，无法保证是否有别的更高的优先级的中断会打断串口的读取中断。（当然，这里我还没有找到相关硬中断的具体的改变优先级之类的东西，还在看，不确定我现在认为的就是好的）

  但是，同时，我也看到，软流控的话似乎是能根治的。但是我看到说，软流控的话他发送的XON/XOFF就是Ctrl-S和Crtl-Q，如果出现在了传输的字符中的话，可能会导致传输的中断，甚至永远不传输。这是问题一，英文的某上面说，Therefore, serial communication using software flow control is only acceptable when communication speeds are not to high, and the probability that buffer overruns or data damage occur are minimal.
  问题二，这个是我还不是很清楚软流控的情况下的一个。就是触发软流控，应该是有overrun情况的出现，然后接收端给发送端发送XON，那么发送停止。直到接收端发XOFF给发送端，再开始发送。那么这里的问题是，发送端是否会重新发送被overrun掉的数据，只是两个XON和XOFF似乎不能起到这样的效果，那么结果就是丢掉的数据少了，还是会发生。这个到底是怎么回事。还望指教。

smalloc

对于软流控是不是硬件发出来和处理的.我也很困惑.因为目前还没看到哪个UART讲这个
如果没有,我觉得只能在驱动里发.应该改成每发<16个字节就等待确认.这样才不会丢失.

EZWORD

对于软流控是不是硬件发出来和处理的.我也很困惑.因为目前还没看到哪个UART讲这个
如果没有,我觉得只能在驱 ...
smalloc 发表于 2010-11-26 17:05

    When software flow control operation is enabled, the UART compares incoming data with XOFF1/2
programmed characters (in certain cases XOFF1 and XOFF2 must be received sequentially). When the
correct XOFF characters are received, transmission is halted after completing transmission of the current
character.

ljwilliam

回复 114# smalloc


    的确，讲UART的都讲的比较简单，都说串口是最简单的驱动。。。
   这么改。。。驱动不就是加入了针对某个东西的部分了么，而且，我觉得最麻烦的就是这个等待确认，这有点网络传输的味道了。。。

ljwilliam

回复 115# EZWORD


    应该是主动发的。但是8250里面貌似没有这方面的机制阿，也没有看见硬件流控制的相关代码。 不知道这部分是怎么实现的。。。

EZWORD

硬件流控，需要硬件支持，根据引脚电平决定是否发送。软件流控内核代码中有。

1.         if (tty->receive_room < TTY_THRESHOLD_THROTTLE)
   
2.                 tty_throttle(tty);

复制代码

在n_tty.c文件中，有个函数叫做n_tty_receive_buf，这个函数调用了tty_throttle，接着调用uart_throttle，发送XOFF。以上为2.6.36内核中。

ljwilliam

回复 118# EZWORD


    兄台比我研究的细致多了，受教受教。这个串口的程序，整个走的路径其实我还不是非常的清晰，就大致有个印象，具体的还不是很清楚。
   原来是做在这一层的机制。我看了下，硬件和软件的流控制是做在了一起。也很简单，里面并没有实现我所说的重发的机制。所以我就不是很清楚，这个流控制的效果到底能怎么样？不知道兄台有没有进一步的东西可以分享。

EZWORD

简单的研究过一段时间，详细的内容还是直接看源码比较好。
内核中关于串口的驱动分层确实有些复杂。
我自己总结的层次关系如下：
1，struct uart_ops功能靠直接操作硬件层来实现；                  物理层（此处驱动硬件工作）
2，struct tty_operations的实现依赖于struct uart_ops；        串口核心层
3，struct tty_ldisc_ops的实现依赖于struct tty_operations        线程规程层
4，struct file_operations的实现依赖于struct tty_ldisc_ops        tty核心层？

当然实际可能比上面要复杂一些，也可能存在理解上的错误，自己去分析下吧。