5 Summary

The resulting benchmarks across AM62x, AM64x, AM69, and TDA4VM indicates that configuring a 1ms cycle time is achievable for the case of filtering out results from CODESYS startup or log-in. After some optimizations, higher end processors such as AM69 and TDA4VM can achieve down to 500µs cycle times whereas lower end processors such as AM62x and AM64x can achieve 1ms cycle times. Additionally, AM62x performed better than AM64x in terms of measuring a much lower maximum cycle time of 500µs compared to about 900µs. AM62x features four A53 cores running at a higher clock speed of 1.4GHz compared to AM64x at only two A53 cores running at 1GHz. The higher number of cores to redistribute “IEC tasks” that the CODESYS EtherCAT controller application uses and higher clock speed could have contributed the improvement in cycle time by about 400µs.

The expectation is to align the worst-case interrupt latency observed from cyclictest results with the cycle time observed from running CODESYS EtherCAT stack. The actual results show that CODESYS adds a significant amount of additional jitter. Further tunings such as changing clock frequency can improve cycle time performance; however, a better understanding of how CODESYS related threads impact scheduling and CPU load, helps in determining how to further optimize cycle time performance.

Note that the analysis provided in this application note are from the CODESYS EtherCAT controller stack running on Linux using a generic ethernet driver. Running an EtherCAT controller stack with a native driver can show even better performance. This is already shown by an RTOS-based EtherCAT controller stack with an optimized native driver developed by IBV (stack name is icECAT), reaching 100µs cycle time when running on a high-end MCU-based platform. With a more focused commercial stack such as IBV icECAT, better performance can also be achieved on a system running Linux, even with the standard ethernet driver (see also icECAT EtherCAT Master Stack Benchmark).