TMS320F28P650DK: Ethernet over Ethercat

Hi Michael,

Using Ethercat in place of Ethernet is not a feasible solution. Fundamentally Ethernet is a decentralized architecture vs Ethernet is centralized architecture.

What is the use case or end equipment, can you explain better?

Hi Anand,

Thank you for the response.

My customer currently uses the TMS320F2838 in one of their power conditioners, but would like to update to a newer C2000.

The issue is that they utilize the TMS320F2838's ethernet functionality and require similar functionality in their new part. Therefore, we would like to explore all possibilities which consisted of ethernet over ethercat.

I recommended them to consider the AM26x as well, however given the investments already made in utilizing the TMS320F2838, they highly prefer the TMS320F28P650.

Given the information above, do you have any recommendations on how to best proceed?

Best regards,

Michael

Hi Michael,

EtherCAT cannot work as alternative for Ethernet.

Can they use EtherCAT instead? 

Hi Anand,

My understanding is that their current project is an update to a pre-existing power conditioner, which utilizes ethernet.

In order to keep changes as small as possible, they have identified ethernet as a key requirement at this point in time.

Do you have a recommended device, or any possible work arounds given this information?

Best regards,

Michael

EoE instead of a dedicated Ethernet MAC introduces several significant limitations:

​1. Bandwidth and Throughput Constraints

​EoE traffic is treated as acyclic data, meaning it is only transmitted during the idle time of the EtherCAT communication cycle, after the critical cyclic Process Data Objects (PDOs) have been handled. Because it is strictly background traffic, the effective throughput for EoE is only a small fraction of the 100 Mbps physical link, making it unsuitable for bandwidth-heavy applications like high-res video streaming or massive file transfers.

​2. High Latency and Jitter

​Standard Ethernet relies on the ability to transmit data whenever the medium is free (CSMA/CD) or through immediate switch forwarding. In EoE, the slave cannot initiate data transfer autonomously; it must wait for the EtherCAT Master to poll its mailbox. This master-driven polling introduces substantial latency and jitter to the tunneled IT traffic.

​3. Fragmentation and CPU Overhead

​A standard Ethernet frame has a Maximum Transmission Unit (MTU) of 1500 bytes. However, EtherCAT mailboxes are typically configured to be much smaller (often between 128 and 512 bytes) to optimize the real-time cycle. Consequently, standard Ethernet frames must be fragmented into smaller pieces by the sender and reassembled by the receiver. This fragmentation and reassembly process consumes additional CPU and memory resources on the slave microcontroller.

​4. Absolute Dependency on the EtherCAT Master

​A standard Ethernet MAC allows a device to communicate autonomously with any node on the network. With EoE, the device's "Ethernet" connection is entirely dependent on the EtherCAT Master. If the Master goes offline, halts the EtherCAT network, or simply does not support EoE routing (virtual switch capability), the slave loses all standard IP communication capabilities.

​5. No Real-Time Guarantees for IT Traffic

​While the EtherCAT protocol itself is deterministic and real-time, the Ethernet traffic tunneled inside the EoE mailboxes is strictly "best-effort." You cannot rely on EoE for secondary time-sensitive IT protocols (like standard NTP or PTP) because the timing of the mailbox extraction is unpredictable.