SK-AM62: Where is the ECAT master / slave Example of in the AM62 SDK?

Hello,

Thank you for your question.

I will forward your query to the ECAT experts.

Regards,

S.Anil.

Hello Rio,

the way I understand it, the AM62x is never going to support EtherCAT slave, since it's only got an PRU-SS, without the Ethernet connectivity that you need for an EtherCAT slave.

If you're looking for an EtherCAT master, every Linux based master should already support the AM62x, at least via "raw sockets".

Regards,

Dominic

Hi Dominic:

If so, what's the purpose of the PRU inside the AM62?

Why it exists there?

If this is truth as you said (No support for the ECAT), then, we shall remove the term (PRU) on the datasheet.

To prevent the customers continue asking us the AM62 ECAT slave.

please correct me if I'm wrong.

BR Rio

Hello Rio,

Rio Chan said:

If so, what's the purpose of the PRU inside the AM62?

Why it exists there?

this is something that should better be answered by your colleagues, e.g. some kind of product manager, but here's an excerpt from the AM62x datasheet:

Intended for driving GPIO for cycle accurate
protocols such as additional:
– General Purpose Input/Output (GPIO)
– UARTs
– I2C
– External ADC

There's also the PRU-ICSS features comparison (https://www.ti.com/lit/an/sprac90g/sprac90g.pdf) that explicitly states that

Industrial Communication Subsystem features including Ethernet (MII signals and MDIO signals are not pinned
out) are not supported.
Devices offering the PRUSS capability include AM62x

I'm pretty sure about all that, but of course I'm not TI, so your colleagues might know better. I was simply reading Ashwani's reply above, and found that misleading, so I chimed in.

Regards,

Dominic

Dominic Rath thanks for chiming in on this thread and some of the other threads -  you have been a rock solid  power user of our products and we really appreciate you helping provide creative solutions based on your experience. Rock on and thank you! 

Rio

Ashwani did mean ECAT primary and as noted ECAT secondary (if i can avoid the master/slave terms) is never going to be supported on AM62. 

The following application note is a good reference for differences in the PRU integration and capabilities

https://www.ti.com/lit/an/spracj8/spracj8.pdf

External ADC attach is already something we have working on AM64 

https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/08_02_00_31/exports/docs/api_guide_am64x/EXAMPLES_PRU_ADC_ADS85x8.html

It is in our back log to do some show and tell on AM62 too. 

In past customers have used PRU for several creative things  before it became known for industrial protocols in factory automation, motor drives and grid etc. 

Over time we hope that customers will be able to develop similar creative solutions on their own based on the foundation offering we provide 

Nick Saulnier has started to fold that in the SDK documentation 

https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/08_04_01_03/exports/docs/linux/Foundational_Components_PRU_Subsystem.html

Get creative with it :) 

Regards

Mukul 

Dominic Rath and Mukul Bhatnagar thanks for your responses! Everything that was said above is correct.

Let me add a bit more context. This is how I think about the cores that currently have broad market development support on AM62x & AM64x:

A53: General purpose Linux cores (technically FreeRTOS is an option on AM64x, but not supported by TI as per the "Attention" box at https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/08_04_00_17/exports/docs/api_guide_am64x/index.html)
R5: General purpose RTOS / NORTOS cores (only supported on AM64x at the time of this post)
M4: Specialized isolated usecases, or general purpose RTOS core that is better for limited applications (code that can fit within the local M4 SRAM)
PRU cores: bare metal cores specialized for moving data in and out of the processor, or around the processor.

On AM64x that includes Industrial communication interfaces like Ethernet, but on AM62x the PRUs can still implement additional standard interfaces already on the chip (e.g., UART/I2C/SPI), custom interfaces (legacy busses, I2S, etc), and even a bunch of stuff that you would normally need a custom ASIC to implement. PRU is very powerful for adding specialized features to customer designs. You just need to make sure the customer understands that there will be a bit of additional work for them to write and validate the PRU firmware, or they may want to enlist a third party for help with firmware development.

The AM62x datasheet "Device Comparison" and TRM "Module Integration > Processors > PRU" specifies that industrial communication is not supported on AM62x PRUSS. In our next revision of the AM62x Datasheet, we are clarifying the naming convention from PRU_ICSS to PRUSS to make it easier to see the differences.

Regards,

Nick