Jon Elson wrote: >Stephen Wille Padnos wrote: > > >>I don't know the specifics of how to deal with the incoming packets on >>the PC (or the specifics of how to send them, for that matter :) ), but >>I'm pretty sure data throughput won't be an issue. Latency is unlikely >>to be either, unless there's some very complex packet reception >>mechanism on the PC which can't be worked around. >> >> >> >That's one of the things that worries me, I have no idea how much >overhead there is in the net stack. >Also, rtnet imposes time slots for each node, and some kind of timer >that tells each node when its time slot happens. >The master node sends a sync packet every so often, and the slave nodes >keep time off that. I'm not sure rtnet was designed at all for the kind >of VERY tight coupling we are envisioning here. Of course, rtnet >exists, but you then have to make the embedded slave nodes have a >matching protocol scheme in their stack. > > I agree with Ken - you don't need RTNet unless you want to have multiple slave devices and all that stuff. It could still be useful since the master defines the timebase (at least in one mode, AFAIK), so the master could send one "sync" packet, then have all the slaves transmit status packets automatically, then the master can transmit a command packet at the end of the "frame".
>Really, for what I wanted to do with it, I don't WANT the message slot >scheduling, the HAL driver would be the master, and the slave would only >send (immediately) when commanded to. > For some value of "immediately". You'll need to check on how many bytes the uC will have to move around, how much math it will have to do, whether the integrated ethernet controller does checksums, etc. etc. There will be some latency - the fastest (cheap) chips only go to ~200 MHz, so you get 200 cycles per microsecond. Memory access instructions may take multiple cycles, so moving data around can be costly. It doesn't take much work to make a delay of a few microseconds before return packet transmission starts. > But, of course, it needs access >to the net hardware from the real time environment. > > Yep. The big thing to look at is how the PC ethernet "driver" gets notified of a received packet. If you have to poll the hardware directly, that may provide the best latency, though it's not so great for CPU usage. That may be the only way though - the ethernet hardware gets accessed by its HAL driver the same way as e.g. a parallel port or a PCI card - with direct access to its registers, and "manual" treatment of error conditions. Ick. :) - Steve ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
