TMDS64EVM: How to send data from Linux as an EtherCAT subdevice

Hello Olaf,

I will be commenting from the perspective of IPC between Linux and an MCU+ core. Please note that the Linux mailbox driver is a low-level driver only (i.e., it does not interact with Linux userspace). So you CANNOT use the IPC_Notify driver to communicate with Linux userspace using TI-provided code.

The first example I would look at for transmitting non-time critical data from Linux to R5F would be RPMsg (if there is TRUELY no timing requirements, and you are willing to pass data in 496 byte chunks). We also have the RPMsg zerocopy example, where a shared memory region is used to pass the actual data, and RPMsg is used as the notification mechanism.

You can get started with RPMsg information in the AM64x academy's Multicore module:
https://dev.ti.com/tirex/explore/node?node=A__ASn.0Gvx.CK7j7a0EWKc.w__AM64-ACADEMY__WI1KRXP__LATEST

If you want to get an idea of what kinds of round-trip latency performance you can expect with RPMsg, take a look at my response here from Sept 26:
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1410313/am6442-communication-latency-issues-between-a53-and-r5-in-a-linux-rt-system/5434861#5434861

Regards,

Nick

Hi guys,

thanks for your hints on implementing an IPC mechanism. I wonder if this common use case is not used by other customers at all? What would be the benefit of having A53 cores if you want to implement an EtherCAT slave (including the application) that solely runs on the R5s? For this use case I would select a different SoC...

Do you have any experience in running the EtherCAT stack on the A53? The SOES project seems to have a proof-of-concept implementation using the PRU: https://github.com/OpenEtherCATsociety/SOES/tree/master/soes/hal/tiesc (even though loading of the PRU is not documented).

Best regards,

Olaf

Hi Olaf,

with my reply I didn't want to say that a implementation of the EtherCAT stack isn't possible on the A53, we actually implemented it on the AM335x in the past. We've also thought about providing an example application for that, but for now we don't have a time plan for that.

Our insights were that cycle-times sub 100us were hard to manage for the Linux system, and implementing other applications like e.g. a web-server must be done carefully to not disturb the real-time characteristics. Therefore, it makes sense for us to run the real-time related parts on the R5 core and "less important" parts on the A53.

Best regards

Andreas