Hello,
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
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 :-))
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?
- 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?
- 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?
- 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...
Of course, all our work is comming back to you, as its requested by gpl. We are
nice guys :-)
Thanks for any help
Bye
Stefan
_______________________________________________
etherlab-dev mailing list
[email protected]
http://lists.etherlab.org/mailman/listinfo/etherlab-dev
