[参考译文] PROCESSOR-SDK-AM64X：了解等时 PROFINET API (4.0.3) IRT -时序、引脚

您好 Dominik

在下面提供您的疑问的答案

• 这两个信号似乎是从 PN_API_IOD_activateIsoGpioObj ()触发的信号？
• 它们是 TI 和的脉冲？！

是的、调用这些 API 以初始化 TI 的 GPIO 事件和信号。

Unknown 说：

是否有任何 PIN/可能没有延迟地获得 IRT 中断/ISR？

您能否通过 IRT 中断澄清一下、您是指 CPM/PPM 帧的中断？ CPM/PPM 存在一个 ISR、分别为"pN_cpmIsrHandler"和"pN_ppmIsrHandler"。 您可以参阅 PROFINET FWHAL 上的该 API 文档以了解更多详细信息。  

https://software-dl.ti.com/processor-industrial-sw/esd/ind_comms_sdk/am243x/09_02_00_15/docs/api_guide_am243x/group__INDUSTRIAL__COMMS__PROFINET__DEVICE__FWHAL__MODULE.html

• 不应该在 TI 调用 PN_APP_IOD_cbDataWrite ()
• 和 PN_APP_IOD_cbDataRead ()被调用到

我将了解一下这个延迟及其与 TI 和 TO 事件的相关性。 很快将提供有关此方面的更新。

Unknown 说：

]您是否有任何有关 Profinet IRT 器件以及如何使用 TI 的完整协议栈集成到应用中的指南/文档？

您可以 使用以下链接参阅演示应用上的文档。 如果您需要有关任何主题的任何具体详细信息、请告知我们。
https://software-dl.ti.com/processor-industrial-sw/esd/ind_comms_sdk/am243x/09_02_00_15/docs/am243x/profinet_device/index.html

此致、
Laxman

您好：

Unknown 说：

我将看看这个延迟以及它与 TI 和事件的相关性。 将很快提供有关此问题的更新。

根据 TI 和至、回调以及与数据回调的相关性、是否有关于此主题的新闻？

Unknown 说：

您能否通过 IRT 中断阐明您是指 CPM/PPM 帧的中断？

当然、对于 IRT 中断、我是指 T_DC 处的中断/信号。 因此、据我了解 PROFINET IRT、需要在黄色时间触发器件中的测量(见下文)。 然后、在 TI 的时候、测量值需要准备好发送到 PLC

作为一种变通方法、我尝试使用：

但是、GPIO 只会每第二个周期触发一次(我不知道为什么？)：

Unknown 说：

CPM/PPM 存在一个 ISR、分别为"pN_cpmIsrHandler"和"pN_ppmIsrHandler"。 您可以参阅 PROFINET FWHAL 上的该 API 文档以了解更多详细信息。  

https://software-dl.ti.com/processor-industrial-sw/esd/ind_comms_sdk/am243x/09_02_00_15/docs/api_guide_am243x/group__INDUSTRIAL__COMMS__PROFINET__DEVICE__FWHAL__MODULE.html

[/报价]

我还查看了建议的 CPM 和 PPM 函数、我注册了回调。 然而,他们从来没有被调用,所以我猜这不是我正在寻找的。

还出现了一个新主题：由于我可能会耗尽最终器件上的引脚、因此我尝试通过 ISR API 接口调用 TI 和。 在 isrTo ()和 isrTi ()中,我切换了 PIN 以查看它们被调用的时间。 然而、两者似乎在几乎同时被调用、而不是在 TI 和 TO 进行配置时被调用。  

  PN_API_IOD_activateIsoIsrObj (pnHandle、isrTo、To、 &pnIsomHandlTo)；

  PN_API_IOD_activateIsoIsrObj (pnHandle、isrTi、tcyc - ti、&pnIsomHandlTi)；

如果您需要更多信息、敬请告知。

提前感谢您的支持！

此致

Dominik Fischer

尊敬的 Dominik：

抱歉、由于出现意外问题、支持此查询将延迟。 我们将在详细审查问题后尽快作出答复。

此致、

Laxman

您好！

这是一段时间以来的最后答复...

您是否有任何提示/答案如何在应用程序中正确处理 IRT、特别是对所提问题的回答？

尊敬的 Dominik：

对延迟深表歉意、我们  现在将通过执行类似的实验来了解时序问题、从而开始研究这个问题。  我们将很快提供最新状态。

此致、
Laxman

谢谢！ 这将是伟大的,然后我们可以继续在应用中实施

尊敬的 Dominik：

我们之前运行了一些测试、还发现 ISOM 的 ISR 事件没有以正确的间隔调用。 我将详细调试此问题、并在确定根本原因后提供更新。

此致、
Laxman

您好、

我们仍在等待有关此问题的更新。 您能否提供任何信息？

此致、

Dominik

尊敬的 Dominik：

我们已经解决了与 ISOM ISR 相关的问题、并发现了一个错误 、因此无论是否触发了 TI/TO 事件、都会调用 TI 和中断的错误。 我们目前正在实施修复、 不久将使用我们的设置对此进行测试。 会让您随时更新测试结果。

感谢您的耐心。

此致、

Laxman

尊敬的 Dominik：

我们已经审查了 TI 和 TO 事件的 ISOM 中断机制的实现。 当前 实现涉及通过通用中断 事件处理 TI 和中断、并 根据中断的时序区分需要调用的回调。 但是、这种方法 不会导致与提供的时序值进行确定性通信。  
因此、我们计划 通过 对 TI 和 TO 具有单独的中断事件来采用不同的方法。 这将确保中断的时序精确。 我们目前正在实施这一计划、并计划在下周结束之前完成这一计划。

感谢您的耐心。

此致、
Laxman

您好、Laxman：

也许您能给我提供反馈。 当此修复程序可用时、是否有任何具体计划？ 我们需要规划产品版本、并以某种方式依赖于 PROFINET 协议栈的这个修复。

此致、

Dominik

尊敬的 Dominik：

我们能够针对 TI 和事件隔离中断、还能够检测每个周期调用的中断。 但是、目前我们在触发中断时会观察到一些启动延迟。 我们将运行一些测试来 检查根本原因、并很快提供包含结果的更新。 敬请期待下周开始回复。

此致、

Laxman