Emanuele Clerici wrote: > Jan Kiszka wrote: >> Emanuele Clerici wrote: >> >>> Jan Kiszka wrote: >>> >>>> Emanuele Clerici wrote: >>>> >>>> >>>>> Jan Kiszka wrote: >>>>> >>>>>> Emanuele Clerici wrote: >>>>>> >>>>>> >>>>>>> It's possible to send a data packet with an RTnet socket to a linux >>>>>>> socket. >>>>>>> I have tried it but it seem doesn't work. >>>>>>> >>>>>> Over a real network or locally (as interprocess communication means)? >>>>>> The former is possible of course (via UDP/IP or your own Ethernet >>>>>> protocol). The latter is not because the Linux networking stack and >>>>>> RTnet are strictly separated (for good reasons). The question is what >>>>>> kind of communication you want to realise this way. >>>>>> >>>>>> Jan >>>>>> >>>>>> >>>>> over a real network. >>>>> I try to explain: >>>>> I have 2 nodes 192.168.3.1 (A) and 192.168.3.2 (B) >>>>> I load rtnet and start it on A and B and rt_ping works fine >>>>> On A I send using rt_socket to B >>>>> On B i couldn't use it because i don't have hard_real_time context so >>>>> rt_dev_recvfrom doesn't work, so i try with linux socket but it seem >>>>> doesnt'work >>>>> >>>>> >>>> If RTnet is active on node B, Linux will not see the UDP packets >>>> arriving for that node. To forward data arriving via RTnet on B to the >>>> Linux domain, just create a borderline thread that is switching back >>>> and >>>> forth between RT and Linux mode (in user-space, of course). >>>> >>>> If you don't have any strict timing requirements for B at all, you may >>>> also drop RTnet here and communicate via standard Linux with node A. >>>> But >>>> be careful to block unwanted traffic from B to A to avoid >>>> indeterministic impact on A. Some firewall on B may serve as a filter >>>> here. >>>> >>>> Jan >>>> >>>> PS: Don't forget to reply-to-all... >>>> >>>> >>> with "borderline thread" I had to use a real time task and >>> rt_dev_recvfrom, it's ok? >>> >> >> Yep. >> >> >>> Ther's a way to avoid using them without >>> dropping down rtnet on node B? >>> >> >> What disadvantage do you fear when mapping one of your application's >> thread to RT? >> >> Jan >> >> > only i don't like to map all my application on node B as realtime > because i don't need it except for receiving data from node A, and I > don't like so much creating a little "child" application for receiving > because so my application complexity increases.
Well, my experience is that complexity in real-time systems doesn't come with such minor implementation details (given that the involved RT-components are needed on other nodes anyway), it comes with the system design itself. Just because some way appears to be easier from the programming POV doesn't mean the hidden complexity will not bite you elsewhere. My current feeling is that you either do not need RTnet at all (unless there will be also strict RT applications running on B as well) or you are about to mis-design node B. Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
