Kenneth Lerman wrote: > For me, the issue of RTnet is irrelevant. I would, instead, just want to use > the Linux driver. If we can get that to generate and receive ethernet frames > in real time, we are in business. > Well, that's the problem, it is NOT real time code. I don't know how far it is from being real time compatible, but I suspect there's a lot of things in there that might cause problems. > Then we could let the PC be a master and any peripherals be slaves. In the > case of the UPC board, there might be only one slave. The master would poll > each of the slaves as appropriate. As long as you could throttle traffic on that ethernet segment, so a network file transfer, for instance, couldn't bog down the ethernet, then that would work. But, I have no idea what would be involved in making the ethernet port driver and network stack RT compatible. Some time ago the RT stuff didn't do anything well except regularly-schenduled tasks, I think that is no longar a problem. But, the net driver would have to respond to interrupts whenever a packet came in.
Jon ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
