• 状态 Resolved
  • 已锁定 已锁定
  • 回复 24 回复
  • 订户 0 订户
  • 视图 792 视图
  • 用户 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.

[参考译文] TM4C129ENCPDT：UART 是否中断清除 FIFO？

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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/667313/tm4c129encpdt-does-uart-break-clear-fifos

器件型号：TM4C129ENCPDT
Thread 中讨论的其他器件：EK-TM4C129EXL、 TM4C123

数据表对 UART 中的中断信令没有太多评价。

我们将使用 UDMA 和 UART 发送/接收64字节的块。  我们使用中断作为错误处理的一部分、以发出清除状态和重新启动通信的请求。 这可能发生在消息中间。

作为清理的一部分、我们首先阻止 DMA 在存储器和 UART FIFO 之间移动数据。 但是 FIFO 本身中已经存在的信息又会怎样呢？

当 UART 发送中断或接收到中断时、对 UART 的 FIFO 有何影响？

发送中断是否会清除 Tx FIFO？

接收中断是否会清除 Rx FIFO？

如果没有、清除 FIFO 的正确方法是什么？

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

    您好、12月12日下午、

    发送/接收中断不会导致 TX 或 RX FIFO 被清零。

    对于 TX FIFO、建议的清空发送 FIFO 的方法是将线控寄存器(UARTLCRH)的位4 (FEN)清零(来源：器件数据表的第1312页)。 这可以通过 UARTFIFODisable() API 来实现。

    对于 RX FIFO、刷新接收 FIFO 的方法是读取任何垃圾数据或复位外设实例(来源： https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/p/401599/1422732#1422732)

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

    [引用用户="Ralph Jacobi"]

    对于 TX FIFO、建议的清空发送 FIFO 的方法是将线控寄存器(UARTLCRH)的位4 (FEN)清零(来源：器件数据表的第1312页)。 这可以通过 UARTFIFODisable() API 来实现。

    [/报价]

    是否允许清除 Fen、然后立即设置 Fen？ 或者是否需要插入一些等待状态？ 目的是丢弃 Tx FIFO 的内容、但随后继续使用 FIFO。

  • 0
    TI__Guru**** 2337880 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    是否可以在不首先禁用 UART 的情况下通过清除 UARTCTL.UARTEN 来清除/置位 FEN？
  • 0
    TI__Guru**** 2337880 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    [报价用户="12ve12pm"]通过清除 UARTCTL.UARTEN，是否可以清除/置位 FEN？[/QUERT]

    我(通常)在这里"黑暗中"。   (具有此级别的以 MCU 为中心的详细信息)

    拉尔夫说： “UARTFFIFODisable()。”    您是否已(扩展)将其更改为"禁用 UART？"    是否有差异-和/或... 它是否可利用？

  • 0
    TI__Guru**** 2337880 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    我将在 EK-TM4C129EXL LaunchPad 上做一些实验以进行了解。
  • 0
    TI__Guru**** 2337880 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    顺便提一下、TM4C UART 是否有更详细的用户指南、与 TMS320的此 SPRU 类似？

    www.ti.com/.../spru997c.pdf
  • 0
    TI__Guru**** 2337880 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您将需要供应商代理、或更关注"一个和唯一一个 MCU 品牌"的供应商代理。
    在大多数情况下-更高级器件的主要特性会(不会)传播(向下)到更基本的器件...
  • 0
    TI__Guru**** 2337880 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、12月12日下午、

    [引用 user="12ve12pm]]是否允许清除 Fen、然后立即设置 Fen？ 或者是否需要插入一些等待状态？ 目的是丢弃 Tx FIFO 的内容、但随后继续使用 FIFO。[/quot]

    从我看到的内容来看、我认为这没有问题、尽管它似乎没有经过专门测试。 从数据表过程中、似乎需要一段时间才能再次使用 FIFO、但我看不到我们在任何地方测试了完成清空 FIFO 所需的任何种类的最短时间规格。 如果您能负担得起一些等待状态可能是一个好主意。

    [报价用户="12ve12pm"]通过清除 UARTCTL.UARTEN，是否可以清除/置位 FEN？[/QUERT]

    是的、这就是 TivaWare UARTFIFODisable 所做的。 数据表只是预先规定了在不禁用 UART 的情况下执行此操作、这意味着如果 TX 或 RX 过程正在进行、 但我想、在您的情况下、由于您是在休息后执行该操作、因此您不会发生这种情况、因此在不禁用整个 UART 外设的情况下清除该标志应该是安全的。

    [引用 user="12ve12pm"]意外地发现 TM4C UART 是否有更详细的用户指南、类似于 TMS320的 SPRU？

    遗憾的是、我们没有有关 UART 外设的此类文档。

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

    [引用用户="Ralph Jacobi"]

    从我看到的内容来看、我认为这没有问题、尽管它似乎没有经过专门测试。 从数据表过程中、似乎需要一段时间才能再次使用 FIFO、但我看不到我们在任何地方测试了完成清空 FIFO 所需的任何种类的最短时间规格。 如果您能负担得起一些等待状态可能是一个好主意。

    [/报价]

    感谢你的答复。

    我知道没有经过测试的最短时间规格、但对于我们可能讨论的时间刻度有什么提示吗？ 大约需要几个时钟周期？ 微秒？ 毫秒？ 还不止这些？ 大致的棒球场数字会非常有帮助。

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

    嗯、我不知道如何确定性地评估这样一个时序、但从1188页可以看出、重新编程控制寄存器所需的时间足够长、可以再次重新启用 UART。 我想不建议在 FIFO 刷新完成之前启用 UART。 因此、基于这一点、我要说我们处于时钟周期到微秒的范围内。 如果我可以进一步回退该想法和/或进一步缩小窗口、我将在 AM 中做更多的挖掘。
  • 0
    TI__Guru**** 2337880 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    [引用用户="Ralph Jacobi"]我将在 AM 中做更多的挖掘-看看我是否可以进一步支持该想法和/或将窗口缩小更多。

    也许这里值得纪念— —“再一次”——供应商的拉尔夫远远超过   了正常的 高级论坛服务！

    即使在这里已经有10年以上的时间-公司/我从未遇到 过"UART 外设"详细信息的"此级别"。   拉尔夫 、"没有闪烁！"    (很容易通过/退出、 "放弃"-尤其是随着请求的扩展...)

    如果"适应性管理努力"不能进一步扩大、 "拉尔夫的坚定努力和愿望"的结合必须得到赞扬、并且值得(非常)特别注意！

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

    [引用用户="Ralph Jacobi]12时12分、

    嗯、我不知道如何确定性地评估这样一个时序、但从1188页可以看出、重新编程控制寄存器所需的时间足够长、可以再次重新启用 UART。 我想不建议在 FIFO 刷新完成之前启用 UART。 因此、基于这一点、我要说我们处于时钟周期到微秒的范围内。 如果我可以进一步回退该想法和/或进一步缩小窗口、我将在 AM 中做更多的挖掘。

    [/报价]

    我假设您是指数据表--但我查阅了第1188页，它是 ADC 输入等效/电压基准页，与 UART 或时序特性无关。 我应该查看其他文档吗？

    至于时钟周期/微秒范围、这是令人鼓舞的消息。 非常感谢您的帮助。

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

    [引用 USER="CB1_MOBILE"]

    Ralph Jacobi
    我将在 AM 中进行更多挖掘-看看我是否可以进一步支持该想法和/或进一步缩小窗口。

    也许这里值得纪念— —“再一次”——供应商的拉尔夫远远超过   了正常的 高级论坛服务！

    [/报价]

    许多绿盒很快就会获得大奖。 :-)

    [引用 USER="CB1_MOBILE"]

    即使在这里已经有10年以上的时间-公司/我从未遇到 过"UART 外设"详细信息的"此级别"。

    [/报价]

    通常、我不会深入探讨这一级别的外设详细信息。 通信运行得非常好----只要通信的两侧都能通电，并且永远不会遇到错误。 但是、如您所知、我们必须稳健耐用、并且具有良好的恢复/清理/重新同步序列。 到目前为止，我尝试过的一切都不是很好，看起来兔子洞已经导致了一个迷宫般的曲折通道，充满了陷阱和死角。 UART、其 FIFO、DMA、数据表的详细信息、driverlib、我自己的代码以及其他任何"gotchas！" 我跑进去了、我的头开始爆炸。

    当遇到错误(以中断信号表示)时、我将尝试按以下行执行操作：

    取消正在进行的与有问题的 UART 相关的任何 DMA Tx/Rx 操作

    清理 UART 状态--包括：

    -在进行中的字符之后停止任何 Tx/Rx 活动

    －清除 FIFO

    －确定 UART、FIFO、DMA 及其它任何设备是否处于已知状态

    －通过重试最后一条消息重新启动通信

    -递增一些错误计数器

    [引用 USER="CB1_MOBILE"]

      拉尔夫 、"没有闪烁！"    (很容易通过/退出、 "放弃"-尤其是随着请求的扩展...)

    如果"适应性管理努力"不能进一步扩大、 "拉尔夫的坚定努力和愿望"的结合必须得到赞扬、并且值得(非常)特别注意！

    [/报价]

    我非常感谢 Ralph 的帮助。 也感谢您的认可。

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

    (我们公司的)使用"来自多个来源的 ARM MCU"可能会让您对(近)"死海"卷轴有更深入的了解？

    依靠"一个且只有一个"MCU 信息源(甚至一个与供应商的 Ralph 同样有动力且能够做到)可能不会暴露 "其他有价值的方法/解决方案"-由(高度)重叠领域中的人员进行改进！

    的确可能有(一些)差异-但我要指出，我们对 "许多相关来源"的搜索/阅读/审查提供或激发见解-可能无法从(任何)"一个和一个" 来源获得。

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

    我的器件出错、我可能收到了错误的数据表(我在一整天都显示了许多数据表)、并且忘记验证... 您的设备 DS 中的页面为1312。 抱歉！

    寻找更多的信息可能需要等到下午，但这是我今天的队列(CB1，我不确定我的努力是否值得称赞，我认为我可以找到更多的信息可能是愚蠢的：)。
  • 0
    TI__Guru**** 2337880 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    拉尔夫

    公司/我认为-结果并非"总是且仅限于"-(单独)值得信赖！    您的"反应深度"(已有)和"与他人协商"的意愿-表明了卓越的奉献精神和持续的努力。

    简直太棒了...

    在没有"亵渎"(再次)的情况下、我(轻轻)建议海报可以通过检查 "相关他人"的努力/方法来"获得见解"。   当然，有分歧--答案不大可能显示为"剪切/粘贴"--但发现这种 "技术和机制"在"多次"帮助了我们目前的公司。    (并为我的共同创立做出了贡献-将过去的技术公司公开-从而"方法证明！")

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

    [引用 USER="CB1_MOBILE"]

    (我们公司的)使用"来自多个来源的 ARM MCU"可能会让您对(近)"死海"卷轴有更深入的了解？

    依靠"一个且只有一个"MCU 信息源(甚至一个与供应商的 Ralph 同样有动力且能够做到)可能不会暴露 "其他有价值的方法/解决方案"-由(高度)重叠领域中的人员进行改进！

    的确可能有(一些)差异-但我要指出，我们对 "许多相关来源"的搜索/阅读/审查提供或激发见解-可能无法从(任何)"一个和一个" 来源获得。

    [/报价]

    这是一个有趣的建议。 实际上、TM4C (123和129)代表了我在 TI 和 ARM 方面的首次体验。 以前在非 ARM 芯片上与其他供应商有过经验。 现在已经有一年了，所以我已经克服了一些相当困难的障碍。 因此、我最近遇到的问题和我在这里提出的问题远小于 n00b、并且更加深入和详细。 当然、这些是最难回答的问题。

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

    我公司(经证实)的结果表明 、"这种扩大的搜索" 通常证明(超出)"有趣"。    虽然这种(相关供应商)方法并不(尤其是)直观、但充分利用许多人(而不是少数人)的头脑风暴能力确实对您有利。    很多人都"错过了"-这里-真遗憾！

    这里有一个"恐怖点"(可能)。    如果(假设)另一个 ARM MCU "更好地提供"、您会怎么做、甚至"您是否做出反应"、这正是您需要的？    那么呢？   (请原谅我)-这是否不意味着、"更彻底地回顾 MCU 功能"-尤其是那些"深入探索"的(您的 UART、此处)-应该在 更 早的时间内被"识别/搜索/探测"(以确保最佳选择)？

    在没有(适当的)解决方案(此处)的情况下、您仍然可以 从"更广泛的搜索"中收集想法、解决方法(甚至可能是"极好的解决方案")。    很明显-没有任何公司会"锁定"""伟大而明智的想法和/或实施！     您(可能)能够 将这种(或那些)方法"摔跤"到 您当前的 MCU 和系统中-这里。     (有一个希望...)

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

    [引用 USER="CB1_MOBILE"]

    我公司(经证实)的结果表明 、"这种扩大的搜索" 通常证明(超出)"有趣"。    虽然这种(相关供应商)方法并不(尤其是)直观、但充分利用许多人(而不是少数人)的头脑风暴能力确实对您有利。    很多人都"错过了"-这里-真遗憾！

    [/报价]

    我同意。 从各种可能的来源学习有很多需要说的。 从某些人那里、我们可以了解要做的事情。 从其他人那里、可以了解不该做什么！ 这同样有价值！


    [引用 USER="CB1_MOBILE"]


    这里有一个"恐怖点"(可能)。    如果(假设)另一个 ARM MCU "更好地提供"、您会怎么做、甚至"您是否做出反应"、这正是您需要的？    那么呢？   (请原谅我)-这是否不意味着、"更彻底地回顾 MCU 功能"-尤其是那些"深入探索"的(您的 UART、此处)-应该在 更 早的时间内被"识别/搜索/探测"(以确保最佳选择)？

    [/报价]

    是的、这里有"恐怖点"、但我有这样的看法：切换 MCU 是一项痛苦而昂贵的工作！ 即使我确实找到了另一个提供最完美 UART 的 MCU、或者找到最完美的"在此处插入您的愿望列表"、切换到该 MCU 也不可避免地需要回到方形一、再次攀登陡峭的学习曲线、 这意味着您将遇到难以解决的新问题。 人们很容易想到围栏的另一边的草地是绿色的，但我们现在来到这里的原因是，无论我们来自哪里，这种草地都是绿色的。

    我们在研究 MCU 和 MCU 供应商时深入探讨了许多不同的标准、技术标准和其他标准。 我们从比您可以摇棒的更多位置购买开发套件、我们安装了更多 IDE 和开发人员工具、比您想了解的要多、我们运行了测试、我们执行了各种操作。 我们有充分的理由选择 TM4C、我完全支持该决策。 不可能了解世界上每个 MCU 的每个细节、也不可能深入探究、只需选择 MCU 即可。 这是分析造成的瘫痪。 一天结束时，必须做应有的努力，然后必须作出决定，处理出现的任何问题。

    [引用 USER="CB1_MOBILE"]


    在没有(适当的)解决方案(此处)的情况下、您仍然可以 从"更广泛的搜索"中收集想法、解决方法(甚至可能是"极好的解决方案")。    很明显-没有任何公司会"锁定"""伟大而明智的想法和/或实施！     您(可能)能够 将这种(或那些)方法"摔跤"到 您当前的 MCU 和系统中-这里。     (有一个希望...)

    [/报价]

    非常有可能。

    我们正在进行一些实验... 我将再次发布我们的体验。

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

    您好、12月12日下午、

    虽然我无法找到任何进一步的时序信息、但我确实遇到了以下代码片段、我认为您可以利用这些代码片段： 

    //
//等待 UART FIFO 为空，然后等待移位器获取
//输出端口的字节。
//
while (！(HWREG (UART0_BASE + UART_O_FR)& UART_FR_TXFE))
{
}

    如果您还想确保 UART 处于已知状态、您可能还对以下内容的扩展感兴趣： 

    //
//等待 FIFO 为空且 UART 不忙。
//
while ((HWREG (ui32Base + UART_O_FR)&(UART_FR_TXFE | UART_FR_BUSY))！=
UART_FR_TXFE)
{
}

    希望这对您的努力有所帮助！

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

    感谢你的所有帮助。

    我将尝试这些位、并发布我们很快发现的内容。

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

    这看起来非常有用-我希望海报罗伯特在这里展示-和评论。
    希望这证明对"12平方"有利，但它本身却是有价值的。 Mercî μ A。
  • 0
    TI__Guru**** 2337880 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    我要对 Ralph 和 CB1深表感谢、感谢你们在我关于 UART 外设的非常详细的问题上提供的所有帮助。


    我将解释我们如何解决恢复/重新同步问题。


    背景：通信使用固定大小的消息协议。 DMA 在存储器缓冲区和 UART FIFO 之间移动接收和发送数据。 通信采用"乒乓"方式、其中一个器件是通信的"主器件"。 它发送查询、然后等待回复、然后发送下一个查询等 另一个器件反向工作。 它必须首先接收一条消息、然后发送回复、然后等待下一条消息等


    这种方法很好、但我们遇到的问题是、如果其中一个器件遇到一些错误、无论是 UART 接收错误、通信过程中的一个 MCU 复位还是其他中断或损坏通信的问题、 这导致两个器件之间的通信序列不同步、因此所有后续消息由于其标头、CRC 等位置不正确而变得不一致。


    我们的解决方法如下：


    加电时、我们正常初始化 UART 和 UDMA 通道、但我们不启用 UART、不启用其 FIFO、也不允许其访问器件引脚。 器件引脚处于 GPIO 模式、Tx 作为输出、Rx 作为输入、我们将 Tx 驱动为低电平。


    在软件的其余部分完成初始化并准备好开始通信后、我们会执行握手以确保通信的两侧都准备就绪并同步。


    当我们检测到中断或需要发送中断时、我们会将引脚置于 GPIO 模式。 进入该模式后、我们清理 UART 并执行握手、以使通信的两端恢复同步。


    握手非常简单：


    两侧都必须将其 Tx 引脚驱动为低电平、至少持续两个字符帧。


    2.当主器件检测到另一端已将其 Tx 引脚驱动为低电平时、它将其 Tx 引脚驱动为高电平并等待另一端也这样做。


    3.当另一侧检测到主器件一直将其 Tx 引脚驱动为高电平时、它也将其 Tx 引脚驱动为高电平。


    该序列向两侧发出信号、表示它们彼此同步。 两侧都已停止正在进行的 UDMA 传输、并"清理"了它们的 UART 以从之前删除任何已失效的数据。 现在、两侧都可以重新启用其 UART、并将引脚控制权交给 UART、然后从新的 slate 开始。


    理由：我们首先将 Tx 驱动为低电平。 当两个器件同时上电时、都处于 GPIO 模式。 但是、如果其中一个处于 UART 模式、另一个由于复位或检测到错误而进入 GPIO 模式、则将 Tx 驱动为低电平的步骤1用于两帧将在仍处于 UART 模式的器件上注册为中断、 从而使其切换到 GPIO 并运行握手序列。


    我们最后将 Tx 驱动为高电平、因为这是 UART Tx 线路在未进行传输时的"静止"状态。


    我们确保至少两个字符帧的读数分别保持低或高、以便我们不会错误地将从其他 MCU 传输的数据位识别为预期信号。


    必须遵守一些计时特点：


    当 Tx 驱动为低电平的完整字符时间超过一个时、该字符在接收 UART 上显示为中断。 UARTBreakCtl()附近的文档指出，为了正确传输中断，必须对至少两个完整的帧将其置为有效。


    2.当通过关闭 UARTCTL 位 UARTEN、RXE 和 TXE 来停止 UART 发送和接收时、数据表规定、如果 UART 在传输过程中被禁用、它会在停止前完成当前字符、因此必须允许一个字符帧的时间长度。 建议在禁用 FIFO 清空 Tx FIFO 之前等待当前字符的传输或接收完成、以避免出现未定义的结果。


    在本主题前面、我们讨论了完全清除 Tx 和 Rx FIFO 所需的时间。 Ralph 将时钟周期中的某个位置缩小为微秒范围。 与两个字符帧等效的时间长度应大于足够的长度。


    为了确保我们尊重这些时序特性、握手和 UDMA/UART 清理由生成周期性中断的计时器驱动。 加载值计算为两个字符的时间长度。 在此中断中、我们实现了一个状态机、该状态机继续执行握手序列、每两个字符帧的时间长度一步。 我们仅在需要执行该序列时激活计时器。 在正常运行期间、定时器未被使用并且不会触发中断。


    为了确保我们尊重上面的时序问题2、我们在第一步中停止 UDMA 传输并禁用 UART、然后在传输完任何字符后在下一步中禁用 FIFO。 在与另一台主机完全同步并准备开始/恢复使用 DMA 发送消息之前、我们不会重新启用 FIFO。


    我们遇到的一些意外、以及我们如何解决这些问题：


    在启动新的 UDMA 传输之前、我们的代码会检查通道是否处于 UDMA_MODE_STOP 中、以防止我们对正在进行的传输进行编号。 当我们取消正在进行的 DMA 传输时、该通道似乎仍然停留在 UDMA_MODE_BASIC 上、从而阻止未来的传输能够启动。 我们通过调用 uDMAChannelTransferSet()来解决此问题，其中使用了 UDMA_MODE_STOP 作为 UDMA 消除的一部分。 请注意、由于函数的断言检查、我们必须将缓冲区指针的有效值和传输大小传递给该函数。 因此、我们创建了一个虚拟缓冲区、并传递其指针和大小。 由于我们要停止 UDMA、因此虚拟缓冲器应该保持不变。


    TM4C129和 TM4C123的 UDMA 完成通知不同、我们的代码库目标都不同。 为了纠正这种情况、我们使用预处理器逻辑来选择在 TM4C129上运行时是否使用 UARTIntClear ()和 UART_INT_DMATX / UART_INT_DMARX；在 TM4C123上运行时、使用通道掩码调用 UDMAIntClear ()。


    使用 UARTDisable()禁用 UART 会导致延迟，因为 UARTDisable()会在 while ()循环中等待，直到发送所有 FIFO 内容。 当事情正常工作并且您不想在正常情况下截断正在进行的通信时、这一点很好。 但是、由于我们希望快速取消正在进行的通信并重新同步两台主机、因此我们不希望继续传输实际上已过时/不需要的数据。 因此我们直接关闭 UARTCTL 的 UARTEN、TXE 和 RXE 位来禁用 UART，而无需调用 UARTDisable()。 我们将需要的代码行从 UARTDisable()复制到了自己的代码中。 回想一下、我们在序列的稍后部分禁用 FIFO、以尊重前面提到的时序特性。


    在跳过所有这些触发后、我们的测试最终显示此过程正常、通信会停止、重新同步和有效启动。 每次需要重新同步时、我们都会递增计数器、我们将对其进行监控、以了解实际情况下发生的频率。


    再次感谢 Ralph 和 CB1。 我希望这一讨论将对某人有所帮助。
  • 0
    TI__Guru**** 2337880 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    哇-非常感谢您愿意提供如此详细的信息-并感谢多位(尤其是 Ralph)的努力！

    现在是0420 (CST)、今天是"学校日"。 (一切都好-工作日)

    我一定会给您最新的详细信息一个很好的阅读-我希望也能吸引朋友 Robert 阅读/评论/评论。

    我有破解的员工"阅读/审阅"多个(其他) ARM MCU (M4和 M7s (我最喜欢的)的 UART 部分-我们将看到我们是否可以破解"他们的方法"-以便为您提供"更进一步"的攻击方法。 (您的收发器中永远不会有太多的箭头！) 或其他东西...