This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
你好。
我们使用 IPC 在 CPU1和 CM 之间实现了实时通信通道、然后 CM 将通过以太网或 UART 将该数据输出到外部世界。 程序正在闪存中工作。
我们正在测量 IPC 的性能、我们发现在两个内核之间共享数据所需的时间比预期的要长。
具体而言、在 CPU1中、要将数据复制到 MSGRAM_CPU_TO_CM 区域中的缓冲区中、发送1000字节大约需要120us。 (只需一份简单的副本)。 然后、CM 花费70us 复制同一个数组并确认 IPC
我们将数组声明为:
#pragma DATA_SECTION(readData, "MSGRAM_CPU_TO_CM") uint16_t readData[Tam_msg_buff_eth]; #pragma DATA_SECTION(BUFFER_ETHERNET, "BUFFER_COM") BUFFER_UDP BUFFER_ETHERNET; ........................................... ....//this takes 90us for (i_trama = 0; i_trama < BUFFER->long_msg[cont_trx]; i_trama++) { readData[i_trama] = BUFFER->xmit_msg[cont_trx][i_trama]; } .....//this takes 70us IPC_sendCommand(IPC_CPU1_L_CM_R, IPC_FLAG0, IPC_ADDR_CORRECTION_ENABLE, Code, (uint32_t) readData, BUFFER->long_msg[cont_trx]); IPC_waitForAck(IPC_CPU1_L_CM_R, IPC_FLAG0);
在 CM 上:
if (command == IPC_CMD_READ_MEM)) { status = true; msg_rx_CPU1 = true; ..............// this takes 70us for (i = 0; i < data_g; i++) { buf_tx[i] = (uint8_t) (*((uint16_t*) addr + i)); } } IPC_sendResponse(IPC_CM_L_CPU1_R, TEST_PASS); IPC_ackFlagRtoL(IPC_CM_L_CPU1_R, IPC_FLAG0);
对于阵列、在 CPU1上:
BUFFER_COM : > RAMLS6 MSGRAM_CPU_TO_CM : > CPUTOCMRAM, type=NOINIT CPUTOCMRAM : origin = 0x039000, length = 0x000800 RAMLS6 : origin = 0x00B000, length = 0x001000
我们如何提高性能?
与在程序的其他 RAM 存储器区域中工作相比、它似乎太低
我还在检查内存、对于这些内存缓冲区、一切似乎都是正确的。
我还附加了映射文件
e2e.ti.com/.../Example_5F00_test.txt
PS:我们 发现的另一个奇怪行为是、如果我们将 memcpy_fast 与 CPU1到 CM 缓冲区一起使用、则不会复制数据:
// This works --------------------------------- for (i_trama_cm = 0; i_trama_cm < BUFFER->long_msg[cont_trx_cm]; i_trama_cm++) { readData[i_trama_cm] = BUFFER->xmit_msg[cont_trx_cm][i_trama_cm]; } // This does NOT work --------------------------------- memcpy_fast(readData, BUFFER->xmit_msg[cont_trx_cm], BUFFER->long_msg[cont_trx_cm]);
朴世利
您能否调整 IPC C2000Ware 示例并向我们发送压缩项目、以便在 launchpad (或)控制卡设置中重新创建问题?
此致、
曼诺伊
朴世利
您能否调整 IPC C2000Ware 示例并向我们发送压缩项目、以便在 launchpad (或)控制卡设置中重新创建问题?
此外、请说明您如何计算所需时间?
此致、
曼诺伊
您能否分析 IPC C2000Ware 示例(按原样)并测量使用1000k 元素和闪存的时间? 我无法在文档中找到传输 IPC 数据所需的时间。
谢谢你。
切换 GPIOpin 和示波器的测量时间。 我还使用调试器测量时钟周期、它们匹配。
您以何种 SYSCLK 频率运行?
CPU1上为200MHz、CON CM 为125MHz
我将在芯片上对此进行测试、并在接下来的2个工作日内与您联系。
此致、
曼诺伊
谢谢你。
您在这项研究中是否取得了任何进展?
正如您所看到的、我确实看到了90us 复制1000字节的数据。
三、会议的报告
//这需要90us
对于(I_trama = 0;I_trama < buffer->long_msg[CONT_TRx];I_trama++)
{
ReadData[i_trama]= buffer->xmit_msg[CONT_TRx][i_trama];
}
但是、当我针对速度使用代码优化时、我能够以~10us 的单位复制1000个字节。 请尝试并告诉我。
此致、
曼诺伊
谢谢你 Manoj。
我在两个内核中都启用了所有优化后发现90us。 我看到您正在从 RAM 运行。 您能像我们说的那样从闪存中尝试吗?
谢谢你
我将通过从闪存运行来检查上述代码。
但是、您是否可以更改闪存等待状态? 当 SYSCLK = 200MHz 时、您需要使闪存等待状态为3。
此致、
曼诺伊
我刚刚检查了通过在启用优化的情况下从闪存运行来复制1000个字节。 我确实看到了与从 RAM 运行时相同的性能改进。
我们如何将闪存等待状态更改为3?
如您所见、我们的定义正确:
我一直在使用 driverlib IPC 示例进行测试、您似乎正在使用头文件方法。 我建议您改用 driverlib 方法、因为大多数 driverlib 函数都是由 TI 构建的、这样可以消除较小的固件设置问题。 此外、它还具有 SysConfig 支持、可增强用户体验、允许用户使用 GUI 设置初始化外设。
DriverLib 示例路径:-
\driverlib\f2838x\examples\C28x_cm\IPC\
谢谢你 Manoj。
为什么您说我们使用头文件方法?
BR
根据您在帖子中附加的快照、我很清楚您使用的是头文件方法。
谢谢你 Manoj。
我不明白什么是头文件方法而不是 driverlib 方法?
您能稍微解释一下吗?
快照在哪里清晰?
在此快照中、您将使用位字段/头文件方法评估所有闪存寄存器。 在 driverlib 中、我们使用 HWREG 来读取/写入 MMR 寄存器。 所有新的 C2000Ware 示例和 SysConfig 都基于 driverlib 方法。 这就是我建议考虑使用 driverlib 的原因。
你好。
我们的项目从以前的版本移植、因此它包含以下文件:
#include "f2838x_sysctrl.h"
我们应如何将其移植到新方法?
是否有应用手册?
此处提供了 Driverlib 方法
\driverlib\f2838x\examples\C28x_cm\IPC\