Hi there,

Has anyone experimented with realtime Ethernet? It seems like a nice idea to use the mbed's Ethernet for realtime industrial control... The latest 787 and A380/A350 all use a realtime Ethernet for their avionics, so it's an area that interests me :)

http://en.wikipedia.org/wiki/AFDX

I did some testing, and found that if one device on the network was the master and all other devices were clients, and the clients could only speak when spoken to (I copied the USB structure), then I could eliminate the non deterministic nature of the collision detection/resolution process. Also I found that using the master/client architecture I could use UDP and perform my own light weight acknowledgement procedure (rather than using TCP, which requires every packet to be acknowledged)!

So if you need a high throughput, highly deterministic link, using Ethernet in this way seems to work really well! :)

Matt, It looks interesting you have done some works on PROFINET using mbed. Will you pl. post the hardware sch and associated mbed code along with some basic documentation. This will be very helpful. I am new to PROFINET and wants to build some prototype to learn using mbed.

Hi Matt, all,

Perhaps you could start a PROFINET/real-time Ethernet page in the cookbook to collect your findings and efforts?

We're going to be working on an official mbed networking stack as a priority this year, and one transport is obviously going to be Ethernet. Would be great to make sure our Ethernet driver and networking stack can be a basis for your investigations.

Simon

I have a near-real-time http/TCP product in pre-production phase now.

If you require fast response to TCP traffic, then you must avoid the NetServices stack for http (which only achieves about 4 to 8 small packets per second).

However, if you setup an Ethernet interface and use raw TCP commands from the lwIP API:

http://lwip.wikia.com/wiki/Raw/TCP

then you can get up to 100 packets/s of throughput. To get this kind of speed (8ms latency) I send the request for the NEXT packet (http GET) during the receive callback of the CURRENT packet.

This works reliably well. I conclude that the Ethernet driver is in pretty good shape, but the higher level http layer in Net Services is not yet optimised. This layer also has a number of compatibility issues with some servers.

Simon, I am pleased to hear that there's a plan for an uprated stack - I believe that this is very worthwhile.