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
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------
_______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
