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.

[参考译文] TDA4VM:Fvid2时间戳

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1187898/tda4vm-fvid2-timestamp

器件型号:TDA4VM

         您好!

我们将 r5f GTC 时间注册为 Fvid2时间戳回调 、并以25fps 运行4个摄像头。  我们 在捕获目标的处理函数中的每个帧之间打印时间戳差。 当我们运行多凸轮演示时、时间戳差将保持40ms。 但是、当我们添加一些负载时、例如捕获对象(在 A72或 DSP 上、但在 MCU2_0上不是)的排队和排队之间的 memcpy、 时间戳差有时会变化、低至10-20ms 或高达60-70ms。  在这两种情况下、MCU2_0负载都不是高电平。

我知道、当 UDMA 过程完成时、会调用时间戳回调。 其他内核请求的 uDMA 任务是否有可能降低 MCU2_0上 CSIRX 中 UDMA 任务的性能? 或者、Fvid2的时间戳变化还有其他可能的原因吗?

谢谢

                                                                                                                                                                 李云豪

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

    您正使用哪个时间戳来找出差异? 是否使用 TIVX_reference_timestamp 引用属性来获取/查询时间戳?  

    因此、存储器复制或 DMA 复制不应影响 CSIRX 捕获时间戳、但让我们首先检查您用于获取时间戳的方法。

    此致、

    Brijesh

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

    感谢您的回复。

    是的,我们通过 vxQueryReference()和 TIVX_reference_timestamp 查询时间戳,在 A72上的 vxGraphParameterDequeDonRef()之后。

    此致、

                    李云豪

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

    我们在此登录:

    并获取日志、如下所示:

    通常、DIFF%40ms 应接近于0。 但有时它很小。 此时、所有4个图像均已进行了测试。

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

    您好!

    您使用的是哪个 SDK 版本? 您还在使用 SPL 引导流程吗?  

    通常 、在 PSDKRA 版本中、我们为 CSIRX 提供了最高优先级、因此 A72上的 memcpy 不应影响 CSIRX。 但是、让我们看看您是否正在使用 PSDKRA 版本、并且优先级设置正确。

     在运行用例时、您是否还可以打印捕获统计信息并共享数字? 在多凸轮示例中、您可以通过在控制台上按"p"来获取统计信息。 我想查看 CSIRX 是否报告了任何错误。  

    此致、

    Brijesh

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

    您好!

    我们在 以下位置获得了 SDK 版本:https://www.ti.com/tool/download/PROCESSOR-SDK-RTOS-J721E/07.03.00.07 
    我们将使用 SPL 引导流程。

    我们添加了捕获目标进程函数、如下所示

    正常帧间隔为40000us。 有时 A72应用程序会缓慢排出队、导致帧丢失。 因此 N*40000us 也是正常的。

    我们得到了类似的日志

    56600加上63400是120000,120000是40000*3,这意味着一个帧太快,下一个帧恢复到正确的阶段。

    同样,,9000加71100大约是80000,即40000*2。  

    在 Capture 状态日志中是否发现任何错误?

           

    此致、

    锂离子电池

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

    您好、Li、

    但是、你在 A72上运行的是什么呢? 您可以共享此代码吗? 您是在 A72上执行 memcpy 的去队列和 enqueue 操作、还是在 A72上运行单独的低优先级任务上运行 memcpy? 此外、您是连续还是仅执行一次 memcpy 操作?

    此致、

    Brijesh

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

    您好  Brijesh,

    我们在 A72 (QNX)上的去队列和排队之间执行帧 memcpy、每秒20帧。  memcpy 任务的优先级为10、在 A72上的应用中最高

    此致、

    锂离子电池

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

    您好、Li、

    但不建议在 A72上执行 debqueue 和 enqueue 操作之间的 memcpy。 因为在这种情况下、CSIRX 可能需要33ms 以上的时间、并且可能影响 CSIRX 的运行、因为 CSIRX 可能会耗尽缓冲区、并且会在这种情况下丢弃缓冲区。  

    如果删除此 memcpy、您是否会看到此问题? 或者、如果您可以执行更小的 memcpy、这一操作所花费的时间始终小于33ms、则 CSIRX 将正常运行。  

    此致、

    Brijesh

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

    建议客户不要在 tiovx 捕获链中使用 memcpy、也不要在每次迭代中使用 delta b/w dq 和 enq、而是在 DQ 之后的帧之间增量时间戳。   

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

    谢谢徐刘。