[参考译文] TMS320F28388D：ADC 中断至 CLA 任务延迟

Adrien、您好！

是否启用了任何其他 CLA 任务？ 如果触发信号进入时正在执行不同的 CLA 任务、它将在分支到 ADC 触发任务之前完成其他任务执行。

此致、

Delaney

尊敬的 Delaney：

不、这是唯一在 CLA 上运行的任务。 这就是我预计会出现上面提到的准确延迟的原因。 我的任务是用 C 语言编写、而不是用 ASM 语言编写。 以 C 语言编写的这一事实是否会由于上下文保存而增加约12-13 SYSCLK 的额外延迟？

此致、  

Adrien

Adrien、您好！

用 C 语言编写任务不应该是个问题、CLA 编译器通常应该能够生成高效的代码。 但是、GPIO 是在任务开始时使用 GPIO_writePin () driverlib 调用还是使用直接 HWREG 寄存器访问来切换？ 我 之前在 CLA 上看到过 GPIO_writePin ()函数的问题、增加了额外的周期。 如果 GPIO 写入仅用于调试/探查目的、我建议直接写入 GPDAT 寄存器、例如如下所示：

HWREG(GPIODATA_BASE + GPIO_O_GPADAT) &= 0x0001;

此致、

Delaney

尊敬的 Delaney：

我不使用 driverlib。 我使用 TI 提供的寄存器结构直接写入 GPDAT 寄存器。

因此额外的延迟必须来自其他某个地方。

我已经尝试关闭编译器的优化、仅保留用于切换 GPIO 的指令(以及用于清除标志的指令)。

结果相同、我仍测得300ns。

此致、

Adrien

 Adrien、您好！

Delaney 目前不在办公室、她将在下周返岗时尽快与您联系。

此致、

Allison

Adrien、您好！

您是否可以访问调试器？ 您是否可以尝试在 CLA 任务的最开始停止调试器(使用__mdebugstop();)并单步执行反汇编以查看 GPIO 写入行是否花费比预期更多的时钟周期？ 我过去在 CLA 上观察到的 GPIO 写入问题是、它在一段时间内一直使用一条指令、而不是反复执行。 如果反汇编中的所有内容似乎都执行顺利、这将排除 CLA 是延迟的罪魁祸首。 如果是这样的话、我将环路 XBAR 和 ADC 专家来研究这个问题。

此致、

Delaney

尊敬的 Delaney：

可以、我可以访问调试器。 你将找到你所要求的内容的屏幕截图。 当我汇编步入时、它似乎执行顺利。

我还附上了我所采取的措施,其中一个范围说明了我在我的第一篇文章中所描述的内容。 我的测量值为986.4ns、而我预计为926.3ns (请参阅文章1)。 我测得的额外延迟为60.1ns、大约为190MHz 处的11个 SYSCLK。 也许,我会满足这种额外的延迟,我只是想知道的原因或如果我错过了一些东西。

此致、  

Adrien

Adrien、您好！

从反汇编来看、我确实认为11个 SYSCLK 周期来自 CLA 任务的开始。 编译器生成8条 MNOP 指令和4条指令来实际写入 GPIO。 请记住、许多指令也会花费多个 SYSCLK 来完成。 如果您想确认所有11个周期都在这段时间内发生、则可以使用 CCS ( 此处链接)中的分析时钟功能。 在命中调试内在函数时启动时钟、并单步执行反汇编、直到您到达 GPIO 写入指令的末尾。

您还可以尝试 在工程设置中使用编译器优化来缩短时间。 但是是的、我认为这是根据反汇编中的说明预期的。

此致、

Delaney