[参考译文] BEAGLEBN：PRU EGPIO 时序

您好！

显然、这是需要额外周期的"while"循环。 您应该检查编译器生成的汇编代码。

Biser、

感谢您快速回答问题。

我再次验证了 asm 代码。 由于 clpru -O3优化、while 环路仅为一行(第166行)、开销为5ns。

请参阅列表中的摘录：

    145；------------------------------------------------
    146；162 |_R30 |=(1 << 12)；//设置 PRU1.12                                     
    147；---------------
    148 00000004 0000001F0CFEFE         设置      r30、r30、0x0000000c ；[ALU_PRU]|162|
    149；*---------------------------------------------------------- *
    150；*  开始循环||$C$L2||
    151；*
    152；*  循环源代码行               ：163
    153;*  循环右括号源代码行 :164.
    154；*  已知最小行程计数       ：1.
    155；*  已知最大行程计数       ：4294967295
    156;*  已知最大行程计数因子    ：1.
    157；*---------------------------------------------------------------- *
    158 00000008                ||$C$L2||：    
    159；***   ------------------ G3：
    160；*** 163       ------------    如果(！(_R31&0x80u))转到 G3；
    161       .dwpsn 文件"pru1_buslaters.c"、第163行、第10列、is_stmt、ISA 0
    162；----------------------------------------------
    163；163 | while (！(_R31和0x80))                                                
    164；164 |        ；//等待 DATAIN7的回读                            
    165；--------------------------------------
    166 00000008 000000C907FF00         QBBC     ||$C$L2||、R31、0x07 ；[ALU_PRU]|163|

 

同时、我尝试计算 PRU 直接输入的频率响应。
数据表中
          sprs717j.pdf、第7.14.1.1章、
GPIO 输入在内部加载的最大值为30pF。
输出可以在3.3V 时驱动6mA、因此假设它们具有500 Ω(静态直流)
当 f = 1 /(2 * PI * R * C)时、我计算的低通频率为
1 /(6.3 * 500 * 30E-12)= 10MHz、导致周期为100ns
当我针对要读回的单个低电平/高电平测量40ns 时、该尺寸大致相同。
    
如果内部低通是我的延迟的解释、那么您需要使用来驱动 PRU 直接输入
阻抗约为50欧姆、可达到100MHz。 你同意吗？

不过、这只是一个测试设置。 我的真实电路使用74LVT541总线驱动器来驱动 PRU 输入、该总线驱动器可以驱动50mA (而不是测试中的6mA)。 这会导致 R=66欧姆、截止频率为80MHz、但我在那里具有相同的40ns 响应时间。

再次感谢、

Joerg Hoppe、PEAK System Technik GmbH

 

 

Joerg、您好！

您使用的是 GPI 的默认直接输入模式还是不同的模式？

此致、
Nick

Nick、

我不确定"模式"是什么意思。 也许这里有一些需要学习的东西？

我的软件使用简单的并行输入/输出： 无本地 PRU 多路复用、无移位寄存器。

实际上、除了在 clpru 的""_c_int00_noinit_noargs"启动例程中进行初始化之外、我没有设置任何 PRU 配置寄存器。

引脚配置(引脚复用)寄存器的值为0x2e：

SLEWCTRL 0x40 =0：快速

RXACTIVE 0x20 = 1：输入接收器激活

PULLUDEN 0x8 = 1：上拉/下拉被禁用

感谢您的回答、

Joerg

Joerg、您好！

1) 1)为了确保您处于直接输入模式：
查看 AM335x TRM 部分"PRU 模块与 PRU I/O 和 INTC"、尤其是"通用输入(R31)：增强型 PRU GP 模块"小节。 通用输入模式直接输入将比输入模式16位并行捕捉更快。

在直接输入模式下、回送不会花费8个时钟。 我正在深入研究硬件、以便更好地了解应该达到的预期目标。

2) 2)我正在尝试更好地了解加载：在 BeagleBone 上、您要将引脚 PR1_PRU1_PRU_R30_12与引脚 PR1_PRU1_PRU_R31_7之间的导线连接起来、并且不做其他更改？ 在您的电路板上、您要对74LVT541总线驱动器使用什么回路设置？

供参考、您的66MHz 示例有道理：
while (1)｛
_R30 |=(1 << 12)；// 5ns
_R30 &&~(1 << 12)；// 5ns
｝//分支花费5ns

此致、
Nick

我对您的应用也有点不清楚。 您是否正在执行 PRU_GPO 到 PRU_GPI 环回、或执行其他操作？ 它看起来是什么样子的？

我很想查看您测得的波形。 如果不看汇编、我希望波形的逻辑低电平部分是额外的时钟周期、而不是逻辑高电平、因为 while 环路底部有分支/跳转指令。

此致、
Nick

Nick、

感谢您的意见。

1)> 1)将直接输入模式置为有效。

一个"16位并行捕捉"的输入模式将解释一个更长的输入读取时间。 但我认为这不是问题。

-当我阅读 spruh73n 章节4.4.1.2.3.2时、我需要在 GPI16 PRU1_16处使用时钟信号来查看"并行 CPOTI"模式下的任何输入。
-我知道对于直接输入模式、GPCFG1<1：0>= PRU1_GPI_MODE 必须为0。
通过"PRU_cfg.h"、这现在由"CT_CFG.GPCFG1_bit.PRU1_GPI_MODE = 0"完成。
行为没有改变。

2)> 2)我正在尝试更好地了解加载：在 BeagleBone 上、您要将一根线从引脚 PR1_PRU1_PRU_R30_12连接到引脚 PR1_PRU1_PRU_R31_7、并且不做其他更改？
>在您的电路板上、您将使用哪些回路设置来连接74LVT541总线驱动器？

对于测试、我切断 R31.7并将其直接连接到 R30.12、R30.12是一个原本未连接的测试点、仅用于调试。 实际上、它只是一根 R30.12 - R31.7导线、不受我的电路的影响。 但是、在 BBB 上、R31.7是 P8.40、它连接到更多的组件。
我订购了另一个 BBB 和一个原型 Cape、并将"回读环路"设置为单独的项目。

3) 3)由生成的66MHz 波  

while (1)｛
_R30 |=(1 << 12)；// 5ns
_R30 &&~(1 << 12)；// 5ns
｝//分支花费5ns

是一个周期 H 和两个周期 L、如预期：

4) 4)我对您的应用也有点不清楚。
>是否正在执行 PRU_GPO 到 PRU_GPI 回送或其他操作？ 它看起来是什么样子的？

它将成为老式并行计算机总线(DEC PDP-11 UNIBUS)的设备仿真器。

我的电路包含一个64至8输入多路复用器。 64个输入连接到8个74lvth541输入锁存器。 所有锁存器的输出都连接到内部8位总线、
由 PRU1_GPI<0：7>读取。 要读取单个锁存器、PRU1.GPO<8：10>会将地址(0..7)输出到启用所选锁存器的"3：8"解码器74AC138
驱动 PRU1_GPI<0：7>。

我注意到、从"地址输出"到"锁存输入读取"的周期所需的时间要比从74ac138和74lvth541的延迟计算的要长得多。

我调试了这一点、因为读取 PRU1输入的速度比预期慢、 这通过此处所述的"回写"测试进行了演示。

回送测试的波形

while (1)｛
_R30 |=(1 << 12)；//设置 PRU1.12
while (！(_R31和0x80))；//等待直到 DATAIN7上的回读
_R30 &&~(1 << 12)；//清除 PRU1.12
while (__R31和0x80)；//等待 DATAIN7的回读
｝

是：

此致、

Joerg

Nick、

我使用新的 BBB 和该原型 Cape 重复了"回送"测试：

https://www.sparkfun.com/products/12774

输出 P8.21 = PRU1.GPO12以最短的方式连接到输入 P8.40 = PRU1.GPI7
结果：
-使用普通线连接：35ns 延迟
-连接经优化的33欧姆电阻器：30ns

单个内联电阻器用作终端器、抑制过冲/下冲。 请参阅 Graham & Johnson 的"高速数字设计：Black Magic 手册"。

当我在主电路上测量到40ns 延迟时、我们可以将至少10ns 的延迟归因于 布线和信号形状。

在此设置下、我无法获得低于30ns = 6个周期的延迟。

至少这一点再次明确说明：PRU 速度如此之快、我们必须考虑高频信号行为。

也许我们开始竞争：

***  谁能获得超过30ns 的“环回”延迟？  ***

感谢您阅读本书、
Joerg

Joerg、您好！

您能否发布三个 BeagleBone Black 设置的照片、这些照片会导致三个不同的延迟？ 我已开始与我们的硬件工程师讨论、但他们无法直观地了解设置之间的差异。

我将为此进行测试、看看我是否可以复制您的结果。

此致、
Nick

您好、Nick、

这是两张图片。

1) "绿色"板是我正在处理的项目("UniBone")。 我用红色标记了环回的布线。

环回为 PRU1.GPO[12](BBB 接头 P8.21)到 PRU1.GPI[7](BBB 接头 P8.40)。

该信号在电路板上传播一定距离、并通过大约2英寸的折叠扁平电缆而不进行任何热处理。

测量40毫微秒的延迟。

2) 2)在红色原型 Cape 上进行相同的环回。 回送是通过短的47欧姆电阻器实现的。 从而产生大约30ns 的延迟。

3) 3)将47欧姆替换为"零欧姆"线会导致35ns 的延迟。 我没有再添加这张图片... 看起来没有什么不同。

Joerg

Joerg、您好！

我很抱歉耽误你的答复。 来自硬件团队：

电容负载会减慢转换速度。 因此、示波器探头电容可能会增加延迟。

无法判断第一张照片中所示电路板上的整个信号路径是否被路由为阻抗控制传输线。 但是、我怀疑它们没有保持通过带状电缆和带状电缆连接器的恒定阻抗。 第二张照片中显示的板上肯定没有。

当信号未被路由为阻抗控制传输线路时、它可能具有较大的过冲/下冲。 如果是、它们可能需要一段时间才能稳定至有效的逻辑电平。 这可以提供不一致的结果、而不会延迟输入采样足够长的时间使信号稳定。

我还没有时间在我身边运行测试。 请告诉我、您是否需要有关此方面的更多支持。

此致、
Nick

Nick、大家好、

[引用用户="Nick Saulnier">来自硬件团队：

电容负载会减慢转换速度。 因此、示波器探头电容可能会增加延迟。

无法判断第一张照片中所示电路板上的整个信号路径是否被路由为阻抗控制传输线。 但是、我怀疑它们没有保持通过带状电缆和带状电缆连接器的恒定阻抗。 第二张照片中显示的板上肯定没有。

当信号未被路由为阻抗控制传输线路时、它可能具有较大的过冲/下冲。 如果是、它们可能需要一段时间才能稳定至有效的逻辑电平。 这可以提供不一致的结果、而不会延迟输入采样足够长的时间使信号稳定。

[/报价]

我知道第一张图片上的第一个原型在信号质量方面很混乱。
因此、让我们仅对第二张图片上的精简"环回"设置进行处理。

我知道您的硬件团队怀疑 PRU 输出、PRU 输入以及逻辑分析仪探针之间的阻抗匹配不良。
我同意、必须首先纠正信号质量。

根据我的测量结果、我在第二幅图中发现47 Ω 终端器(直接 PRU 输入-输出回路)可以充分减少过冲/下冲。
我可能是错的、会再次专注于波形(可能需要一些时间)。

您的硬件团队能否提供有关"如何构建适用于 BeagleBone PRU 输入的阻抗控制传输线"的链接？
还是绘制第二个电路板设置的建议电路草图？

BBB 设计人员对其电路板了解更多、也许他们已经进行 了"PRU 环回"测试并获得了解决方案。 您可以建立联系吗？

在高速应用中使用 PRU 的任何人都将对这些信息感兴趣。

再次感谢您的努力、
Joerg

Joerg、您好！

我认为阻抗控制更会成为混乱的信号转换问题、而不会导致信号传输所需的总延迟。 这可能涉及设计选择、例如带状电缆中的信号线与接地线交叉。

在环回测试中、使用一条 U 形短导线会在这一侧产生30ns 的响应(使用示波器进行观察时)。 通过使用几英寸长的导线、可以将该值增加到35ns 或40ns。

此致、
Nick

编辑2018年8月15日：测试代码为

您好、Nick、

我理解正确：您在 BeagleBone PRU EGPIO 环回中重现了30ns (=6周期)延迟吗？

我最终使用47欧姆回路电阻器和零欧姆回扫进行了一些测量。  示波器的额定频率仅为200MHz、但将两个信号进行比较表明、过冲/下冲不是问题、至少对于47欧姆电阻而言不是问题。

您对如何继续进行有什么想法吗？ 还是 BBB 只是"按设计工作"？

此致、

Joerg

附件：波形。

A)、带47Ohm 回路(如前面的图片所示)

b)使用零欧姆导线：

Joerg、您好！

是的、看起来这是预期的延迟。 下面是器件设计人员对时序预期结果的估计：

R30写入结束(0ns)-> IO 延迟(3ns)-> PCB 延迟(1ns)-> IO 延迟(2ns)->同步触发器(5ns)-> R31读取(5ns)-> R30写入以进行切换(5ns)

根据他的输入、我很惊讶地看到您的测试的回送结果小于25ns。 30ns 听起来很合理。

降低回送延迟的最佳方法似乎是缩短布线长度。

如果您需要更短的时间(并有时间接收)、则可能需要提升设计的软件元素。 例如、如果 ARM 请求 PRU 更改锁存器、您可能能够加快该通信协议的速度。

此致、
Nick