[参考译文] AM5728：MessageQ 问题

Rob、

我想确保您找到了：

processors.wiki.ti.com/.../Processor_SDK_Linux_IPC

这更像是一个 Linux 透视图、其中包含许多有用的链接。 希望它能帮助...

我们的 Linux MessageQ 所有者在城外待了几天、因此他将在回来后尽快回来。

就像过去了很多天一样继续跟进。

我注意到在运行 SYSBIOS 的 DSP 上、堆是在 cfg 文件中创建的、说明代码中没有堆。 这在 Linux 中是否相似？ 它是否在其他地方进行？

在哪里可以找到一些有关 MessageQ 中内置的同步对象(Linux 和 DSP SYSBIOS)的文档。 我假设这样做是为了使您可以有效地使用同步对象来通知 MessageQ 的另一端消息正在等待、并"同步"对其访问的使用。

谢谢。

Rob、

很抱歉耽误你的时间。 此文档尝试帮助解释一些 MessageQ 详细信息：

processors.wiki.ti.com/.../MessageQ_Module

我的发言来自：
如果目的队列为本地队列、则消息将放置在相应的优先级链接列表中、并调用 iSync 信号函数。 如果目的队列在远程处理器上、则消息将被发送到正确的传输并返回。

对于 ARM <->DSP、正在使用 rpmsg 传输协议。 rpmsg 使用硬件邮箱通过中断同步内核。

Linux 方面的一个很好的示例是位于/usr/share/ti/ti-ipc-tree/linux/src/tests/MessageQApp.c.上的 SDK 的根文件系统

本视频可能对提供良好的概述有很大帮助：

training.ti.com/am572x-build-run-ipc-examples

许多文件已经在 Linux SDK 中、并不需要像视频所暗示的那样构建。

希望这对您有所帮助。

您好、Rob、

您提到的同步对象是哪个网站？ 它是 RTOS IPC 用户指南中的 MessageQ 文档吗？ 大数据 simple_buffer_example 显示了 ARM 和 DSP 之间的数据传输、但该文档仅适用于 DSP。 因此、并非所有内容都适用于 Linux 端、尤其是同步对象。 您对该框架的了解太深。 提供的 API 应改为使用。 大数据使用2个堆、一个用于第一个堆的 MessageQ 设置、这与其他非大数据示例相同。 对于大数据、它需要 CMEM 的较大连续空间(作为第二个堆)来保存数据。 这是代码中的 src1Heap。 该示例展示了如何通过调用 MessageQ_create 和 MessageQ_open 来设置 MessageQ。 在 App_exec 中，它设置 CMEM 和 sharedRegion，然后通过调用 HeapMem_create 为大数据创建 HeapMP。  大数据下有一个 HeapMem 目录用于堆管理。 您应该在其中查找堆 API。

希望这些信息能解答您的问题。

雷克斯

感谢您的回复。  我现在对任何东西都不是很深入。  更多丢失、不跟踪。

也许我可以从这个开始：

如果我们以 IPC_3_47_00_00示例/DRA7xx_BIOS_elf\ex02_MessageQ 为例。

在 MaineDSP 中的任一 DSP 下、它调用：

remoteProId = MultiProc_getid ("主机")；

因此、我理解这意味着它将向主机处理器获取一些句柄/标签。  然后继续将 IPC 附加到该 RemoteProId ... 因此这很有意义... 每个 DSP 都将启动、运行此代码、联系、查找主机、并将其 IPC 附加到该主机。

此外，server_init()中 server.c 中的每个 DSP 都调用 Registry_AddModule (...，module_name)，其中 module_name 是 Server

因此、这看起来就像它用一个"服务器"名称对每个 DSP 进行"堆叠"。。。

Q1： 为什么每个 DSP 不使用多处理器功能？  为什么它不为每个 DSP 指定唯一的名称？

然后看一下主机代码、首先我看不到它在任何地方"重新生成"它的名称... 因此、这就提出了一个问题、即当 DSP 要求查找主机时、它们是如何查找主机的... 主机的"注册"在该代码中隐藏在哪里？

在 MainHost.c 的主机端、它还调用 MultiProc_getid (服务器)；

由于两个 DSP 都将自己注册为服务器、那么目的是否明确？  那么、当您在主机端调用 IPC_Attach 时、它会连接到这两者吗？

如果是、那么在 Multiproc 文档中、为什么您有这样的内容：

MultiProc.setConfig("DSP"、["视频"、"DSS"、"DSP"])；

对我来说、这表示您将3个可用器件的名称设置为 DSP ... 因此、在我们的案例中、它可能是：

MultiProc.setConfig("DSP1"、["DSP1"、"DSP2"、"ARM")；

或

MultiProc.setConfig("ARM",["DSP1"、"DSP2"、"ARM")；

您是否看到了混乱？

这是 AM5728的错误示例文件还是过期？

这只是解决了我对 Multiproc 部件的看法...

关于堆。

在 SYS/BIOS 中、我弄清楚了如何使用您的工具 XGCONF、我发现您基本上是在它们中分配堆、因此、即使在列出的 IPC 参考中、您也在初始响应中声明了它讨论调用堆函数、 在 SYS/BIOS 中、您似乎已经"隐藏"了、这样我就不必在代码中明确地调用它了。。。 但是、当读取 wiki 时、首先不清楚为什么当我查看示例代码时、你没有在任何位置分配堆(因为它是在 SYS/BIOS 中完成的)...

在 Linux (ARM)方面、这种情况发生在哪里、或者我们是否需要在代码中手动执行？

从概念上讲、我要关注... 但我在遵循我使用或不使用的不使用的不使用的不使用的不使用的情况下，遇到了很多问题，这是强制性的，等等。。。。

关于同步、如果您转到讨论线程同步的位置、则在您提供的第一个列出的链接中是... 它讨论了信号和等待函数的存在方式...   

当我从 ARM 调用 MessageQ_Put ()到 DSP 或 DSP 来对其进行 ARM 时，我不清楚如何使用这些函数。  在一个示例文件中、它显示我们可以传递一个参数来获取函数、该函数基本上是说要等到它获取某个内容... 这样可以有效地锁定处理器等待接收数据...  您能否要求它"检查是否有消息、如果没有、则立即返回？  您能否设置基于"中断"的事件机制、以便在发送消息时触发中断、以便接收处理器进行响应、或者是否严格轮询接收处理器/线程必须调用"检查消息"功能... IE 正在轮询 IT ...

因此、同步对象的问题是：

我们是否将它们与处理器间 MessageQ 一起使用？  还是仅使用同步对象的同一处理器上的本地线程？  我们能否在接收处理器上设置中断类型 MessageQ？

这有道理吗？

非常感谢您的支持。

很抱歉、这更像是一个理解问题、因此它不是很简明或非常清晰。

您好、Rob、

您确实意识到您指出的 MessageQ 示例适用于 RTOS 应用程序。 对于 Linux-RTOS 示例、它应该位于 DRA7xx_linux_elf 目录下。 对于 Linux-RTOS MessageQ 示例、所有 DSP 内核都作为服务器运行并等待来自主机的消息、主机/应用程序会将消息发送到 DSP 内核、如参数所示。 收到消息的任何人都会回复。 ex02_MessageQ 不是多核应用的好示例。 我将有一位 DSP 工程师来回答这部分问题。

MessageQ_get 确实有一个超时参数。 MessqgeQ_forever 设置为0xFFFF。 将其设置为0应立即返回。 MessageQ_get 会等待一个信标、邮箱中断会将其释放。  它被中断触发在后台由 IPC 处理所有到邮箱的挂钩中断。  

这取决于您的应用程序尝试执行的操作。 如果只需要发送/接收消息、则 MessageQ API 就足够了。

雷克斯  

非常感谢。 除了解决处理器寻址的多核问题外、DSP 工程师还能回答使用 Registry_AddModule 函数与使用 MultiProc 函数的对比。

谢谢。

您好、Rob、

DSP 工程师的回答如下：

" ex02_MessageQ 示例中的此行、  

   结果=注册表 AddModule (&Registry_CURDESC、MODULE_NAME)；

仅用于记录。

在 MainHost.c 中，您将看到此调用，

   remoteProId = MultiProc_getid (服务器)；

其中服务器是在文件顶部定义的、

   #define 服务器"DSP1"

因此、如果我们要使用 DSP2、我们将更改此定义。

MessageQ 然后使用上面的 RemoteProId 检索远程处理器的名称、并将其用作消息的唯一密钥。

System_sprintf (msgqName、App_SlaveMsgQueName、

   MultiProc_getName (remoteProId))；

   操作

   ｛

     状态= MessageQ_open (msgqName、&Module.slaveQue)；

DSP 通过  cfg 文件添加其 ID xdc.global.procName="DSP1"、该名称必须包含在 ipc.cfg.xs 中：VAR procNameAry =["DSP1"、"DSP2"、"EVE1"、"EVE2"、"EVE3"、"EVE3"、"EVE4"、"IPU1"、"IPU2"、"host"]；"

如果信息回答了您的问题、请单击"已解决"按钮。 谢谢！

雷克斯

感谢您的帮助。

我能从这一点推断出、如果主机想与两个 DSP 进行通信、您会说：
remoteProId = MultiProc_getid (SERVER1)；
remoteProceId2 = MultiProc_getid (SERVER2)；

其中、SERVER1和2是 DSP1和 DSP2

然后、我将调用 IPC_Attach (remoteProId)；
和 IPC_Attach (remoteProId2)；

这是否会在主机和 DSP1以及主机和 DSP2之间正确连接 IPC 的底层硬件？

这是我了解的 RTOS RTOS 示例。

如果我看一下与 Linux-RTOS 代码稍有不同的代码、它看起来就像您调用的主机中：

MultiProc_getName (RemoteProceID)

创建消息缓冲区打开名称的 sprint 函数内。

我在这个中没有看到任何 IPC_Attach 调用？

在这种情况下、如何在 IPC_START 中处理所有 IPC 设置？



您是否在任何地方概述了我何时应调用的函数调用？

那么、如果我有一个运行 Linux 的 ARM 和两个运行 SYS/BIOS 的 DSP、我可以阅读哪些文档、这些文档将向我展示我应该调用哪些函数？

谢谢。

您好、Rob、

所有 API 均位于 IPC 用户指南中。 IPC 模块 API 位于 processors.wiki.ti.com/.../Ipc_Module 中

在 RTOS-RTOS 情况下、使用 ProcSync_pair 配置 DSP、并且需要 IPC_attach()调用。

在 Linux-RTOS 情况下、Linux 从 LAD 获得配置、该 LAD 使用 ProcSync_all 进行配置。 因此不需要 IPC_attach()调用。

IPC 模块文档中介绍了 IPC 同步过程、介绍了不同 ProcSync 选项的行为。

我们发现 Linux 中从 LAD 获取配置的文档存在差异。 我们将相应地更新文档。

雷克斯