Good day.
Help me to find some information about RTmac adapting for my needs (start from NoMac) or give me any suggestion.
I have ethercat master ( software implementation for EtherCAT (fieldbus) ) which must work on PC with Linux/RTAI/RTNet. I want have vnic-mechanism (only) based on Nomac skeletone for receiving and transmiting no real-time trafic by using abilities which EtherCAT give me.
Ha, I always knew it: the day would come that someone does the obvious work implementing EtherCAT on top of RTnet. :)
You are welcome - even more if you are able to contribute the low-level work (kernel drivers, libraries) back to the RTnet community!
Example: I have pc with Linux/RTAI/RTNet and 1 network adapter which connected to Ethernet. All other ethernet nodes are EtherCAT slaves. One of them (slave) has extension - in/out with no realtime LAN. I want start no realtime task which use same ethernet adapter for connect to other LAN via slave extension. For it i must realize mac-discipline for send/receive no realtime data but without "tunneling" because else slave doesn't undestand me. Slave undestand EtherCAT packets only. For this goal we will use EtherCAT mechanism (i.e. mailbox). Thus in rtmac i will wrap no-realtime trafic and send them how EtherCAT packates.
Can I realize this in rtmac (nomac is base) and where can i find info for to understand structure of rtmac and its disciplines.
Documentation is few and scattered, we know. There are READMEs and specification in the documentation folder, and you may also analyse the use-cases of RTmac in combination with TDMA to get an impression. And, of course, there is always the code as reference. ;)
Basically, these are the tasks of RTmac (extracted from a paper draft currently waiting on review):
o Interception of the crucial packet output path and redirection to discipline-specific handlers. For transmitting packets, this is performed right before the packet is passed to the NIC driver. Furthermore, a handler to override the device MTU on a per-packet basis can be installed.
o Exchanging discipline-defined control or data messages in a RTmac frame aside any user protocols.
o Discipline management on a per-device basis. To every real-time NIC, an individual MAC discipline can be assigned when it was registered with the RTmac layer.
o Packet tunnelling service for time-uncritical data as generated or received by the non-real-time network stack. This service creates a virtual network device for every RTmac-managed real-time NIC. Tunnelled packets are encapsulated by the RTmac protocol frame to distinguish between otherwise identical real-time and non-real-time protocols like UDP.
RTmac was design with the idea that normal, arbitrary protocols (like UDP/IP) are to be transmitted over Ethernet or other media deterministically. The assumption is that, for guaranteeing real-time contraints on all involved nodes, a transmission control mechanisms needs to be installed.
When looking at EtherCAT (as fas as I can without the detailed specs at hand), this transmission control could be either void (like in NoMAC) or a periodic real-time task initiating the issue of the EtherCAT process image update frame(s). The application or an IO manager dealing with the process image update could just throw some EtherCAT frame down the RTnet socket API which would either be issued immediately or delayed until the next fixed cycle.
Regarding your tunnelling question: RTmac provides both the upper and the lower interface - but you don't have to use both. The upper, i.e. the creation of a linux network device per real-time NIC, is certainly useful, but you are right, the lower, i.e. the encapsulation of the tunnelled non-rt frame in a RTmac header, is not compatible with EtherCAT. Here you can just put you own EtherCAT header in front of the payload and issue the frame.
Reception is a bit more tricky as RTmac assumes that discipline-specific or tunnelled packets start with the RTmac header. However, even if the "usual" pattern for discipline development does not fit, you are free to register the EtherCAT frame type with the RTnet core and handle those frames in your own way, i.e. separate tunnelled frames and forward the payload to the VNIC device. If any interface for doing this is missing, let us know and we can discuss extensions - should be no big deal.
But the reception path of tunnelled EtherCAT frames arriving on the master just raises a question for me: Is there any flow control mechanisms so that non-rt frames do not overload the master with the full 100 MBit bandwith? Or do you have to select a hardware that is able to handle both these non-rt bursts and all potential real-time tasks (soft PLCs etc.) running in parallel? I think this question does not only applies on a future RTnet-based implementation. TwinCAT should work similar...
Jan
------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click _______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
