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 _______________________________________________ etherlab-dev mailing list [email protected] http://lists.etherlab.org/mailman/listinfo/etherlab-dev
