[参考译文] SK-AM64B：处理时间测量方法

您好、Yoshiki、

是的、您回答正确。 您是否已经对此进行过实验？

请允许我在某个时候对您的其他问题进行评论。

此致、

Vaibhav

您好、Vaibhav、

就是我所怀疑的。
谢谢你。
此致、
Yoshiki

您好！

Unknown 说：

Q4.如果是 Linux、可以使用 top 命令检查 CPU 占用情况。
 如果是 MCU+SDK、如何测量 CPU 占用情况？[/QUOT]

为了解决这个问题、我们最近创建了一个常见问题解答： https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1392509/faq-how-to-profile-cpu-usage-with-mcu-sdk

此致、

Vaibhav

您好、Vaibhav、

一如既往,谢谢你!!!! 我将查看它。

此致、
Yoshiki

您好！

问题2： 如何测量内核之间的时间差？
 T1 = RCV0-1 - SND0-0
 T2 = RCV0-0 - RCV0-1

Q3如果 ClockP_getTimeUsec()的返回值返回自 CPU 复位以来经过的时间

我已在内部讨论过这一点、逻辑可以如下所示。

因此、假设有两个内核使用了 Notify、以确保两个内核之间的操作同步。

对于此注释、您可以尝试执行以下操作：

核心1应用：

此处请注意时间戳 t1 =假设为1s

通知呼叫

此处请注意时间戳 t2 =假设为10s

酷睿2应用程序：

此处请注意时间戳 T3 =假设为4s

通知呼叫

因此所用的时间很简单、t2 - t3 = 10 - 4 = 6秒。

请告诉我这是否合理。

此致、

Vaibhav

尊敬的 Yoshiki：

该专家目前已离开办公室一周。 对该线程的响应将被延迟。

感谢您的耐心。

此致、

Tushar

Tushar、您好！

感谢您与我们联系。

此致、

Yoshiki

Unknown 说：

我已经绘制了 T2 - T3。 我的理解是否正确？

是的、理解正确。 您可以继续操作。 如果有任何其他疑问、请告诉我。

谢谢您、Kumar。

我使用了 IPC Notify evcho 应用来测量处理时间。
我认为 ClockP_getTimeUsec()返回的时间不正确。
我认为 A53内核检索到的时间和 R5F 内核检索到的时间不正确。

我想在此处公布处理时间。

此致、

Yoshiki

您好！

我认为 A53内核检索到的时间和 R5F 内核检索到的时间不正确。

我想在此处公布处理时间。

您可以在此处发布时间吗？

您是否看到不一致的值？

此致、

Vaibhav

您好 Kumar。
很抱歉我迟到了。

PROT 1017-1.

本图表假设 PON 时间是同时的。
我认为它们不是完全同步的。

1017-Q1。

 我能否确定消隐时间？
 消隐时间需要多长时间？

 a53=>R5F 通信间隔
  A53的通信间隔约为30us。
  R5F 的通信间隔也约为30us。

  我不确定 A53 => R5F 的通信间隔。 可能大约为15usec。

以下是详细说明。
我的 IPC Notify echo 项目有一个主要内核 A53。

表。 ClockP_getTimeUsec

PROT 1017-1."T2 - T3 = 10 - 4 = 6"
 使用此公式、值为114511 (usec)。
 a53=> 114511的 R5F 通信间隔(usec)不正确。

 a53=>R5F 通信间隔：
  echo3 (T3)=> echo2 (T2)   114511 (usec)

 a53=>A53通信间隔：。
  echO2 (T2)=> echo4 (T4)  29 (usec)
  29/2 = 14.5 (usec)      R5F>R5F 通信间隔 A53=

表。 ClockP_getTimeUsec"同步"
 R5F 的 syncall()的完成时间为129062 (usec)。
 A53的 syncall()完成时间为18816 (usec)。

 如果 syncall()同时完成 A53和 R5F、则 ClockP_getTimeUsec()返回的时间不正确。

1017-Q2。
 如果 ClockP_getTimeUsec()返回的时间正确、则 R53F 中的 Ippiria(451)应在 Notify_Sync 之前完成。
 a53=>R5F 通知延迟为4273us。
 表。 ClockP_getTimeUsec"SYNC => T1"

 R5F syncall ()=> A53 syncall ()=> A53 sendMsg ()=> R5F echo1
  A53中的第一个 IpcNotify_sendMsg ()"t0"在 syncall()之后立即执行。
   A53 IpcNotify_sendMsg()延迟、因为 syncall()晚于 R5F 完成。
   在 R5F 中、同步后、等待接收。
   接收延迟为4273us。

 可能第一个 R5F 应用程序是在 SBL 完成后启动的。
 然后、在大约4000usec 后、我相信 A53应用程序就已经推出了。
 这种猜想是正确的吗？

1017-Q3.
 应用程序的启动顺序是什么？
 OSPI 引导加载程序：          R5F 0-0 => R5F 0-1 => R5F 1-0 => R5F 1-1 => M4F 0-0 => A53 0-0 => A53 0-1？
 OSPI 多分区引导加载程序：R5F 0-0 => R5F 0-1 => R5F 1-0 => R5F 1-1 => M4F 0-0 => A53 0-0 => A53 0-1？

此致、
Yoshiki

您好、Yoshiki、

感谢您的耐心。

此主题已分配给正确的专家。

请期待在几个工作日内得到回复。

此致、

Vaibhav