TCP need acknowledge but for periodic data this may be skipped. For periodic data I use to add a timeout at receiver instead of acknowledge.
> Hi Rafael, hi everyone! > > On 09.06.2015 03:23, Rafael wrote: >> While waiting for experts to respond I did some research on this >> interesting topics ... >> >> ... >> >> Nothing wrong with being proprietary if nothing else out there suits >> your needs. However, when it comes to communications between logical >> devices you have to pay the price. Either you need to increase >> complexity for more reliable connections or use simpler protocols for >> lower HW costs. >> >> Ethernet interface chips are low cost these days, many hobby SBCs come >> with it. Benefits in using them is in their power to handle the TCP/IP >> connection without more than dumping bytes in and out of it's registers >> something most microcontrollers can easily do these days. >> > > This complexity vs. reliability stuff may be a bit misleading when it > comes to hard-realtime systems. TCP is obviously a very reliable > protocol if it is sufficient if the data "just" arrives sometimes. But > especially for a control loop, waiting for milliseconds just because a > frame has been lost would most likely cause much more harm than to just > forget about it. But since I only need to link boards together which are > no more than, say, at most 5m apart (most likely they will be directly > adjacent, maybe 20cm of cable inbetween), any sensibly designed hardware > interface is unlikely to cause any significant loss of data at all. BER > maybe 10^(-12) or even much lower. > > Should there be considerable data corruption for some reason, then a > better approach for a fast hard-realtime system would be to use some > forward error correction (Hamming, Reed-Solomon, Convolution, whatever), > because requesting a corrupted frame again will always fail for cycle > times below 10ms or something like that. > >>> ... >>> >>> Rough requirements would be: >>> - Usable for daisy-chaining (no common bus) >> >> Wouldn't failure in any single link bring everything down? Fibre channel >> Arbitrated loop (FC-AL) and Tokenring work fall in that category. Each >> host has to pass the message along the line so there is a delay between >> the first and last host. > > Sure, one broken link will bring the interface down (or at least part of > it, the loop could be closed by the device just before the point of > failure). But: The interface will be used to link a master to some > motion and I/O controllers. If one of these devices or a link fails, the > machine has to be shut down anyway, as there would be no point to run it > with only half of the axes functional. > > Concerning the transmission delays: Since all those devices have the > interface right in an FPGA, the delay imposed by each slave can be very > short, even below the time for a single bit. > >> >>> - Data rate somewhere in the range 1Mbps .. 10Mbps >>> - Serial with exactly one RX and one TX pair in each link >> >> What's the max distance between the hosts? What are electrical >> characteristics for connections between the hosts? There are other >> considerations that need to be looked at: how many units are connected >> in the chain? How do you implement the communication part? >> Microprocessor? ASIC? Do you need isolation between them? > > See above: Distances are short, 5m are already a rather high guess. A > simple differential interface will do, all devices can share a common > ground, but at least some noise immunity should be provided (hence > differential signaling). A chain will consist of sometimes only two and > sometimes up to, say, ten devices. The interface is implemented in an > FPGA. > >> >> CAT-6 cabling would likely fit the job as far as physical connections >> and relative distance go. Low cost, easy to connect to hubs or switches. >> >> Advantage of ethernet is in possibility to wrap any protocol into TCP/IP >> and route it elsewhere. Not deterministic of course but possibly good >> enough for remote troubleshooting or monitoring. >> >> On the other hand, nobody prevents you to write your own version of >> network protocol. UDP came to mind first but because it's not reliable I >> did additional research and found Reliable User Datagram Protocol >> https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol >> >> It's not a formal standard or widely used but the description is >> available https://tools.ietf.org/html/draft-ietf-sigtran-reliable-udp-00 >> It seems very simple to me so it would not be too hard to write a driver >> I think. > > I already have a system running which uses a UDP connection between > LinuxCNC and a controller. This works quite well. But this is the only > real Ethernet connection in this system, it is simply overkill for the > connections between every two boards. > >> >>> - Suitable for deterministic cyclic transfers with some tens of bytes >>> each >> >> Not sure how you can do that without a dedicated clock line. > > I'm not talking about determinism in the sub-nanosecond range and > everything above is not that difficult to realize with an almost direct > connection between multiple FPGAs. If I transmit 10 Bytes at 1Mbps, this > will always take exactly 80us on the wire (plus-minus some jitter, yes, > yes). > > > Let me just summarize all this a bit: > > - There are lots of more or less standardized protocols based on > Ethernet. Using such an interface is a good choice for many reasons, but > I still view it as being overkill for my application. And there is > simply no PHY present on the existing boards and on the one I'm > designing right now there is no space left for one or two PHYs and the > Ethernet jack(s). > > - Non-Ethernet protocols probably suitable are CAN(open), probably > Interbus, probably Mesa Smart-Serial. CANopen seems to be targeted for > microcontroller applications (due to the management overhead) and uses a > bus structure; Interbus seems not be used anymore; Smart-Serial is out > of my knowledge, at least at the moment. > > > Maybe that's not exactly what I hoped to learn, but at least it is an > interesting discussion which also shows that Ethernet really is a good > choice for many applications. > > Thanks everyone for your comments! > > Regards, > Philipp > > ------------------------------------------------------------------------------ > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
