If I were to combine a large number of channels onto one PHY, then yes I would likely use some sort of scheduled communication scheme to avoid collision. Or make it so that the slaves only send data when asked by the master. That's one of my concerns with an ethernet implementation. Is there such a way to implement such behavior with normal ethernet ports/modules?Whatever the solution you chose for the physical layer, the most restrictive detail in this layout is the synchronization between all these devices in order to avoid collision and data loss, so that a simple system with neither resending protocol or local buffer for output, wont work; but this solution by itself would kill the implicit requirement to have a real-time reading. Better you consider the master receiving data from each channel upon its own request instead of having to deal with a huge unsynced data srtream.
Or make it so that the slaves only send data when asked by the master. That's one of my concerns with an ethernet implementation. Is there such a way to implement such behavior with normal ethernet ports/modules?
I2C is absolutely not suitable.The best protocols for globalized transmission and its peripheral included in microcontroller is I2C and CAN
UART is only a part of an interface. It doesn´t tell what signals levels to use.UART is not recommended for point to multi-point communication unless ypu were sure about impedance matching of the communication lines, obviously its nearly impossible to communicate to 128 devices.
I assume that the vast majority of that ping is in your OS, and in the TCP stack. For our implementation the slaves will be MCUs (which will devote most of their resources to keeping communication latency low as possible) and the master will be a custom pxie module with the necessary transceivers, again devoting all resources to communications.The amount of connected devices is quite restrictive, even with a 'lighter' protocol such as the UDP for example (with which losses would not be handled), considering antennas at different positions at locations with more or less obstacles, it would not be unlikely that consecutive requests would have the response sent to the same time therefore having colision. Your timing requirement is something that gives you little room for maneuver. Here, very close to my Wifi router, I can PING ( which is a even lighter protocol ) running with 54Mbps and it took 3-4ms, having only my Laptop connected. You have specified 0,1ms for each one of all 128 devices. I would say it is not feasible with the 802.11 standard wireless. Better to thing about a lightweighter communication standard with less runtime overhead, or even change your reuirements.
What about 80 bytes every 1ms? Or 800 bytes every 10ms?
Right, and by using larger packets less frequently, I should reduce overhead for channel switching. I'd be shocked if 10ms isn't enough with optimized MAC drivers.For each one of the 128 slaves ? As said, the speed by itself is not the main issue, but rather the time allocation for each transmission of all devices.
Glad you drew my attention to Profibus, it's at least good to see that there are some good industrial control protocols which can be implemented with UART and still get decent speed.UART is only a part of an interface. It doesn´t tell what signals levels to use.
UART in combination with RS422/RS485 is used many times in the industry.
Profibus for example.
A UART based interface is way more suitable than I2C for this application. But you need several interfaces to handle the ammount of data.
Using SPI would definitely be too much wiring. If I could use copper interconnects, a large number of RS485 busses (maybe Profibus) with 4-8 slaves each would likely work okay. But with fiber, I might as well use a protocol with full duplex (not Profibus).I don´t have a soultion, but i think about a full duplex soultion. Maybe SPI style but with RS485 signal lines.
* Hardware addressing (CS) is faster then addressing via protocol (can be single ended)
* all slaves may be to connected to a single MOSI data pair
* all slaves may be to connected to a single MISO data pair
* all slaves may be to connected to a single SCK clock pair
* only the addressed slave enables it´s RS485 driver (MISO)
* transmit of 8 bytes of data takes place in parallel to receive 8 bytes of data. (full duplex, no data overhead = data efficient)
But even with this topolgy I doubt that this is a useful solution because of the high effort in wiring - especially the 128 individual CS lines.
Klaus
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?