The Gigabit Ethernet technology seems pretty good as a command/control/data bus.
It can handle very fast speeds, bi-directional, between multiple nodes on the bus.
gigabit ethernet is not multidrop, it is point-to-point only.
That sounds like royal pain in arse for everyone involved honestly
gigabit ethernet is not multidrop, it is point-to-point only.That assumes you are using all the levels of 802.3 "Ethernet" protocol.
I am suggesting that you CAN implement multidrop and/or whatever else is needed by establishing new protocols for the upper layers.
Using a standard just to throw away most of it seems like royal pain in arse for everyone involved. You're basically throwing most of advantages of having ethernet while compensating for none of it disadvantages.
Also "multidrop" is function of layer 1, layers above it have nothing to do with it. So you can't just take ethernet chip and "implement multidrop"
100Mbit ethernet *can* actually do it (via passive hubs), but 1Gbit can't .
I considered mentioning this. I even keep a 10/100 ethernet hub for special applications where it will work better than a switch.
It has been a while since I looked at this and someone can correct me if I am wrong but 10Mbit and 100Mbit Ethernet on twisted pair use one pair for transmit and one for receive so the hub function is more than just bridging the signals; it selects and repeats one transmitted signal to all of the receivers so it is more than just a passive function. Switches do actual store and forwarding.
I always wondered if 100 Mbit Ethernet could be adapted to operate with carrier-sense multiple access with collision detection on a shared media like 10 Mbit Ethernet can but I never saw this implemented. I have a pretty good idea how it could be done while using a standard 100 Mbit Ethernet physical layer interface.
I'm working on new pin mappings trying to include some of your thoughts and saying that is quite challenging is simply understatement.
1. If differential transmission line is used, I presume there is no need to have GND next to line+/- pins.
2. Are you aware of any mechanism/wiring that can be implemented when same signal line(s) can be used as single-ended OR differential?
3. Does it make sense to spare some pins (primarily on the hi-speed LVDS signals) by introducing Isochronous self-clocking signaling?
One option for relatively fast and low pinout bus would be just USB2.0, just 2 pins for >400MBits of bandwidth, that is also very easy to interact with directly from micro.
Yes it would, however there are pretty much commodity. Disadvantage is quite a bit of overhead when coding for it (altho there is plenty of ready-made code to support) and possible issues with bus contention (as you can't really control how usb hub handles traffic)
Just FYI, isolating LVDS with a transformer requires the use of DC-level coding eg 8b/10b (which is commonly used). Unfortunately that will likely require SERDES chips or FPGAs (could use ICE40s).
It’s possible to get quite good software triggering, especially if a good clock is distributed.
I didn't read this through, but I hope there have been though of:
- Power consumption, should be compatible with low power battery equipment.
- Separation, Should be galvanically isolated.
- Complexity, should fit in a minimum of memory and be build with ease.
- Cost, Should use simple parts and techniques
- Measurable, medium speed.
IE. Interesting protocol SW/HW were HP-IL
Yes it would, however there are pretty much commodity. Disadvantage is quite a bit of overhead when coding for it (altho there is plenty of ready-made code to support) and possible issues with bus contention (as you can't really control how usb hub handles traffic)
Great, and we are again in situation that asks for MCU on all modules (master/control and slaves/peripherals) or at least a kind of USB-to-somethingelse bridge on peripheral modules.
Just FYI, isolating LVDS with a transformer requires the use of DC-level coding eg 8b/10b (which is commonly used). Unfortunately that will likely require SERDES chips or FPGAs (could use ICE40s).
It’s possible to get quite good software triggering, especially if a good clock is distributed.
He, he, and guess which MCU (not FPGA) has serious built-in SERDES functionality: XMOS again