AM335X ,Switching Between Ethernet and EtherCAT on the same port

Dear Faraz,

theoretically yes, but in reality it is a bit more complex. There is no 'EtherCAT port' connected to PRUSS first of all. PRUSS has two dedicated MII ports which can interface to Ethernet Phys. However the standard or protocol that then runs via the two ports is defined by software (PRU firmware + some form of ARM side stack). So you can do EtherCAT, Ethernet or any other standard with the right software.

We already have an EA version of the EtherCAT SDK out. Some work is ongoing for normal Ethernet TCP/IP support. Please contact your local TI sales for details.

Regards.

Hello,

I ssume that a solution for the dual use Ethercat/Ethernet is still not available.

Unfortunately the Pinout for the ZCZ package is designed in a way that the Ethernet MII and the Ethercat MII and on the same group of pins, but they are not compatible regarding the assignment.

So if we don't want to use a hardware multiplexer, the special Ethernet software for the PRUSS would be needed.

Is it perhaps possible to use ONE of the pruss MII ports for a slave use with Ethercat and the other port connected as standard ethernet port via the ethernet switch port with the existing Ethercat SDK ?

Regards

Werner

Werner,

that is possible from pin-mux point of view I think. One example is the IDK board where we have the two PRU MIIs and a third MII connected to the switch. All three phys are TLK110s so 100Mbit is the max for all ports.

What is missing in the IA-SDK right now to also USE all of three ports is some software... We do run the EtherCAT slave on Sys/Bios 6 but there is no support for standard Ethernet for AM335x switch yet. Someone would need to port the driver and a TCP/IP stack to Sys/Bios 6 I think. There is an Ethernet example in Starterware 2.0.0.5 which supports the BeagleBone. It uses lwIP and some kind of driver but it would take some work to integrate that into IA-SDK. Long term we would like to have that option e.g. for debug purposes but so far it is not scheduled. Another option would be to use TI Network Development Kit (NDK) and get it ported/integrated with IA-SDK.

Regards.

thanks a lot for your answer.

We also had the idea of using a 3rd phy.

But regarding to the additional needed integrated resources we might run out of pins and pin combinations when using a third phy.

I know that when an Ethercat device is used is the final device only one RJ45 (and assumed phy) is used.

Is the current state of the stack able to handle such configuration ?

So we would be able to use both ethernet implementations.

Regards

Werner

Hi,

is there any source for the pruss code used for the ethercat firmware ?

Perhaps I may try to get some solution handled by programming an ethernet solution for the pruss unit.

But the sdk only contains the ethercat pruss firmware as h files with no source as it seems.

And I don't know whether the needed assembler is included in the sdk or CCS.

It would be fine to get this source as a demo and starting point.

Any ideas where to get it ?

Thank you very much in advance.

Werner

Werner,

I will summarize the answers here:

1) EtherCAT PRU firmware support for ONE port only:

Theoretically yes... we do a lot of testing with only one port where our slave is last in chain. This setup is automatically detected by the firmware and the internal data paths are configured automatically. However we always test this with TWO phys connected so far. I am not sure what happens if there is a phy missing. The firmware may run into some error state. I need to check internally if running the firmware with one phy only is a standard test case. If not we have to add it for the future I think.

2) EtherCAT firmware sources:

No, we will not release EtherCAT firmware sources. There are legal obligations that forbid that. We are working with 3Ps of course to help them use the PRUSS for other protocols. We do not see the need or advantage of someone doing a second version of EtherCAT slave firmware. There are enough other protocols people can work on...

3) PRU assembler:

PRU tools are not included in IA-SDK as there is no firmware source anyway. You can find the original PRU development package on the Wiki. This contains the old assembler for PRUs on AM18xx, OMAPL1xx and some DSPs. Now the code produced by that assembler will run on AM335x PRUs. We added only a few instructions for new features. It is planned to release PASM2 in a few months publicly. See some other threads on the forum for this (or request a date in a new thread).

We will also give out the new assembler under NDA I believe to 3Ps and customers with known projects. This should be part of a direct conversation involving the TI sales team.

Regards.

Werner,

I forgot an important point on 1)

For sure you will not gain a PRU while running EtherCAT slave with one port only! This means you can not use the second (unused) PRU MII for normal Ethernet.

That would require a new firmware as our current EtherCAT firmware architecture needs both PRUs.

So combining EtherCAT and Ethernet on AM335x will in any case require the use of one switch (RG)MII port. That means you still need a driver for Ethernet switch running on your choice of RTOS combined with the EtherCAT slave support on PRUSS.

Regards.

Hi Frank,

thank you for your information.

There is no problem for us using RGMII for the ethernet and MII for the Ethercat Phy. So if he software stack for Ethercat will allow this after testing this would be a good solution.

I didn't intend to write an ethercat low level driver, a normal ethernet one was taken into consideration , but seems not to be needed if the slave Ethercat works with one phy.

From a person I spoke some days before on an exhibition I was told that the Ethercat formware uses one PRU only. As far as I understood he implemented the solution for you. Or might be this was a second solution ?

I will try to contact him again.

What we would be interested in additionally is to use the PRU for CAN protocol tasks which are needed to be repeated in short intervalls to release the main CPU from this work.

This needs not to work with ethercat in parallel, so we have the PRUs available.

I already found the old pasm yesterday on the wiki, but the new one and additional infos if there are any for using the PRU with can and perhaps UART would be welcome.

Regards

Werner

Werner,

I do know the experts on this field in TI... don't think anyone of them talked to you :-). But be assured that we require both PRUs with current firmware. Maybe he confused this with one PRUSS.

For CAN I would always recommend the CAN controllers on the chip + standard driver. We did some tests with implementing CAN on PRU but the achieved data rates are usually not sufficient. Also you would need to get this sw solution verified. The CAN controller uses fully verified IP so that there are no conformance issues.

Do you think a 720MHz device wouldn't be capable of running your software?

Regards.

Hi Frank,

thanks for your information.

And for the information that CAN would not deliver a maximum performance and would work better wth the main CPU.

I don't spoke to anyone at TI, it was someone from ETG as I remember.

Of course we hope that the performance will be sufficient. We are not primary needing maximum performance in the average, but very low latencies.

There is an external interrupt every 20us which needs to be handled and calculate matrix floating point ops to write back data to the process in less than 15us after the interrupt is triggered.

Every interrupt must be handled and it is not allowed to miss it or extend the period.

We are currently using a competition ARM9 CPU with less clock/power but now a limit regarding handling time is reached.

And there are plans that need more CPU power inside this interval which are definitely not possible with the current solution.

So we now want to use a solution with some extra power especially regarding latency to be sure that the design may be used for a while and we don't need to redesign the hw in some month again.

And the idea of using the PRUSS for CAN came from the fact that this ports may also be used with many interrupts simultaneously to the need of the external interrupt, but always alternatively to Ethercat for example.

So I am currently responsible for the evaluation of the AM335x solution for my customer and will be responsible for most of the low level work (driver..) afterwards. 

Regarding the question with the single phy for ethercat there is a need to save pins, as I need to implement a fast synchronous GPMC <> FPGA interface which for performance reasons need to be 16 bit wide and should not be multiplexed if ever possible.

If I put this all together (Ethercat possibility, Ethernet possibility, dual can, at least four UARTS/RS485, MMC, SPI) there are not a lot different possibilities when looking at the Pinmux utility. So the extra Ethercat Phy with about 15 lines on the MII would steal ressources needed elsewhere.

I assume (but I don't know of course) that removing one phy should be no problem regarding rx or tx on the Ehercat, but may be a problem regarding the management (MDIO) interface when the second phy is not present.

Regards

Werner

Hello,

I've read the posts for Ethercat and Ethernet.

In a project, I need to manage both Ethernet standard for spare parts and Ethercat instead of Ethernet for new project. I would like to save pins and manage Ethernet standard on PRU. Is it not still available a FW library for it?

The only solution is to use PRU for Ethercat and MII for Ethernet with 3 different PHY or there are some news?

Thanks in advance.

Regards.