This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3359: EtherCAT Slave on Linux-RT

Part Number: AM3359

I am trying to implement EtherCAT Slave on AM3359 Sitara processor using TMDSICEV2 as the reference design and Linux-RT as the OS running on the main core.

I see from Ti literature that all implementations of EtherCAT slave are only provided are for Ti RTOS running on the host, and not for Linux-RT running on the ARM_A8 core CPU, however there are indications in some literature that Linux user space UIO driver can be used to implement this solution. Of the course, the solution also relies on Beckhoff's SSC which must be downloaded from ETG Technology Group website. 

I have downloaded and installed PRU-ICSS-EtherCAT_Slave_01.00.07.02 on my PC.

I have noted the Ti binaries in the directory PRU-ICSS-EtherCAT_Slave_01.00.07.02\protocols\ethercat_slave\firmware\v1.0. These binaries and header files appear to be the black box binaries that are supposed to fulfill the IEEE 802.1 functionality. Are these the same binaries that Ti documentation in other places says they are black box binaries that will take care of the MAC layer in implementation of Industrial Communication System? 

However, if this is the case, it is still not clear how to install these on the PRUs during run time under a core running Linux-RT. If they were .elf files, one could use RemoteProc driver to move them to PRUs during run time and use RemoteMsg driver to communicate with them. Alternatively, perhaps it is intended that an image must be created so that the binaries can be loaded at boot time. If so, how does this process work with the particular case of PRU firmware? I find it is not clear how the latter process would work either, i.e in building a new .dtb file, how would I arrange these binaries to be installed correctly in the PRU units? I know for example that PRUs also require a resource file. 

Another option might be to use the Double EMAC plus switch option that has also been indicated in the documentation for RTOS + PRU, but again there are some indications of changes to be made to provide cut-through capability between the two Ethernet ports, but I have not seen how the problem if single MAC address will be resolved. 

Is there some concise and to the point documentation that would outline how I could go about getting the Ti provided "black box" binaries with suitable wrappers and drivers to implement the Linux UIO driver, Hardware Abstraction Layer for the processor that I have?

I intend to use the "UIO" driver to communicate between the application layer and PRUs. 

  • One Correction; RemoteMSG would not be used to communicate with the PRUs for an EtherCAT slave solution. UIO would be used. 

  • Hi,

    TI supports EtherCAT Slave only under TI-RTOS. We do not support any other implementations, sorry.

  • Hi Biser,

    Thanks. I already realize that Ti doesn't support implementations under Linux for EtherCAT slave. But If I have the binaries that load to PRU for providing the MAC layer and the corresponding headers, I can attempt to implement it myself. 


    So,

    1) if you can confirm that the binaries and header files found in PRU-ICSS-EtherCAT_Slave_01.00.07.02\protocols\ethercat_slave\firmware\v1.0 are the actual implementation of the MAC layer of the OSI model, that will already be a big help.

    2) If you have some tips that tells me how to load the binaries to PRUs within the Linux environment and independent of Ti RTOS, that will also be very helpful.

    Best Regards

    Farouk

  • Farouk,

    1) The white paper describes the firmware in high level -  and the firmware API may help better understand the internal - 

    2) There is no resource table built in the EtherCAT PRU firmware, so remoteProc/rpmsg method is not applicable. You may try to direct write the PRU firmware to its physical memory address as shown here - 

    Good luck and please let us know if you have any questions and progress.We are interested to see EtherCAT running with RT-Linux as well.

    Regards,

    Garrett