Stephen Wille Padnos wrote: > > 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". > > Even then, if you don't send multiple requests to multiple devices, but contact each one single-file, you don't need any arbitration. Of course, you'd get better overall throughput by interleaving the commands to multiple slaves. >> > 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. > > My guess, to have fairly simple packets command reading or writing to about 15 registers on my PPMC boards, would be that an Arm7 ought to be able to do that in 10-15 us even with very inefficient code. Coding in C, one could use pointers and inline code to get better efficiency. Creating checksums, etc., for such small packets should be no big deal, but I believe the Arm ethernet port handles that. >> 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. :) > Oh, no, that won't do. Well, maybe it would, but you'd need to sit in a loop until the message comes back, quite ugly, and you need a timeout in case the reply never comes back. MUCH better to set an interrupt handler and give up the CPU until the response. One of the HUGE flaws in the PC architecture is the extreme shortage of interrupt addresses. We used to hook up insanely complex systems with PDP-11s with hundreds of different ISR addresses.
Jon ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
