[参考译文] TDA4VM：使用MCSPI_SLAVE_MODE.C进行SPI分析

您好，Tanvi，

我正在内部检查。
同时，请您分享以下详细信息：
1)您的观察结果是在定制电路板上还是在TI EVM上？
2)如果可能，您能否共享在<pdkInstallPath>/ti/drv/spi/example/mcspi_slavemode/src上所做的修改

此致，
第

您好，Parth：

1.观察结果见J721e_EVM

2.changes附加在文本文件中

同时，我调试了TI提供的默认代码，并发现了相同的观察结果。

在调试过程中，我遇到了这一问题  

SPI_osalPendLock(cbSem[0]，超时)

大约需要1秒的时间。

为什么会这样？

e2e.ti.com/.../5008.changes.txt 

此致，

Tanvi

您好，Tanvi，

我检查过，转账不应该花这么多时间。
您能否分享您如何计算转账时间？

此致，
第

您好，Parth：

请注意：

此观察是在DMA回调模式下进行的

"在调试过程中，我遇到了这一问题  

SPI_osalPendLock(cbSem[0]，超时)

大约需要1秒钟的时间。"

我正在使用TI其它性能分析应用中提供的“TimerP_getTimeInUsecs();”。

下面是我的代码片段

//***************************************************

UINT64_t Pretime，PostTime，objAcc；

如果(转接OK)
｛
   Pretime=TimerP_getTimeInUsecs();//l0
   IF (cbMode)
   ｛
      IF (SPI_osalPendLock(cbSem[0]，timeout)!= SemaphoreP_OK)
      ｛
         Goto Err；
      }
  }  
  PostTime=TimerP_getTimeInUsecs();//l0

  //****  
         保持一切如样
   **//
}

否则

｛

    //****  
         保持一切如样
   **//

}
   RET =真；
   objAcc =(PostTime-Pretime)；//cbMode
   SPI_LOC("cbMode %d\n",objAc);

   错误：
      RETURN (RET)；

//********************************************************************************************************

输出如下所示

/****************************************************************************************

正在启动SPI从属测试。

SPI UT 4.

DMA调用中的SPI主从测试从机
SPI已初始化
从机：通过：TxD来自主SPI通过：
cbMode 99.8618万


DMA callbacd中的SPI主从测试从机

所有测试均已通过。
完成

//********************************************************************************************************

此致，

Tanvi

您好，Tanvi，

我将在结束时重复此内容，以找出问题所在。 将使您随时了解最新信息。

此致，
第

您好，Tanvi，

很抱歉耽误了很长时间。  
以下是目前为止的更新：
我已经能够在我的端重现此问题，正如您之前提到 的，SPI_osalPendLock(cbSem[0]，timeout)大约需要1秒。 我正在对此进行进一步调查，将在当天结束前提供最新情况。

此致，
第

您好，Tanvi，

由于主从之间的同步要求，SPI_osalPendLock(cbSem[0]，超时)正在占用1秒。 基本上，SPI从属设备需要在主中继器启动传输时准备就绪。 为了达到此条件，Task_Sleep用于 masterTaskFxn，由于 SPI_osalPendLock(cbSem[0]，timeout)需要1才能释放。

我已尝试将其减少到Task_Sleep (10)，它工作正常，并减少了释放锁所需的时间。 您可以根据您的用例进一步减少这种情况。

此致，
第  

您好，Parth：

我尝试了你指定的内容。

在构建默认应用程序中，我在DMA回调模式下使用了SPI。

我使用以下命令生成-->

make -s -j MCSPI_Master_TestApp Board=j721e_EVM SOC=j721e core=mcu1_0 build_os_type=tirtos build_profile=release DMA=enable

make -s -j MCSPI_Slave_TestApp Board=j721e_EVM SOC=j721e core=mpu1_0 build_os_type=tirtos build_profile=release DMA=enable

之后使用此命令生成组合图像-->

/MulticoreImageGen LE 55 app 0 MCSPI_Slave_DMA_j721e_EVM_mpu1_0TestApp_release.rprc 4 MCSPI_Master_DMA_j721e_EVM_mcu1_0TestApp_release.rprc

我在   main_mcspi_slaver_mode.c.的masterTaskFxn()中将Task_sleep(1000)更改为Task_sleep(10)

当我运行代码时，我发现使用 Task_Sleep (10)时，默认应用程序花费了50毫秒，而当我将其改回Task_Sleep (1000)时，花费了1040毫秒。

对于  仅发送-->的默认应用程序，使用Task_sleep(10)可获得50毫秒

unsigned char masterTxBuffer[128]="通过：来自主SPI的TxD通过：来自主SPI的TxD通过：来自主SPI的TxD ";
unsigned char slaveTxBuffer[128]="通过：从从SPI通过的TxD通过：从从SPI通过的TxD：从从从SPI通过的TxD ";

请给出您在尝试将Task_Sleep(1000)切换为Task_Sleep(10)时获得的读数。

我仍然认为，对于使用SPI DMA模式运行的默认应用程序来说，这50毫秒的时间太长了。

我也在共享该文件，以便您了解为清晰起见所做的更改。

e2e.ti.com/.../5850.main_5F00_mcspi_5F00_slave_5F00_mode.c

请查看。

谢谢，此致，

Tanvi

您好，Tanvi，

您是否尝试进一步降低该值？ 如果不是，可以尝试5次？

当1040当我402.8924万我运行402.8924万运行代码时，我得到默认应用程序使用 Task_sleep_I (10秒)返回到Task_sleep_1000 (引用)的时间。

这50毫秒是用于完成事务还是仅用于 SPI_osalPendLock(cbSem[0]，timeout)!= SemaphoreP_OK?

我402.8924万我仍然402.8924万仍然认为这50毫秒对于使用SPI DMA模式运行的默认应用程序来说太长了[/SPI]。

另外，您预计要达到多少时间？

此致，
第

[/quote]

您好，Parth：

您402.982万您是否402.982万是否尝试进一步降低该值？ 如果不是，请尝试5？[/QUOT]

是的，我尝试使用Task_Sleep (5)，但我的应用程序被卡住Task_Sleep (5)无法解决问题。

此402.982万此50402.982万50毫秒是用于完成事务还是仅用于 spi_osalPendSem[f_timeout]？

是的，这一次用于完成事务，而不仅仅是 用于SPI_osalPendLock(cbSem[0]，timeout)!= SemaphoreP_OK。

另外402.982万另外，402.982万，您希望达到多少时间？

[/quote]

[/quote][/quote]

您好，Tanvi，

 SPI_TEST_xfer_error中有一个Task_Sleep API用于同步，您是否可以尝试减少该问题，以及查看是否有帮助？

此致，
第

您好，Parth：

尝试了你指定的内容，但对我没有帮助。

请为此提出其他建议。

另外402.982万另外，402.982万，您希望达到多少时间？

我想在大约30毫秒内发送2 KB。

谢谢，此致，

Tanvi

TANVI，

OSAL_DELAY (1000)；//主(减少到20ms)

OSAL_DELAY (500)；//从(减少至10ms)

[/引述]

是50毫秒时间的数值减少还是实际值减少？

此致，
第

您好，Parth：

根据文件main_mcspi_slaver_mode.c，我在函数 SPI_test_singal_channel() 中与您共享的文件OSAL_Delay有10和20个传递到该文件。

您也可以在我与您共享的文件中检查它。

谢谢，此致，

Tanvi

您好，Tanvi，

我402.8924万我还402.8924万还将共享该文件，以便您了解为清晰起见所做的更改。

我检查了您共享的代码。 计算的50毫秒时间用于完整执行 SPI_TEST_Mst_SLV_xfer API，该API除了传输数据外，还包括一些数据验证和日志打印。 我已确认日志打印所花费的时间比实际传输所花费的时间要长得多。 在注释掉  SPI_TEST_Mst_SLV_xfer中的所有SPI_LOG调用后，我得到了默认情况下大约9毫秒的读数，其中大部分是由于OSAL_Pendlock，这是一次性同步要求，在您的实际使用情况中可能不需要。

您是否还可以注释掉您端的所有SPI_LOG调用并查看是否获得所需结果？

此致，
第  

您好，Parth：

对所有日志进行注释后，上述数据的传输速率相同，即大约10毫秒
我将检查注释 OSAL_Pendlock，并更新读数。

谢谢，此致，
Tanvi

您好，Tanvi，  

在406.015万在评论406.015万评论所有日志后，上述数据的传输速率相同，即大约10ms (报价)

此读数是否位于所需的范围内？

我406.015万我将406.015万将检查注释 OSAL_Pendlock并更新读数。[/quote-use.]

当然，请检查并告知我们

此致，
第

您好，Parth：

当然406.0482万当然，406.0482万，请查看并告知我们

我通过评论来检查

           IF (SPI_osalPendLock(cbSem[0]，timeout)!= SemaphoreP_OK)

但现在比没有评论的时候多花了3毫秒。

请建议其他方法。

此致，

Tanvi