Serial port 串行驱动器hw fifo在460800波特率下超限

我使用的是基于2.6.32 OMAP的linux内核。我观察到，在高速数据速率下（串行端口设置为460800波特率），串行端口HW fifo溢出发生

串行端口配置为在rx和tx两个方向上每8字节生成一次中断（即当串行端口HW fifo为8字节时，生成一次从串行端口读取数据的完整串行中断）

我正在连续传输114字节的数据包（串行驱动程序不知道数据包模式，它以原始模式接收数据）。根据计算,

460800位/秒=>460800/10=46080字节/秒（其中1个停止位和1个开始位），因此在最坏情况下，我可以在1秒内传输46080/114=>404.21数据包，而不会出现任何问题

但是，我希望串行端口每秒至少处理1000个数据包，因为我已将串行驱动程序配置为每8个字节生成一次中断

我使用windows XP尝试了同样的方法，并且我能够每秒读取多达600个数据包

在上述情况下，您认为这在linux上可行吗？或者我错过了什么？让我知道你的意见

---

是否有人也可以发送一些需要在.config文件中配置的重要配置设置。我无法附加.config文件，否则，我可以共享它

串行端口可能发生两种溢出。第一个是您正在谈论的，驱动程序对中断的响应速度不够快，无法清空FIFO。它们通常大约有16字节深，因此获得fifo溢出需要中断处理程序在1/（46080/16）=347微秒内无响应。那真是一段非常非常长的时间。你必须有一个非常严重的错误的驱动程序，具有更高优先级的中断，才能使它跳闸

第二类是你没有考虑到的，并为逻辑解释提供更多的希望。驱动程序将字节从fifo复制到接收缓冲区。在用户模式程序调用read（）来读取它们之前，它们将一直坐在那里。如果不配置与设备的任何类型的握手，并且用户模式程序调用read（）的频率不够高，则会发生缓冲区溢出。它看起来就像一个fifo缓冲区溢出，字节就消失了。有一些状态位可以警告这些问题，但不检查它们是一种常见的疏忽。你也没提过要这么做

---

因此，从改进诊断开始，检查溢出状态位以了解发生了什么。然后，如果您发现它实际上是缓冲区溢出问题，请考虑启用握手。增加缓冲区大小是可能的，但如果这是消防软管问题，则不是解决方案。让用户模式程序更频繁地调用read（）是一个解决方案，但并不容易。只是降低波特率，是的，这总是有效的。

吹毛求疵：波特率和bps不一样。串行驱动程序以460800波特率获取数据，并将数据传递到用户空间。用户空间代码在处理后通过网络套接字/以太网将其发送到另一个应用程序。在数据传输过程中，只有3/4的中断发生。GP_定时器、EthTx和EthRx以及串行Rx。我观察到，在发送几百千字节后，串行驱动程序HW FIFO首先出现（串行驱动程序代码中的printk）。有一次，我发现我停止了通过套接字发送数据（减少了以太网中断的开销），但只是将其转储到一个文件中，这个设置工作起来没有任何问题。我将串行驱动程序HW fifo接收触发级别设置为8字节，这给了我大约56字节的时间来处理下一个中断。大约1.2毫秒（1秒内46080字节，填充56字节的时间=56/46080=>1.215毫秒）。我无法理解是以太网驱动程序问题还是其他问题？我如何取得进一步进展？可以肯定的是，串行驱动器HW FIFO溢出正在发生，因为系统中的中断被禁用超过1.2毫秒，或者其他中断占用的时间超过1.2毫秒。我认为根本没有考虑接收缓冲区溢出的可能性。不要只是注释掉socket send（）调用，用sleep（1000）替换它。并确认您仍然没有丢失任何数据。我敢打赌你会这么做。嗨，谢谢你的快速回复。我现在没有访问用户空间代码的权限，但一旦我有了访问权限，我将尝试插入sleep（1000）并验证我是否丢失了数据。如果我正确理解您的评论，根据您的说法，以太网中断频率和硬件FIFO溢出之间没有联系？如果是这种情况，在用户空间代码中（向网络应用程序发送数据或接收数据的网络应用程序本身）存在一些触发睡眠/或使系统在1毫秒以上不可抢占的实例。我如何调查这一点？如您所述，发送前引入1000us延迟时，会发生硬件FIFO溢出。因此，以太网中断导致这种情况的说法被排除在外。我还注意到，当硬件FIFO溢出发生时，ISR需要6000到8000微秒（这本身就是太长的时间）。我无法找到禁用发送套接字不会导致HW FIFO，但通过套接字发送信息会导致HW FIFO之间的关系。是什么导致串行驱动程序使用套接字花费如此长的时间？我知道ISR不能被抢先。它是否与系统负载或调度程序有关？评论