[参考译文] TMS320F28379D：将 SPI 数据发送和接收过程发送到 CPU2

这应该是可行的。  

不过、我想知道您的 SPI 传输是否已优化。 如果不是、尝试对其进行优化而不是在两个 CPU 之间划分软件是否更有意义？ 一些您可以使用的 SPI 优化：启用 SPI FIFO 以使 SPI 总线尽可能繁忙、使用 DMA 传输数据以减轻 CPU 的负担。

在您的软件流描述中、您提到：

Unknown 说：

ISR
----------------
*读取传感器数据
*读取电流
*执行控制算法  
*确认 ISR ,启用进一步的中断[/报价]

据此、我假设读取的传感器数据会阻止 ISR 中的后续步骤。 我想、如果您能够更快地获取传感器数据、就可以更快地完成 ISR。 如果我的假设不正确、请告诉我。  

Unknown 说：

对于我正在使用的设备，4 MHz 串行时钟是我可以操作的最大时钟频率。 在这个频率下、我的示波器上的每个完整数据事务都需要12.6微秒。

 在本例中、您实现的 SPI 总线负载是多少？ 换句话说、100%负载意味着您可以在12.6us 内传输12.6us * 4Mhz = 50位。 如果 SPI 传输中存在大量死区时间、则可能是由于 SPI 例程的结构所致。 例如、如果将数据写入 SPI、则会轮询数据以完成传输、然后写入新数据、这会引起一些 CPU 延迟损失。 您可以使用 FIFO 并执行以下操作：一次将8个字符写入 SPI FIFO、然后等待所有字符的传输。  

[/quote]

Gus、您好！

我的数据事务使用两个单独的 SPI 模块。 我在事务期间在下面附加了一个串行时钟波形的图像。  

                    

完整的传感器事务需要12.4 us。 单个 SPI 事务耗时3.6us。 事务之间的时间为0.8us。 每个 ISR 都会执行此过程。  

我想知道您提到的更改会如何影响我的 SPI 数据事务波形？ 我认为我的波形中没有太多的死区时间？

chunjiang dai 说：

据此、我假设读取的传感器数据会阻止 ISR 中的后续步骤。 我想、如果您能够更快地获取传感器数据、就可以更快地完成 ISR。 如果我的假设不正确、请告诉我。  

[/报价]

是的、您的假设是正确的。

Unknown 说：

我想知道您提到的更改将如何影响我的 SPI 数据事务波形？ 我认为我的波形中没有太多的死区时间？

您可以消除0.8us 死区时间(假设从器件支持此功能)、但您是对的、它不会将总传输时间缩短超过1.6us (0.8us x 2)。 是否可以选择更高的 SPI 时钟速度？

Gus、您好！  

我仔细查看了器件数据表、发现我实际上可以在8MHz SPI 时钟下工作。 目前、这允许使用20KHz ISR、但是、我用于向 ISR 添加更多代码的空间非常小。  

我认为我可能必须在第二个 CPU 上执行 SPI 事务、或者在可能的情况下、使用具有嵌套中断的并发处理(如果可能的话)、不过我觉得合适的选择是将 SPI 事务发送到第二个 CPU。

你怎么看？  

大家好、Gus、

我当时想使用第二个 CPU、对于如何进行设置、您有什么建议吗？ 我好像无法在 CPU2上设置 GPIO。 或者、您是否建议我打开一个新问题？