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.

[参考译文] AM3359:PRU DRAM 与 PRU RAM 访问

Guru**** 2606725 points


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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/651595/am3359-pru-dram-vs-pru-ram-access

器件型号:AM3359

我们使用 PRU 上的汇编器代码来实现快速 IO 采样和时间戳。 通过 PRU 共享12KB RAM 中的寄存器接口从 Linux 控制 PRU。 其中一个寄存器是 DRAM 中一个大环形缓冲区的地址、该缓冲区使用 Linux cmem 驱动程序进行分配。 PRU µs 与外设 GPIO 器件的 SPI 连接、并每4 μ s 检查一次 IO 状态。 发生更改时、包含新状态和更改时间的事件结构将使用 sbbo 指令写入 DRAM 环缓冲区。 执行该指令后、PRU 本地 RAM 中的寄存器将更新为指向环形缓冲区中新事件的指针、再次使用 sbbo 指令。

从 Linux 读取 PRU 本地 RAM 中的事件指针寄存器时、有时会更新 PRU RAM 寄存器、但 DRAM 环缓冲区不包含新的事件结构。 短时间(几毫秒)后、将出现新事件。

我假设 PRU RAM 写入/读取周期比 DRAM 写入/读取周期快、即使 PRU 首先写入 DRAM、而 Linux 首先从 PRU RAM 读取也是如此。 如果是、是否可以对存储器访问进行序列化?

另一个可能的原因可能是 DRAM 被缓存、并且未注意到物理内存的变化。 DRAM 环形缓冲器在 Linux 用户空间应用程序中使用标志 PROT_READ | PROT_WRITE 和 MAP_SHARED 进行 mmwed。 在访问存储器之前、是否有办法使数据高速缓存行无效?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    软件团队已收到通知。 他们将在这里作出回应。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    Martin、

    请参阅此 Wiki 页面、其中介绍了 AM335x 器件中 PRU 视图的访问延迟 :processors.wiki.ti.com/.../AM335x_PRU_Read_Latencies

    需要注意的一个重要事项是、PRU 的写入指令是非阻塞式的、将在单个周期内完成(无论写入的存储器是什么、还是数据是否已到达)、而读取指令将在数据到达之前阻止。

    您还将在读取延迟表中看到、对本地存储器的读取访问大约需要3个 PRU 周期、而从 DDR 读取大约需要36个 PRU 周期、而 OCMC RAM 访问大约需要27个周期。 这些是最佳情况值。 如果共享存储器总线处于重负载状态、则这些周期时间可能更长。

    假设写入延迟与读取延迟类似、则可以正确地看到、尽管按照汇编指令的顺序、本地写入实际上是在外部写入之前发生的。

    尝试的一件事是在您的 DRAM 写入指令之后立即添加 DRAM 读取指令(到同一地址)。 这将阻止 PRU、直到读操作返回、并应确保您的写操作完成。 读取指令返回后、在本地存储器中移动指针应该是安全的。

    Jason Reeder

    电源 我的理解是、使用 map_shared 应该阻止内存被缓存? 您是否还在变量上使用 volatile 关键字以确保未使用本地副本? 如果上述写入、读取、写入建议不起作用、则可能需要进一步调查用户空间方面的问题。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    Jason、

    我尝试在写入后立即添加加载指令、但问题仍然存在。 我调试了汇编器代码、并测量了两个 mem 访问指令的执行时间、这两个指令是17个写入节拍和70个写入节拍、与 wiki 页面上的时序非常匹配。 但是、我注意到、寄存器在读回时会发生变化。 看起来、读取访问会截断写入访问。

    您在建议中写下了"应该"的内容。 您是否确实确定在读取返回后写入存储器、或者是否有可能我的发现是正确的?

    不过、我还会再次调查我的用户空间代码。 我的事件索引计算中可能有问题、我正在查看最近事件之后的第一个事件或类似事件。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    Martin、

    我已经问过一位同事、读访问是否可以通过较短的路径路由(或以某种方式优先于写访问)、然后在写操作发生之前返回。 我希望他们的回复会延迟到假期后、但我会在他们回复后通知您。

    一种万无一失的方法是写入存储器、然后在循环中读取存储器、直到返回预期的值。 这将保证存储器已经被写入。 如果问题在此之后仍然存在、我们需要进一步了解您的索引计算和可能的缓存。

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

    无需着急。 我也不在办公室两周、在我回到工作岗位之前无法测试任何内容。 但我当时正在考虑另一种解决问题的方法。 我可以将指向 PRU RAM 中最新事件的指针移动到 DRAM 缓冲区的开头。 当确定连续两次写入 DRAM 的操作不会被重新排序时、我的问题就会得到解决。 您能否找出至少是这样的情况吗?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    Martin、

    我的理解是、从同一个主器件(在本例中为 PRU)到同一存储器目标的连续写入应按照发出的顺序完成。 但是、如果我的理解有误、我再次要求我的同事进行澄清。 我会在收到回复后通知您。

    Jason Reeder