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.
工具/软件:TI-RTOS
我测量的是 GPIO 引脚上信号变为高电平与 GPIO 回调函数发生之间的延迟。 根据我看到的时序、DSP 时钟速度为700MHz 时、延迟似乎几乎为8us。 这高于我的预期。 借助 HWI 的66x TI-RTOS 基准测试、中断延迟以及 HWI 调度程序序言可评估约0.5us 的延迟。 我希望 GPIO 回调也能实现类似的效果。 我对此是否不正确? GPIO 回调是否存在类似的基准?
我的 TI-RTOS 安装中包含了计时基准测试。 我的 PC 上的本地路径是 C:/ti/am57x_packages/bios_6_46_01_38/packages/ti/sysbios/benchmarks/doc-files/TI_C66_ti_platforms_evm6670_time.html
以周期为单位提供了各种函数的基准。 我假设回调函数的工作方式是创建一个链接到 GPIO 引脚的 HWI、因此我可以通过添加基准测试表中列出的"中断延迟"和"HWI 调度程序 prologue"值并将其乘以处理器时钟周期来确定预期延迟 (1/700MHz)。 我已经从我的机器中附加了特定文件。
e2e.ti.com/.../TI_5F00_C66_5F00_ti_5F00_platforms_5F00_evm6670_5F00_time.html
感谢您的回答。 通过实施另一个问题、我的同事可能发现了导致我发现问题的原因。 他对这一问题的评论如下:
"我们目前正在将 SYS/BIOS 库 app_pe66.oe66的.far 部分分配 给 .externalData。 此段的大小为0x10900字节、不适合内部存储器。 am571x.firmware.map 文件显示此部分包含四个符号:
8000000 ti_SYSBIOS_backs_HeapMem_Instance_State_0_Buf_A 80010000 XDC_Runtime_LoggerBuf_Instance_0_entryArr_A 80010080 XDC_Runtime_SysMIN_Module_State_0_outbuf__A 80010100 ti_800BIOS_000_Instance_000_000_000_000_000_0001_STACT_SYSMIT_000_STACT_STACT_STACK_0_000_000_000_000_000_000_
在这些符号中、最后一个符号(ti_sysbios_KNL_Task_Instance_State_0_stack___A、大小为0x800)可以与其他符号分开分配、因为它有自己的名为 .far:taskStackSection 的子段。 我发现将 app_pe66.oe66 (.far)移动 到 .internalData 会显著降低最大 HWI 处理延迟和抖动。 在移动或不移动子段 .far:taskStackSection 的情况下会发生这种情况。 在此变化之后、我观察到的最大 HWI 处理延迟约为2.3微秒。 要移动此部分、我必须在 本地 SYS/BIOS app.cfg 中将 BIOS.heapSize 从0x10000减少到0x8000。 我不知道这需要多大。
鉴于这些发现、我强烈建议我们找到一种方法来将 app_pe66.oe66的所有部分分配 给内部存储器。"
因此、分配给外部存储器似乎导致上下文切换花费的时间比预期的要长得多。