工具与软件:
尊敬的 TI 团队:
在 AM64x EtherCAT 子器件处理输入(子器件->主器件)数据三缓冲的方式方面、我们遇到了一个相当严重的问题。
我们首先在定制应用程序中遇到该问题、但也可以通过"Beckhoff"子器件示例重现该问题。
- 工业通信 SDK 09.02.00.08
- AM64x EVM 上的 EtherCAT_SLAVE_Beckhoff_SSC_DEMO (修订版 C、SR2.0硬件)
- 10ms EtherCAT 主器件周期
- 通过0x1c32.1/0x1c33.1将 EtherCAT 子器件配置为自由运行模式
当配置为自由运行模式时、PDO_InputMapping 从 MainLoop 调用、并且在我的测试期间每~10-16us 更新一次输入。
PDO_InputMapping 调用 HW_EscWriteIsr 将循环输入写入 ESC 存储器。 在 HW_EscWriteIsr 中调用 BSP_GET_PROCESSOR_DATA_ADDRESS 来获取"当前"三路缓冲区的实际偏移。
我希望更新在2 (还是3?)之间迭代 向三个缓冲区中写入、但使用我的日志记录(开销极低~、记录到 DDR 存储器中的环形缓冲区)、我可以看到、对一个地址连续写入~600次(在本例中为0x140e)、然后~600次写入下一个地址(0x1407)、然后~600次写入下一个地址(同样为0x140e)、依此类推。 缓冲区切换之间的时间几乎正好是10ms、即每次 EtherCAT 帧读取 SyncManager 时、PDI 将在下次调用 bsp_get_process_data_address 时获取不同的缓冲区。
附件是带有我们的日志记录的 CSV 文件。 子器件示例只修改为在 HW_EscWriteIsr 中包含我们的记录工具和日志输出:
void HW_EscWriteIsr(uint8_t *pData, uint16_t Address, uint16_t Len) { int16_t sm_index; uint16_t ActualAddr = bsp_get_process_data_address(pruIcss1Handle, Address, Len, &sm_index); LOGGERBUF_LOG3(main, 0x1, "HW_EscWriteIsr", Address, Len, ActualAddr);
在记录中、"R5F"和"tsdiff"通过 ts 周期计数器(800 MHz)测量。 上述记录仪中的参数("Address"、"Len"和"ActualAddr")以十六进制和十进制格式打印。 您可以看到、从开始 PDO_InputMapping 就一直在0x140e 处写入缓冲区、直到~600在该缓冲区切换到0x1400时更新。 这些~600次更新的持续时间也是~10ms。
这种三角缓冲行为是有问题的、因为如果子设备持续更新同一缓冲区、则子设备无法将最新的数据传送到网络。 这也是我们首先注意到这个问题的原因:
- 自由运行的子器件以 EtherCAT 周期~13倍的速度更新循环输入数据
- 每次更新都会在输入数据中存储一个递增计数器
- 每个 EtherCAT 周期通常会显示计数器递增13或14 (周期为异步)、但每隔一段时间(例如、3000000 ~80 of 3000000)、计数器就不会在两个 EtherCAT 周期之间递增、即我们收到相同的循环输入数据两次。
- 这意味着我们得到的输入数据更新不会稍微有点旧(计数器将是+11或+12而不是+13/+14进行输入数据更新)、但我们得到的输入数据是整个 EtherCAT 周期之前的数据(之前为13或14次循环输入数据更新)
我将 EtherCAT 子设备固件在09.02.00.08和09.02.00.15之间进行了比较、这些固件是相同的、因此我希望.15中不会针对此问题进行任何修复。 通信 SDK。
我们不知道这个问题是否也出现在旧版本中,我们只是刚刚注意到它。
在"正常"SM 同步操作期间、您不会直接注意到这个问题、因为在这种情况下、每次输入数据更新都会有一个帧。
此致、
Dominic
e2e.ti.com/.../ethercat_5F00_slave_5F00_sm3_5F00_address_5F00_beginning.zip