[参考译文] TMS320F2.8335万：GPIO输出有问题

我将在本设备上与专家进行循环。

NIMA

您好，

我看到测试过的代码，但我有一些问题。 当显示"50ns Delay between two GPIO (两个GPIO之间的延迟为50ns)"时，这是两个GPIO上升之间的测量时间，还是GPIO上升需要多长时间？ 如果是前者，可能是由于多种原因，最重要的原因是编译代码的位置。 如果代码在闪存上运行，则每个周期至少有5种等待状态，这可能会延迟指令之间的时间。 如果代码在RAM上运行，您可以显示反汇编，以帮助阐明CPU级别上发生的情况。

由于代码的运行方式(如果不满足条件，则需要刷新管道)等原因，带while循环的代码本身就会更长。这是C代码，并且固有 的优化程度不会像汇编那样。 如果您发现50 ns和150 ns的时间是指什么，请告诉我。

Omer

您好，Omer：

请参阅我们客户的回复：

它是指两个GPIO上升之间的测量时间，可在附件中找到。 此外，我可以简要描述我对DSP的需求，即我需要根据附件中显示的两个输入脉冲控制PWM。 因此，我非常关注GPIO输入捕获和输出生成的延迟。 GPIO输入和输出似乎都存在延迟问题。 我知道检测GPIO和生成PWM的中断方式将更加耗时。 如果可能，是否有实现快速GPIO检测和生成的最佳解决方案？

此致，
卡洛

您好，Omer：  

非常感谢！ 我已根据您的建议再次检查了代码和GPIO。 还有几个问题：

ePWM：

1.虽然 ePWM是控制PWM的最佳方式(我 也经常使用)，但它不能处理我现在遇到的实际情况，即PWMH和PWML期间 都 由输入脉冲决定，如上图所示。 那么，您认为ePWM是否具有 这样 的功能，仅根据输入触发信号生成PWM？   

代码时间：

2.1 最大上升/下降时间8ns对50ns延迟没有影响，因为我测量的时间  基于 GPIO开始上升或下降的起点， 如上图所示；

2.2 I已检查了拆卸，代码'GpioDataRegs.GPACLEAR.bit.GPIO5 =1'采用了由CCS测量的4个系统时钟，其中包括两个汇编代码。 因此 ，它似乎需要 4*6.3ns。

 2.3 我对'如果代码在闪存上运行，每个周期至少有5个等待状态'感到困惑，那么您是否意味着每段汇编代码还要消耗5个系统时钟？ 如果是这样，那将是非常接线的。

王磊，您好！

1.我可以通过ePWM专家来更好地回答这个问题。

2.1 我不确定我要传达的内容是否清晰，因此我在下面插入了一个图表，显示了我的意思。 根据F2833x数据表，上升/下降时间最多应为8 ns (请参阅下面列出的部分和页码)。 如果这是您正在做的事情，请向我展示示波器图像，其中此过渡需要50 ns。 图中未说明时间T，因为这取决于代码的编译方式/编译位置(下面列出的切换时间是切换单个GPIO的时间，而不是将一个高调到另一个低调)。

2.2 线路 'GpioDataRegs.GPACLEAR.bit.GPIO5'是清除GPIO位的最优化指令，如您所见，但 由于指令集，这仍需要1个周期以上。

2.3 是的，在闪存上运行代码本身就较慢。 查看器件的数据表，这就是我发现的(请参阅 数据表7.9 ．7.5 部分的表7－4，第95页)；系统时钟频率为150 MHz时，有5页/随机等待状态。

如果还有其他问题，请告诉我，我一定会联系ePWM专家，帮助回答您的第一个问题。

此致，

Omer Amir

感谢您的考核。 正如我之前所预期的，嵌入式ePWM没有此类功能。 至于中断的方式，它将导致输入脉冲触发的PWM的明显延迟。

此致，

LEI

1.感谢您的被动态度，耐心回答。

2.我已重新澄清如下：

3.是的。 GPIO寄存器的操作似乎比其他寄存器的操作慢。  

4.我认为等待状态 并不是每条指令都跟着，否则在闪存上运行的DSP将会非常慢。 一般而言，闪存上运行的代码是否比ROM上运行的代码慢，对吗？  

非常感谢。 与您讨论后，我似乎必须使用FPGA或CPLD。 非常感谢您的帮助，您现在可以关闭案例。