AM6442: PRU usage for EtherCAT master

Hello, 

There is no specific Ethernet hardware requirement to run EtherCAT Master as there is for EtherCAT slave. This is the reason PRU must be used for EtherCAT slave but CPSW or PRU can be used for EtherCAT Master.

EtherCAT Master implementation is typically done so through open source or commercial EtherCAT Master stacks. You can find 3rd Party stacks that have been tested in the past on TI hardware here:  [FAQ] How to Setup an EtherCAT Network using TI Processors 

For some of the EtherCAT Master stacks we tested, there are some demos videos linked in the FAQ.

May I ask approximately how many EtherCAT slave/subdevices are planning to control with your EtherCAT Master setup? Will these subdevices be running synchronized motor control or digital I/O? What is the target cycle time and jitter your end application needs to meet?

Please note that depending on the performance requirements of your end application (e.g. high speed synchronized motor control such as robotic arm/hand control vs conveyor belt vs sensor/actuator control), you have to carefully consider if you would like run EtherCAT master using the R-cores or A-cores on the AM6442. Ease of use of the EtherCAT Master stack should also be considered. Open source stacks are free and usually more lightweight (cost less processor load and interferes less with real-time performance) but require more experienced programmers to program PLC logic. Commercial stacks offer more libraries and features (require less PLC programming) but are heavier on process load and can be complex to tune for optimal real-time performance. These are all things you should carefully consider/evaluate when designing your system.

-Daolin

Hi Daolin,

Thanks for your fast answer. Below are my comments:

1. The EtherCAT subdevice is supposed to be motion control unit like servo module. Typically we expect more than 30 axis motion application under 1ms sync period. The average CPU load is expected under 50%.

2.  Is there performance difference between EtherCAT stack running on CPSW and PRU? We did some test based on CODESYS runtime test package running on Linux using AM6442 evm board. But the performance is not so good (10 axis submodule, CSV/CST application, 1ms sync cycle. The average cycle time is more than 250us). So I am considering if any improvement on PRU or other directions could be available and be tested. Besides, is any success story or reference design of EtherCAT master stack on R5F core which I could test?

BRs

Feng

Hello Feng, 

Feng Zhang said:

2.  Is there performance difference between EtherCAT stack running on CPSW and PRU?

Out of box, there might be some minor differences in send (TX) and receive (RX) time between CPSW vs PRU Ethernet which may contribute to differences in cycle time, where PRU might have lower TX/RX latency. But this out-of-box difference might not be significant enough to make a huge difference in measured cycle time. What we have noticed is that if the EtherCAT Master stack you use has support with an optimized Ethernet driver, the TX/RX latency can be significantly reduced, which can significantly reduce cycle time. For TI's CPSW and PRU Linux drivers, we currently have XDP and XDP zero copy support which if supported by the EtherCAT Master stack you are using, can significantly reduce cycle time.

Feng Zhang said:

We did some test based on CODESYS runtime test package running on Linux using AM6442 evm board. But the performance is not so good (10 axis submodule, CSV/CST application, 1ms sync cycle. The average cycle time is more than 250us).

Has there been any real-time tunings applied on your test with CODESYS runtime? Since CODESYS is a heavier weight stack, tuning your Linux system to be real-time optimized is usually a necessary step to get significant improvement in your performance. This can involve disabling irqbalance and assigning different Ethernet irqs to specific cpu cores, isolated cpu cores for real-time specific processes vs non-real time processes, implementing the step in 2.5.1. RT-linux 11.02.08.02 Performance Guide — Processor SDK AM64X Documentation to improve interrupt latencies - which can help with EtherCAT jitter, and more suggestions which can be found in https://www.linutronix.de/blog/A-Checklist-for-Real-Time-Applications-in-Linux. For CODESYS specific optimizations you can take a look at Performance Optimization (please note you should contact CODESYS for questions about CODESYS optimization)

Also note that AM6442 only has two A-cores for Linux, so one question I had was if there was any particular hard requirement on using AM6442 for your system?

Feng Zhang said:

The average cycle time is more than 250us). So I am considering if any improvement on PRU or other directions could be available and be tested. Besides, is any success story or reference design of EtherCAT master stack on R5F core which I could test?

We have found that there is significantly better performance on R5F cores using an EtherCAT Master stack from IBV. Please see icECAT EtherCAT Master Stack - Benchmark for a benchmark white paper on AM6442 on R5F core where with 23 subdevices, 100us cycle time is achieved with an optimized Ethernet driver (implemented for PRU-ICSSG Ethernet) which is already integrated into IBV's EtherCAT Master stack. IBV is currently a partner of TI and you can take a look at their page via https://www.ti.com/tool/IBV-3P-ICECAT 

-Daolin

Daolin Qiu said:

Also note that AM6442 only has two A-cores for Linux, so one question I had was if there was any particular hard requirement on using AM6442 for your system?

It is not particular requirement but to keep same platform with previous product (AM6422). 

Also as you mentioned that IBV has an optimized Ethernet driver for PRU, does TI also have similar driver or any plan for this? I see there are some examples for PRU working as subdevice but not so many for EtherCAT master. So I would like to know how PRU could improvement the performance of EtherCAT master design.

Feng Zhang said:

 does TI also have similar driver or any plan for this?

No, but if you like at this main different is the real time latency of Linux vs RTOS. For 1 ms cycle time you mentioned, running enet lld (RTOS driver) from R5F shall be sufficient to meet the desired performance.