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

[参考译文] RTOS/AM5728：RPMessage SWI 执行时间

admin
Guru**** 2558250 points
Other Parts Discussed in Thread: AM5728, SYSBIOS

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/604259/rtos-am5728-rpmessage-swi-execution-time

器件型号：AM5728
Thread 中讨论的其他器件： SYSBIOS

工具/软件：TI-RTOS

在定制板上运行 TI-RTOS 的 AM5728 DSP。  处理器速度为750 MHz。

PDK 1.0.5、IPC 3.44.0、XDC 3.2.1.22、BIOS 6.46.1.38

我一直在使用 Execution Graph 工具来研究我们项目的时间轴。  我们有一个硬实时要求、即每71微秒处理一次来自 FPGA 的采样数据中断。  我们使用通过 IPC 的 MessageQ 从 DSP 到 Linux ARM 主机进行通信。


系统运行正常、直到我们从 ARM 向 DSP 发送消息。  下面的图片显示了处理的时间线。  查看图片的左侧、Hwi.82633508 (顶部的蓝色条)是每71微秒一次的实时中断。  在 Hwi 之后、fpgaDataThread 必须运行到完成。  这通常需要7-8 uec 的时间来执行。  如您所见、fpgaDataThread 完成后、LogUtilThread 将运行、这是系统中优先级最低的线程。  这很好。

现在我们来看看 Hwi.82633508 (图片中间)的第二次执行、在 Hwi 之后、fpgaDataThread 开始运行、但随后它被 EventCombiner Hwi 中断、这必须是从主机到达的消息引起的中断。  X2-X1是 Hwi 时间或15微秒(对于 Hwi 来说、这似乎是一个巨大的时间)。  
Hwi 运行后、RPMessage_swiFxn Swi 运行。  由于所有 Swi 的优先级高于所有任务、RPMessage_swifxn Swi 运行至完成。 这需要 X4-X3 + X6-X5或52微秒。  考虑到消息长度为4个32位字并且 Swi 本身没有实际处理、看来52微秒只是为了接收一个短消息而锁定处理器的时间太长了。  如果你为 Hwi 增加时间、我们为71 uec 中的67 uec、仅用于接收网格。  
您还可以看到、在 RPMessage Swi 期间、我们会得到另一个 Hwi.82633508中断、因此我们基本上会错过实时数据中断、因为我们从未完成之前的处理。

希望我启用了一些不需要的日志记录或一些其他问题、或者我们可能需要放弃 MessageQ 以实现更精简的消息传递实现。

  • 0
    TI__Guru**** 2558250 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    RTOS 团队已收到通知。 他们将在这里作出回应。
  • 0
    TI__Guru**** 2558250 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    更新：我对我的项目和.cfg 文件进行了一些更改、并且能够将 Hwi 和 Swi 的执行时间减少一个位、这已经改善了一些情况、但未修复。 Hwi 时间从15 μ s 变为12 μ s、Swi 从52 μ s 变为41 μ s。

    我将 RTSC 构建配置文件从调试更改为发布。

    我向.cfg 文件中添加了以下行：

    BIOS.libType = BIOS.LibType_Custom；

    VAR 诊断= xdc.useModule("xdc.runtime.Diags");
    VAR 默认值= xdc.useModule('xdc.runtime.Defaults');
    Defaults.common$.diags_ASSERT = Diags.always_off；
    Defaults.common$.logger =空；

    我可能还可以设置一些其他功能来精简 HWI 和 SWI 处理过程？

    我对 IPC 用户指南中的2.3.9节"线程同步"感兴趣。 我可以将其从使用 SWI 更改为线程吗？ MessageQ 中的消息无需实时处理、因此使接口响应速度变慢可能是一件好事。

    此外、我们可以通过任何方法来减少 Hwi 的时间通常都是一件好事。 我的 HWI 只做很少的工作、通常会向任务发布信标。 HWI 调度员最好尽可能精简。 现在、HWI 大约为5-6 μ C。 这几乎占了我的时间表的10%、仅针对 HWI。 在发布信标时，我无法使用 HWI_plug ()方法来避免 HWI 调度程序。
  • 0
    TI__Guru**** 2558250 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    Chris、

    您似乎已阅读 wiki (processors.wiki.ti.com/.../Optimizing_IPC_Applications) 以更改 BIOS.libType、是否还尝试使用各种 BIOS.customCCOpts 选项(-o3应该是必须的)构建 SYS/BIOS 库(如 wiki 所述)？

    对于 HWI_plug ()，线程(e2e.ti.com/.../372449) 有一个示例 c 代码和.cfg 文件，可能会有所帮助。

    对于 MessageQ 线程模型(SWI 与线程)、让我在内部进行检查、然后返回给您。

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

    我没有看过 CCOpts、但我现在看了。 按照指示、我打印了现有选项、我得到了以下内容：

    定制 CCOpts =-mv6600 -abi=eabi -q -m10 -mo -PDR -pden -pdd=238 -pds=880 -pds1110 -program_level_compile -o3 -g -optimize_with debug

    由于-o3已经存在、与-mi10一样、我没有任何明显的尝试。 你可以推荐任何东西吗？

    至于 HWI_plug、我上周读取了该线程并尝试实现 HWI_plug。 由于 HWI 调用 SEM_post 来触发一个线程运行、它似乎不是一个可行的选项、并且它确实非常有效地使我的代码崩溃。 LOL 基于线程中的注释"请注意、如果您的 ISR 需要触发 SWI 或信标、那么最好不要坚持使用 HWI (根据文档、对于信标、您别无选择、只能这样做)。" 我放弃了这种做法。 似乎 HWI_plug 基本上会绕过 BIOS、如果你然后调用一个 BIOS 函数、即 SEM_POST、它会触发一个 BIOS 任务开关、那么你就可以在你的 ISR 和嘣内有效地运行 BIOS！

    我认为这里的真正解决方案是处理 MessageQ 与 SWI 的线程、因此我希望您能找到有关这方面的信息。

    谢谢、

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

    器件型号：AM5728

    工具/软件：TI-RTOS

    以下是此帖子的后续内容： https://e2e.ti.com/support/arm/sitara_arm/f/791/t/604259

    在 定制板上运行 TI-RTOS 的 AM5728 DSP。  处理器速度为750 MHz。

    PDK 1.0.5、IPC 3.44.0、XDC 3.2.1.22、BIOS 6.46.1.38

    我一直在使用 Execution Graph 工具来研究我们项目的时间轴。  我们对每 毫秒处理来自 FPGA 的14个采样数据中断有严格的实时要求。

    如下面的执行图所示、Hwi 执行时间大约为9 μ s。  对于每1ms 周期14个中断、这会增加高达126 μ s 或12.6%的处理器时间。  这是一段很长的时间、只需要放弃 Hwi 处理。  

    此 Hwi 是来自 PCIe 子系统的 MSI 中断的结果。  ISR 几乎如人们所希望的那样简单、清除 PCIe MSI 寄存器中的待处理位、并将邮箱消息发布到 fpgaDataThread、您可以在图片中看到、它在 Hwi 之后立即运行。  我注意到、我对 ISR 代码所做的任何更改都不会影响 Hwi 时间。  基于另一个线程、我使用语法将所有 Hwi 处理代码从 DDR3移动到 L2SRAM、

    Program.sectMap[".hwi:｛*。*(.text：* ti_SysBIOS*_Hwi_*)｝]]="L2SRAM"；

    这确实完成了代码到 L2SRAM 的移动、但我没有看到 Hwi 执行时间发生任何变化。  非常失望

    由于我要将消息发布到邮箱，所以使用 Hwi_plug ()实际上并不是一个选项。  所以、我正在寻找有关如何减少 Hwi 执行时间的建议。  在9微秒时似乎过大、但我不确定所有时间的确切位置。

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

    我在内部与团队讨论了您的应用时序要求。 我们似乎没有针对 RPMessage SWI 执行时间的快速解决方案。 您是否可以简化应用、以便我们能够在 AM572x GP EVM 上重现问题？

    >> HWI_Pplug 似乎基本上会绕过 BIOS、如果您然后调用 BIOS 函数、即 SEM_post、它会触发 BIOS 任务开关
    我认为这是有道理的、并且 Hwi_plug ()在这种情况下不适用。

    通常、代码执行速度似乎很慢。 只有 Hwi_ funciton 从 L2SRAM 运行吗？ 您是否还启用了 L2缓存？ 微调高速缓存配置可能会有所帮助。

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

    Garrett、

    我必须研究我们如何为您提供足够的代码、包括 ARM 和 DSP、以重现问题。  我有一个 DSP 测试构建、不确定我们是否可以构建 ARM 构建。  在任何情况下、我怀疑它必须直接发送给 TI、而不是作为此主题的附件。

    执行时间。  我们已经开始对这一点提出一般性的质疑。  我们需要对此进行更多探索。

    以下是我的映射文件中显示 L2SRAM 中的函数(包括 Hwi)的内容：

    .hwi   0  00805120  00001500   

             00805120  00000260  SYSBIOS.ae66：BIOS.obj (.text：ti_SysBIOS_family_c64p_Hwi_dispatchCore__I)

             00805380  00000010          ：BIOS.obj ($Tramp$S$$ti_SysBIOS_KNL_Swi_restoreHwi__E)

             00805390  00000010  ti.targets.rts6000.ae66：error.oe66 ($Tramp$S$XDC_Runtime_Error_raiseX__E)

             008053a0  00000220  SYSBIOS.ae66：BIOS.obj (.text：ti_SysBIOS_family_c64p_Hwi_reconfig___E)

             008055c0  00000010  ti.targets.rts6000.ae66：error.oe66 ($Tramp$S$XDC_Runtime_Error_check__E)

             008055d0  00000010               ：Core-mem.oe66 ($Tramp$S$XDC_runtime 核心环境对象_i)

             008055e0  00000200  SYSBIOS.ae66：c64p_Hwi_disp_always.obj (.text：_ti_SysBIOS_family_c64p_Hwi_d调度 Always)

             008057e0  00000140          ：BIOS.obj (.text：ti_sysbios_family_c64p_hwi_instance_init__E)

             00805920  00000010  ti.targets.rts6000.ae66：core-mem.oe66 ($Tramp$S$XDC_Runtime_Core_deleteObject__I)

             00805930  00000010  SYSBIOS.ae66：BIOS.obj ($Tramp$S$ti_SYSBIOS_KNL_Task_schedule_i)

             00805940  00000140          ：BIOS.obj (.text：ti_sysbios_family_c64p_Hwi_Module_startup__E)

             00805a80  00000100          ：BIOS.obj (.text：ti_sysbios_family_c64p_hwi_instance_finaling__E)

             00805b80  000000c0  VailLTEDsp1_pe66.oe66 (.text：ti_SysBIOS_family_c64p_Hwi_Object_create_S)

             00805c40  00000020  sysbios.ae66：BIOS.obj ($Tramp$S$ti_sysbios_family_C66_cache_wbInv___E)

             00805c60  000000c0  VailLTEDsp1_pe66.oe66 (.text：ti_SysBIOS_family_c64p_Hwi_create)

             00805d20  000000a0  sysbios.ae66：c64p_hwi_asm-obj (.text：_ti_sysbios_family_c64p_hwi_plug__E)

             00805dc0  00000020          ：BIOS.obj ($Tramp$S$$ti_SysBIOS_family_C66_Cache _ invL1pAll_E)

             00805de0  00000010  ti.targets.rts6000.ae66：Core-smm.oe66 ($Tramp$S$XDC_Runtime_Core_constructObject__I)

             00805df0  00000010               ：Core-params.oe66 ($Tramp$S$$XDC_runtime_Core_赋 值 Params__i)

             00805e00  000000a0  sysbios.ae66：bios.obj (.text：ti_sysbios_family_c64p_hwi_dispatchC__i)

             00805ea0  00000020  --hole --[填充= 0]

             00805ec0  000000a0          ：BIOS.obj (.text：ti_sysbios_family_c64p_Hwi_EventMap__E)

             00805f60  000000a0          ：BIOS.obj (.text：ti_sysbios_family_c64p_Hwi_getStackInfo__E)

             00806000  000000a0  VailLTEDsp1_pe66.oe66 (.text：ti_SysBIOS_hal_hwi_con构)

             008060a0  00000020  --hole --[填充= 0]

             008060c0  00000080  sysbios.ae66：BIOS.obj (.text：ti_sysbios_hal_hwi_checkStack)

             00806140  00000080          ：BIOS.obj (.text：ti_sysbios_hal_hwi_initStack)

             008061c0  00000060          ：c64p_hwi_asm_switch.obj (.text：_ti_sysbios_family_c64p_hwi_switchAndDispatch __i)

             00806220  00000060          ：c64p_Hwi_asm_switch.obj (.text：_ti_SysBIOS_family_xxx_Hwi_switchAndRunFunc)

             00806280  00000060  VailLTEDsp1_pe66.oe66 (.text：ti_SysBIOS_family_c64p_Hwi_Object__delete_S)

             008062e0  00000060  sysbios.ae66：BIOS.obj (.text：ti_sysbios_hal_hwi_instance_init__E)

             00806340  00000040          ：BIOS.obj (.text：ti_sysbios_family_c64p_hwi_disableInterrupt__E)

             00806380  00000040          ：BIOS.obj (.text：ti_sysbios_family_c64p_hwi_enableInterrupt__E)

             008063c0  00000040  VailLTEDsp1_pe66.oe66 (.text：ti_SysBIOS_hal_Hwi_HwiProxy_create)

             00806400  00000040  VailLTEDsp1_pe66.oe66 (.text：ti_SysBIOS_hal_Hwi_Object_析 构函数__S)

             00806440  00000020  VailLTEDsp1_pe66.oe66 (.text：ti_SysBIOS_family_c64p_Hwi_Module_startupDone__F)

             00806460  00000020  VailLTEDsp1_pe66.oe66 (.text：ti_SysBIOS_family_c64p_Hwi_Params__init__S)

             00806480  00000020  --hole --[填充= 0]

             008064a0  00000020  SYSBIOS.ae66：BIOS.obj (.text：ti_SysBIOS_family_c64p_Hwi_clearInterrupt__E)

             008064c0  00000020          ：BIOS.obj (.text：ti_sysbios_family_c64p_hwi_startup__E)

             008064e0  00000020          ：BIOS.obj (.text：ti_sysbios_family_c64p_hwi_switchFromBootStack__E)

             00806500  00000020          ：BIOS.obj (.text：ti_sysbios_family_c64p_hwi_un可 插拔中断__I)

             00806520  00000020  VailLTEDsp1_pe66.oe66 (.text：ti_SysBIOS_hal_Hwi_HwiProxy_Object_create_S)

             00806540  00000020  VailLTEDsp1_pe66.oe66 (.text：ti_SysBIOS_hal_Hwi_HwiProxy_delete)

             00806560  00000020  VailLTEDsp1_pe66.oe66 (.text：ti_SysBIOS_hal_Hwi_HwiProxy_disable_E)

             00806580  00000020  VailLTEDsp1_pe66.oe66 (.text：ti_SysBIOS_hal_Hwi_HwiProxy_restore__E)

             008065a0  00000020  SYSBIOS.ae66：BIOS.obj (.text：ti_SysBIOS_hal_hwi_instance_final__E)

             008065c0  00000020          ：BIOS.obj (.text：ti_sysbios_hal_hwi_Module_startup__E)

             008065e0  00000020  VailLTEDsp1_pe66.oe66 (.text：ti_SysBIOS_hal_Hwi_Params__init__S)

             00806600  00000020  VailLTEDsp1_pe66.oe66 (.text：ti_SysBIOS_hal_hwi_析 构)

    .noncached_Program_Data  

    *      0  00806620  00000140   

             00806620  000000c0  AM57xxPCIe.obj (.noncached_Program_Data)

             008066e0  00000010  ti.osal.ae66：hwip_tirtos.oe66 ($Tramp$S$Hwip_disable)

             008066f0  00000010  LogUtil.obj ($Tramp$S$$_ZN7LogUtil6logMsgEjPcz)

             00806700  00000010  ti.drv.PCIe.ae66：pcie.oe66 ($Tramp$S$PCIe_getPendingFuncInts)

             00806710  00000010            ：PCIe.oe66 ($Tramp$S$PCIe_clrPendingFuncInts)

             00806720  00000010  AM57xxPCIe.obj ($Tramp$S$_ZN10AM57xxPCIe8pcieReadEj)

             00806730  00000010  AM57xxPCIe.obj ($Tramp$S$_ZN10AM57xxPCIe9pcieWriteEjj)

             00806740  00000010  SystemEventManager.obj ($Tramp$S$$_ZN18SystemEventManager6handleE15SystemInterrupt)

             00806750  00000010  --hole --[填充= 000000000000]

    我相信我已启用 L2缓存。  我具有以下平台定义、并且未禁用任何高速缓存存储器区域。

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

    在 RPMessage_swiFxn()执行时间的原始帖子上进行跟进。  我们将一个 EVM 版本的 ARM 和 DSP 代码整合在一起、以使 TI 能够查看我们看到的时序。  以下是 HWI 和 SWI 通过 MessageQ 从 ARM 接收消息到 DSP 的执行时间捕获。  虽然这比我们的定制板上的速度更快、但看起来仍然很慢。  对于 SWI、24 us 似乎是一个非常小(4个32位字)消息的永恒。  在 TskrTskMsgQRx 中运行的代码是从消息队列复制负载并将其转发到消息处理器中的代码、这种情况的发生速度比 HWI 和 SWI 快得多。  当我们有71微秒的处理时间时、让 SWI 阻止24微秒的所有其他任务是一个大问题。  

    如果我们可以向您发送最好的 ARM 和 DSP 代码/图像离线。  有些人可能会直接向我发送电子邮件、告诉我最好的方向。

    谢谢、 Chris

  • 0
    TI__Guru**** 2558250 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    Chris、您可以通过电子邮件或通过与您合作的 TI 代表将您的 EVM 版本代码发送给我。 －Garrett
  • 0
    TI__Guru**** 2558250 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    是的、我可以这么做。 可能在下周。 我们将提供 ARM 应用和 DSP 代码。 您应该能够再现我的最后一张图片。

    在另一天的会议上，有人建议，也许 TI 可以向提供的 MessageQ 示例代码 ex02_MessageQ 中添加仪表，并查看 RPMessage_swifxn()的时序是什么？
  • 0
    TI__Guru**** 2558250 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    在进一步讨论了发送 EVM 代码的问题后、我们希望尽可能避免这种情况。 此线程包含两个问题：1) HWI 为什么需要这么长的时间；2) RPMessage SWI 为什么需要这么长的时间。

    1) 1) HWI 需要大约9 μ s 的执行时间。 这将增加多达12%的时间线。 TI 对 HWI 的执行时间是多少？

    2) 2)我现在已在 EVM 和定制硬件上运行了测试代码、并且 RPMessage_swifxn 在这两个硬件上执行24 us。 TI 能否运行 TI 提供的示例代码 ex02_MessageQ 并将其检测为查看 RPMessage_swiFxn。 我要求 TI 这样做、因为我们的代码不会以任何方式损坏测试。 如果 TI 看到类似的 SWI 时间并确定这是"正常"的、那么我想知道是否有方法可以将 SWI 更改为线程化函数、以便它可以以较低的优先级运行、而不会阻碍我们的任务。 如果不是、我恐怕我们必须完全放弃这种方法、转而采用更高效的方法、我想是定制的方法。
  • 0
    TI__Guru**** 2558250 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    Chris、

    只需查看稍微晚一点的 IPC 维护版本3.44.01的 ex02_MessageQ 执行图即可。 RPMessage_swiFxn (X3-X4 = 29us)结果接近于您观察到的结果。 Hwi 事件组合器需要大约11us (X2-X1)、如下所示。 在 IPC 框架中将 SWI 更改为线程函数可能并不重要、您可能需要自定义"IPC"解决方案。


    此致、Garrett

  • 0
    TI__Guru**** 2558250 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    感谢 Garrett 的测试、但这对我们来说是最坏的情况。 我们确实实现了通过 HPI 接口在 C6482上使用的共享存储器通信。 似乎我们将重做它、以代替 MessageQ。 一个问题、或者我是否应该说第一个问题、ARM 和 DSP 之间中断的简单基本方法是什么、让对方知道共享存储器中已放置一条消息？ 我找到了 AM5728的邮箱功能。 这是最简单的方法吗？
  • 0
    TI__Guru**** 2558250 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    Chris、

    是的、当消息被放置在共享存储器中时、邮箱是通知 AM57x 内核(ARM 或 DSP)的最简单方法。 实际上、这也是 RPMsg 中消息传递机制的一部分。 wiki (processors.wiki.ti.com/.../PRU-ICSS_Remoteproc_and_RPMsg )介绍了 ARM 和 PRU、但 ARM 和 DSP 的设计概念类似。

    rpmsg mailbox Linux 驱动程序位于： 。 我们简要讨论了线程 e2e.ti.com/.../1855549中邮箱(NotifySetup)的 DSP IRQ 交叉开关设置

    此致、Garrett

  • 0
    TI__Guru**** 2558250 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    感谢 Garrett、这应该会有所帮助。 我还一直在以 IPC_*\packages/ti\sdo\ipc\family\vayu\InterruptDsp.c 中的代码为例。 不确定我是否可以自己调用这些函数。