[etherlab-dev] Using EtherCAT Master with common network modules

[Florian Pose]

Hello,

On Thu, Apr 09, 2009 at 01:44:28AM -0700, Stefan Agner wrote:
> We wan't to use Etherlab's EtherCAT Master on a ARM-SoC Board. The
> ethernet device we use is mv643xx. We use EtherCAT to communicate with
> the outside world (from our machines perspecitve..). We use ethernet
> inside our machine as well (just raw ethernet frames). We consider
> folowing solutions:
> 1. Using two Ethernet devices

do you mean to physical Ethernet devices (two interfaces) or two
different device types with different drivers?

> Simplest solution, one for our Ethernet protocol, the other for
> ethercat. Probarly best realtime performance. But its more expensive,
> and one of the network device would have to communicate over an PC/104
> Bus, which is relativly slow... therefor probartly not that good
> realtime performance...
> 2. Using one Ethernet device
> It's the cheaper solution, but need some software changes: Our goal
> was to use standard ethernet drivers when we implemented our
> application for our ethernet protocol. So it runs on top of the linux
> network stack.
> So then, two possible solution solutions appear:
> 2.1. Change our application to use etherlabs ethercat master ethernet
> device driver (*omg* sounds crazy :-))

If the two devices are run by the same driver, the one that is not used
for EtherCAT is not affected by the EtherCAT master.

> Advandage: No need to change the ethercat master
> Disadvantage: Lost platform independency for our application. Code
> changes needed in ethercat master (synchronization or/and sorting out
> the unrelated packets)
> 2.2. Change ethercat master to be able to communicate over standard
> network driver High platform independence, but we lose some realtime
> performance... But anyway, this is the way we want to go... We have
> 5kHz frequences in our ethernet application, therefor 1kHz for the
> ethercat master should be realisitc (which is our goal).
> We also see two possible solution how to made this possible:
> 2.2.1. Make a software ethernet device (which provides a virtual
> device, it would be named something like ec_stdstack)
> This way no changes to the ethercat master would be necessary
> 2.2.2. Change ethercat master that he use standard network stack
> (register a packet_type struct with dev_add_pack, send packets over
> dev_queue_xmit)
> I read the chapter 4 in the ethercat master documentation, so i know
> why the solution which is implemented now was the prefered one. We
> don't use RTAI, we use preempt rt, therefore the interrupt problem is
> solved. My conclusion is, that the realtime behaviour would by the
> only problem...
> Now my questions:
> - Gerneral, do you agree with my conclusion? Would you choose the same
> approach? If not, why?

If you're knowing what you're doing, it is a good idea to have the
possibility to use the standard network stack via some kind of "generic
Ethernet device".

> - The examples workes with timers, which are based on jiffies. This
> leads to a frequence of 250 Hz (default). Are there any applications
> which use a higher frequency? Does this application getting to the
> limits of the current approach?

You can use high resolution timers or RTAI to get higher frequencies.

> - Is this correct: The ethercat master sends packages itself if no
> application is attached. As soon as an application attaches, the
> application triggers the packages. So the frequncy of packets is
> application depended, right?

Yes. After the application calls ecrt_master_activate(), it it
responsible for sending the frames.

> - We use High resolution timers to trigger our ethernet frames in our
> protocol. Are there any high resultion applications implemented? I
> tried to use hrtimers, but it failed, because hrtimers return in the
> interrupt context... Im going to have a closer look at that anyway...
> just wanted to ask if something is running this way atm...

No that I know, I don't know any reasons, why this should not be
possible.

-- 
Best regards,
Florian Pose

http://etherlab.org