• 状态 Resolved
  • 已锁定 已锁定
  • 回复 12 回复
  • 订户 0 订户
  • 视图 387 视图
  • 用户 0 会员在此处
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] AM3352：UART 硬件流控制

admin
Guru**** 2905440 points
请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/649354/am3352-uart-hardware-flow-control

器件型号：AM3352

大家好、

我们在 RS232端口上使用环回连接器、Rx 连接到 TX 引脚、RTS 连接到 CTS 引脚。

而 Linux-serial-test @ github.com/.../linux-serial-test 用于测试流控制

命令为：

> linux-serial-test -p /dev/ttyS1 -s -e -c -r

-s、--stats 转储串行端口每5s 统计一次
-e、--dump-err 显示错误
-c、--rts-CTS 启用 RTS/CTS 流控制
-r、--no-Rx 不接收数据(可用于测试流控制)
驱动器缓冲器已满时
预期的结果是、如果流控工作、程序应该在发送4096字节后停止发送数据、这会导致串行驱动程序缓冲区大小为4096。
但测试结果是、程序在发送4096个字节后继续发送数据。
您是否知道如何验证 RTS/CTS？
谢谢！

BR、
丹尼

  • 0
    TI__Guru**** 2905440 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    这是什么电路板？ 什么是 Linux 版本？ 您是否尝试连接两个板？
  • 0
    TI__Guru**** 2905440 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    电路板是我们的产品板、 内核版本是 Linux 4.1.21、还没有尝试两个电路板。

    您使用什么工具来验证两个电路板之间的流量控制？

  • 0
    TI__Guru**** 2905440 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    尊敬的 Denny's：

    发送日期超过4096字节时、您的观测器数据是否丢失？

    BR
    Tsvetolin Shulev
  • 0
    TI__Guru**** 2905440 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    另一个问题：RTS/CTS 流控制引脚在 Linux 配置中是否正确复用了引脚？

    BR
    Tsvetolin Shulev
  • 0
    TI__Guru**** 2905440 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    这两个引脚在器件树中配置。  

    0x178 (PIN_INPUT_PULLUP | MUX_MODE0)/*(D18) uart1_CTSN.uart1_CTSN：RS232C_CTSN *
    0x17C (PIN_OUTPLUG_PULLUP | MUX_MODE0)/*(D17) uart1_rtsn.uart1_rtsn：RS232C_RTSN *

  • 0
    TI__Guru**** 2905440 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    是的、可能有一些数据丢失、这里是日志、您可以告诉 Rx 不等于 TX、即使我们在缓冲区中以字节为单位进行计数也是如此

    Linux 串行测试应用程序
    /dev/ttyS1：此会话的计数：Rx=61824、TX=65520、Rx err=0
    /dev/ttyS1：TIOCGICOUNT：RET=0、Rx=429552、TX=425984、FRAME = 0、溢出= 0、 奇偶校验= 0、brk = 0、buf_overrun = 0
    读取缓冲区中有0个字节
    写入缓冲区中有4080字节

  • 0
    TI__Guru**** 2905440 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    顺便说一下、为当前 UART 驱动程序启用 DMA。

  • 0
    TI__Guru**** 2905440 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    你好 ，Tsvetolin Shulev，

     

    您是否测试了硬件流控制？

    您是否看到了相同的问题？

     

    BR

    海丰

  • 0
    TI__Guru**** 2905440 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    Haifeng、

    是的、我们已经测试了硬件流控制。 我不确定您看到的是与硬件流控制相关的内容。 由于启用了 DMA、UART FIFO 将持续由 DMA 处理、因此可能永远不会满足4096 UART FIFO 限制。 UART 不知道应用程序是否正在读取数据。 这似乎与您看到的内容一致。

    您是否在 RTS/CTS 线路上放置了一个范围来查看它是否被置为有效/置为无效？ 如果是、则表示硬件流控制正在正确使用。

  • 0
    TI__Guru**** 2905440 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 RonB：

    实际上、4096是 TTY 级别限制、在内核 TTY 级别下、串行端口级别有另一个缓冲区、大约为124k 字节。

    以下是测试日志：

    root@localhost：~ serialtest -p /dev/ttyS1 -s -e -c -r
    Linux 串行测试应用程序
    /dev/ttyS1：此会话的计数：Rx=0、TX=69615、Rx ERR=0
    /dev/ttyS1：TIOCGICOUNT：RET=0、Rx=65424、TX=65520、FRAME = 0、溢出= 0、 奇偶校验= 0、brk = 0、buf_overrun = 0
    /dev/ttyS1：此会话的计数：RX=0、TX=139230、Rx ERR=0
    /dev/ttyS1：TIOCGICOUNT：RET=0、Rx=127232、TX=135135、FRAME = 0、溢出= 0、 奇偶校验= 0、brk = 0、buf_overrun = 7840
    /dev/ttyS1：此会话的计数：Rx=0、TX=208845、Rxer=0
    /dev/ttyS1：TIOCGICOUNT：RET=0、Rx=127232、TX=204750、FRAME = 0、溢出= 0、 奇偶校验= 0、brk = 0、buf_overrun = 77440
    /dev/ttyS1：此会话的计数：Rx=0、TX=278460、Rxer=0
    /dev/ttyS1：TIOCGICOUNT：RET=0、Rx=127232、TX=274365、帧= 0、溢出= 0、 奇偶校验= 0、brk = 0、buf_overrun = 147040
    /dev/ttyS1：此会话的计数：Rx=0、TX=348075、Rxer=0
    /dev/ttyS1：TIOCGICOUNT：RET=0、Rx=127232、TX=343980、FRAME = 0、溢出= 0、 奇偶校验= 0、brk = 0、buf_overrun = 216640
    /dev/ttyS1：此会话的计数：Rx=0、TX=413595、Rxer=0
    /dev/ttyS1：TIOCGICOUNT：RET=0、Rx=127232、TX=409500、帧=0、溢出= 0、 奇偶校验= 0、brk = 0、buf_overrun = 282160

    您可以看到 TX 数量继续增加、 这意味着 RX 数量 在127232停止、而 buf_overrun 继续增加。

    根据我的理解、如果流控制工作、缓冲区溢出永远不会发生、 当接收 缓冲区已满时、TX 应该停止。

    BR

    海丰

  • 0
    TI__Guru**** 2905440 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    Haifeng、

    感谢您继续测试并分享您的结果。 进一步了解该问题、我们已经确定了启用 DMA 时使用的路径、其中 UART 驱动程序无法正确处理来自 TTY 层的信息以启动硬件流控制。 此问题在我们最新的生产内核 v4.9上重现。 我们正在该版本 v4.9上解决此问题。 我将在该修复可用时提供该修复。 如果您选择继续使用 v4.1、则您有责任将修复内核的端口作为备份。

    请理解、现在很多人都在休假、我可能会在1月的某个时候提供此修复。

    此致、
    Ron
  • 0
    TI__Guru**** 2905440 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    Haifeng、

    我们在此处发布了主线 Linux 驱动程序的修复程序：

    www.spinics.net/.../msg633288.html

    您将需要将此更改向后移植到您正在使用的4.1版本、但它应允许您按照最初的请求将流控制与 DMA 配合使用。