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

[参考译文] 编译器/处理器 SDK-AM437X：在 PRU#39；s 之间共享变量

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/659580/compiler-processor-sdk-am437x-sharing-variables-across-pru-s

器件型号：PROCESSOR-SDK-AM437X

工具/软件：TI C/C++编译器

你(们)好

通过在链接器命令文件中创建共享段、是否可以在两个子系统的内核(例如 PRU-ICSS1的 PRU1和 PRU-ICSS0的 PRU1)之间共享变量？  

与下面的链接类似
https://e2e.ti.com/support/arm/sitara_arm/f/791/t/619957
根据 AM437x TRM 的本地数据存储器映射部分、每个 PRU 内核都可以使用本地地址访问其他子系统存储器。

PRU-ICSS0的 PRU1能够使用类似的直接本地存储器地址访问 PRU-ICSS1的 PRU1的共享数据 RAM
volatile unsigned int* PWM_OUT =(volatile unsigned int *) 0x57f00；

但无法通过链接器命令文件中的共享段和 C 文件中的 pragma 指令进行访问、如所示 

AM437X_PRU_SS0.cmd
GLB_BUF ：org = 0x00057f00 len = 0x000000ff
.share_buff > GLB_BUF，第1页
main.c
#pragma DATA_SECTION (share_buff、".share_buff")
volatile struct shared_mem share_buff；


上述代码编译并成功加载、但在尝试访问该位置时失败、抛出以下错误
[124.621794] remoteproc remoteproc3：错误的地址 da 0x57f00 mem 0x6
[124.632569] remoteproc remoteproc3：加载程序段失败：-22

我是否遗漏或 出错了？

谢谢

  • 0
    TI__Guru**** 2618835 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    Puneeth、您好！
    我下周将深入了解这一点、然后再回到您的位置。

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

    我们热切期待您的帮助、以便冻结我们的固件部件。

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

    Puneeth、您好！

    很抱歉耽误你的时间。

    1) 1)对于 PRU-ICSS0的 PRU1、该存储器块是否为只读存储器？

    2) 2)如果您用类似的简单变量替换结构、您是否仍然会遇到错误 

    #pragma DATA_SECTION (share_buff、".share_buff)
const unsigned char share_buff； 

    或 

    #pragma DATA_SECTION (share_buff、".share_buff) 
    volatile far uint32_t share_buff；

    此致、  

    Nick

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

    你(们)好 Nick

    1) 1)我使用以下变量运行了几个测试、但在访问时仍然抛出错误。 

    #pragma DATA_SECTION (test_var、".test_buff)
volatile far uint32_t test_var；
以及 far
const unsigned char test_var；

    编译时没有错误。  

    2) 2)我们将其用于读取和写入目的。

    谢谢

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

    Puneeth、您好！

    问题似乎是您尝试从 AM437x_PRU_SS0.cmd 文件访问存储器位置0x0005_7F00。 Linux 在加载固件时将每个子系统视为自己的独立实体(因为如果您要加载 ICSS1、则不知道 ICSS0资源是否已启用、反之亦然)。 因此、ICSS1链接器文件只能看到 ICSS1的 PRU_DMEM_0_1、 PRU_DMEM_1_0和 PRU_SHAREMEM、ICSS0链接器文件只能看到 ICSS0 的 PRU_DMEM_0_1和 PRU_DMEM_1_0。 在 PRU 内核已加载运行后、ICSS0内核可以访问 ICSS1的共享数据。

    1) 1)如果您不希望在 PRU 固件加载到 RAM 时将值加载到共享变量中、并且  在加载 PRU 固件时未将任何其他代码加载到 ICSS1 PRU_SHAREMEM 中、 然后、无需在任何一个 ICSS 链接器文件中创建条目。

    例如、以下 AM437x_PRU_SS1.cmd 代码仅将固件加载到 ICSS1 PRU_DMEM_0_1 (不是 PRU_SHAREMEM)： 

    SECTIONS｛
//*强制_c_int00到 PRU IRAM 的开头。 在加载
ELF 文件时不需要、但在加载二进制文件时很有用*。
text：_c_int00*> 0x0、page 0
.text> PRU_IMEM、page 0
.stack> PRU_DMEM_0_1、page 1
.bss> PRU_DMEM_0_1、page 1
.CIO> PRU_DMEM_1、page

1 .1_1、PRU_1数据交换> PRU_1、.CIO 1 第1页
.sysmem> PRU_DMEM_0_1、第1页
.cinit> PRU_DMEM_0_1、第1页
.rodata> PRU_DMEM_0_1、第1页
.rofardata> PRU_DMEM_0_1、第1页
.farbss> PRU_DMEM_0_1、


第1页 DMU_1页.fardata > PRU_1页、PRU_DMEM_1页.fardata 1页> PRU_1页.farem_1页、PRU_1页.farem_1页、PRU_DMEM_1页、PRU_DMEM_1页.

    在这种情况下、不要向链接器文件中添加任何内容、只需使用指针从 ICSS0访问 ICSS1存储器、如您所述： 

    volatile unsigned int* PWM_OUT =(volatile unsigned int *) 0x57f00；

    2) 2)如果在 PRU 固件加载到 RAM 时需要将值加载到这些变量中、或者  在加载固件时要将其他代码加载到 ICSS1 PRU_SHAREMEM 中、则应在 AM437x_PRU_SS1.cmd (而不是 SS0)中进行输入。

    在第2种情况下、您仍将使用 ICSS0中的指针来访问 ICSS1中的存储器。

    在第2种情况下、如果您不需要将值加载到共享变量中、但要将其他代码加载到 PRU_SHAREMMEM 中、则最好尝试针对该段使用 NoLoad 指令。

    此致、  

    Nick

  • 0
    TI__Guru**** 2618835 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    第二种方法符合我们的要求。
    感谢您回复伪代码和说明。