Timeline for How should I optimize I2C communication over a 10 to 25 meter cable?
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 24, 2023 at 15:53 | comment | added | supercat | For something like the OP's situation, and also for 99% of situations involving I2C, the only times anything on the network would need to exchange data with anything else would be when there was a functional master device on the network. Having a single master device on the network at a time will allow both the master device and slave devices to be simpler than would be needed in a multi-master network, and the added complexity for multi-master support is only a good thing in situations where multi-master support would actually be useful. | |
| Aug 24, 2023 at 14:54 | comment | added | Lundin | I had this very same discussion about how antique these RS485 buses are around twenty years ago. They have not exactly gotten more relevant to use since then. | |
| Aug 24, 2023 at 14:53 | comment | added | Lundin | @supercat I know that, no need to teach me - that's exactly how for example Profibus works and it's about as archaic as field bus communication goes. So much useless "ping pong" overhead that it's not even funny. The problematic data layer in turn encourages star network topologies with a master in the middle, which is a bad idea electronics-wise. And if there is no master, everything falls apart. And so on. The last argument for using these buses was that PC used to come with RS232 ports, but that's no longer a valid argument either. | |
| Aug 24, 2023 at 14:42 | comment | added | supercat | If the bus is idle and the master hears anything, it can poll everyone to find out what's happening. If a device happens to send it's "someone has somthing to say" pulse at a time when the master is starting its "I'm about to speak", there may be a collision, but it would be inconsequential since the master would be about to start a polling cycle whether or not it knew of a request, and the only thing "lost" would be the "I'm about to speak", which all slaves would recognize as a signal not to interrupt, whether or not they received it fully. | |
| Aug 24, 2023 at 14:39 | comment | added | supercat | @Lundin: In many cases, packet collisions may be prevented by having one device on the bus serve as the master, and saying that any other bus will only start speaking within a certain period of time of being addressed by the master. As a slight variation, in power-sensitive applications when using a signaling method where a quiescent bus would draw essentially zero power, the master may precede each communication with an "I'm about to speak" preamble, and other devices may send a "someone has something to say" pulse if they have something to say and the bus has been idle for awhile. | |
| Aug 24, 2023 at 7:00 | comment | added | Lundin | @supercat The most obvious of the many benefits (too many to address here) is the bus arbitration. RS-485 has no arbitration, it has packet collisions, which may or may not get detected by the antiquated means of error detection (framing, overrun, parity etc). | |
| Aug 23, 2023 at 16:56 | comment | added | supercat | @Lundin: Although some data encodings may have some advantage over the "UART-style" encodings that write a maximum of one byte every ten bit times, the only downside I see with UART-style communication for most tasks involving speeds below a million bits per second is is a need for a receiver to have a clock that can start timing received data immediately and even that may be mitigated by having packets start with multiple FF bytes, but specifying that any number of FF bytes preceding a packet will have no effect. | |
| Aug 23, 2023 at 9:04 | comment | added | Lundin | The various RS422/RS485 technologies are burdensome and quite outdated technologies. Things like Profibus or Modbus were always painful to work with (not to mention custom, home-brewed protocols), and there's a lot of issues with UART in itself. CAN is actually much smoother to work with once one is past the learning curve. The general trend I've been seeing in automation/traditional industry over the last 10+ years is that UART-based buses are getting phased out in favour of CAN. And the automotive industry always used CAN to begin with, since the 1990s. | |
| Aug 23, 2023 at 8:31 | comment | added | Tim Williams | And to be clear -- I am speaking from my own experience, in which I haven't worked with a whole CAN thing top to bottom, but I've certainly used UARTs and RS-422 and such a solution is foreseeably tractable to me, so that's what I would do. Others may choose different combinations, or protocols, and that's fine, too. (I'd also be half-tempted to use Modbus over RS-485, which I have implemented before; assuming the sensors can be programmed with individual addresses of course.) | |
| Aug 23, 2023 at 7:52 | comment | added | Lundin | "Don't" is the correct answer. Since this is an engineering site we do have an obligation to call out bad engineering. I'd personally always pick CAN over RS-422 given the choice, but either would work here. The learning curve for CAN might be a bit longer but it is more flexible and rugged overall, particularly when you need more than just point-to-point. | |
| Aug 23, 2023 at 4:02 | history | answered | Tim Williams | CC BY-SA 4.0 |