EtherCAT on Beaglebone (with mods)?

Mat,

It is not clear what is the issue that you are facing. The currently available EtherCAT solution on ICE board is functional and is being used with dual MII ports in multiple projects with no issues.

It is correct that redundant links are not supported at the moment but that is necessary only when you actually require redundancy support on the EtherCAT network and a directional switch is to be done in case of media failure. This feature will be supported later this year.

The two MII ports that are used on ICE are from the PRUs and the MII port used on Beagle Bone is from the gigabit Ethernet switch. These are distinct MII interfaces and the ones on Beagle Bone (using gigabit switch) are not meant for EtherCAT slave. It is the PRU MII ports that are for EtherCAT implementation.

Thanks,

Maneesh

Thanks Maneesh, that does add a bit more information.

My issue is precisely redundancy! At the moment we are prototyping EtherCAT (and the AM3359) for potential adoptation into future products. However, in order to perform a proper assessment we need that redundant link operational so I can convince my masters that EtherCAT is truely fail-safe.

The beaglebone option I was talking about is in reference to using USB/GPMC/MMC expansion capabilities to attach another PHY or two. In which case the MII won't be used. Very early thoughts at the moment - I'd need to find a suitable PHY chipset (if one exists) which could cope with doing this. The question then exists whether the PRU's could address this type of interface.

Mat

Mat,

obviously you are free to look into this and try it but there is not a lot of hope you would end up with a good EtherCAT slave solution. EtherCAT really requires fast forward and processing of packets at the same time (talking sub 1us here...). That is why we use PRUs to implement the protocol. Otherwise we could just use the standard switch on our devices. Especially if you go via USB you add yet another major sw layer causing severe delays. In addition we can not open EtherCAT PRU code for you so that you are able to do any modifications. And a development from scratch would be tedious for sure.

As already discussed we are currently respinning the device to be able to implement redundancy mode and I assume if you start hardware design now we will have the new PG once you are ready to go to full production. If you need a detailed schedule please contact your sales contact or distributor for TI.Obviously you have to trust the TI roadmap here or wait a few month until we can demo the feature on new samples.

Regards.

Thanks for the info Frank,

I agree that any solution like this would be fundementally compromised. The reason I'm clutching at straws is because we are still trying to profile and validate EtherCAT for use in our applications. The plan was to use the ICE boards to perform this validation, including redundancy, before making the final assessment to adopt both EC and the AM3359 processor. What we're talking about here is to get full-functionality at the expense of performance, preferably retaining the TI processor rather than dropping to a completely different platform. This would at least give us a functional solution to complete our assessment, then drop back to the 'original' solution when it's available. Awful lot of work, I agree, but then so is moving to a different platform. I'm slightly up the creek without a paddle here, hence the sideways-thinking!

Mat

Mat,

With the way EtherCAT works, at least on the slave side, is that it is NOT possible to use an off-the-shelf 802.3 MAC and use it for EtherCAT slave. In EtherCAT, frame processing is done on-the-fly. That means, while a frame is still coming in on one receive port, it is being transmitted on the other side with approx. 700 ns delay in between. So, an ordinary Ethernet MAC just cannot do EtherCAT slave functions. That is the reason why EtherCAT slave solutions are available only on specialized ASICs or FPGAs.

Our recommendation would be that you please evaluate EtherCAT on TI platform but keep redundancy as a last thing in your checklist. Going through the evaluation of EtherCAT minus redundancy would be a good exercise to give you a feel of quality and performance of TI solution than going down that path of Beagle Bone. At least we will be able to answer all your questions on the ICE platform...

Thanks.

Maneesh