各位专家、您好！
我的客户使用 F28377D 创建了电路板、但我发现 GPIO 行为不清楚。
问题1：我们注意到 GPIO 输出存在延迟、这是否是预期行为？
问题2：如果以下用法不是问题、是否有任何方法可以消除延迟？
Q3：如果无法缩短延迟时间、您能否分享有关延迟的规格(时间规格)？
[详细信息]
他们通过仅使用在 RAM 上运行的 CPU1而不使用中断来检查这一点。 它们分别使用 GPIO11、12、13来写入设置/清除、切换和 DAT 寄存器、然后读取 EMIF1一次以等待时间(1us)。
随附了总体波形和 GPIO11 =低电平到高电平部分的放大版本。 对于这两个端口、C 源和汇编器输出显示 EMIF1读取前的 GPIO 输出、但波形显示的是按照该顺序在 GPIO 输出前读取 EMIF1。
这个结果表明 GPIO 输出始终存在延迟、但是请告诉我是否还有其他需要检查的点或需要添加或更改的条件。
我们还想检查 CPU2和 CLA 是否存在冲突和延迟、但如果您可以先回答上述问题、那将会有所帮助。
此致、
还不错
您好！
根据 F2837xD 数据表(第8.9.6.1节)第74页上 GPIO 的时序规格、将 GPIO 从低电平更改为高电平或从高电平更改为低电平的最大延迟为8ns。 如果您使用闪存运行程序、该时间可能会更长。 这种延迟无法消除、因为微控制器将始终具有一些物理延迟、以便信号从程序存储器传输到外设。
此致、
Omer Amir
您好、再说一次、
如果您正在讨论程序写入寄存器的延迟并查看其中的值、这是一个与代码相关的延迟。 此延迟可能由 CPU 流水线引起(如下所示)。 在_GPIO_TEST 汇编代码的第8行和第9行中，“OR”实际上是一个写操作，它将在流水线中最后发生。 下一条指令“MOV”是读取，即使在“或”之后提取，也会在写入之前发生。 由于您是从外部接口读取数据、因此始终比 CPU 时钟速率慢得多、并且会显示您看到的延迟。
由于 GPIO 寄存器或 EMIF 地址范围内没有重叠、因此无需管道来保护写入、使其在 XINTF 读取之前执行。 如果要测试此情况、可以插入一些 NOP、大约3个 NOP 应该足够、写入/读取指令之间应允许首先进行写入。
此致、
Omer Amir
两个 CPU 都有自己的 GPIO 数据寄存器的物理副本、并且这些寄存器的输出是基于 CPUSEL 的多路复用的、该输出在 GPIO 引脚上被驱动。 由于它们有自己的寄存器物理副本、CPU 写入它们自己的寄存器、因此没有冲突。 请参阅"图8-1。 器件 TRM 中的"单引脚的 GPIO 逻辑"、清楚地显示了这一点(下图是该图的快照)。
此致、
Vivek Singh
