I2C master

David Lesher wrote on 9/22/2017 2:59 PM:

There are two features in I2C that I believe are seldom implemented. One is clock stretching and the other is multiple masters. I don't know, but suspect you are looking at a long row to hoe.

Thanks, we'll eschew. RS-232 may be old and slow but works....

It's also not multi-master... I guess you can roll your own.

RS-485 is a solved problem, cheap, and noise tolerant. Or CAN, if you don't mind a little more hardware (often provided in MCUs) and more automation as far as the bus dealing with bus-y problems all by itself.

These might be a little hungry, or overly robust. If you need lower current consumption, and the signal doesn't have to leave the board, an open collector bus (like I2C) is still a good idea.

Tim

If you have *any* other choice. Don't go there. There be demons there.

Clock stretching is rather common. It's used in the various I2C extension interfaces like the LVDS video interfaces (Maxim or TI) and things like A2B (ADI).

Tim Williams wrote on 9/22/2017 10:42 PM:

RS-485 is an electrical interface, nothing more. It doesn't solve the multi-master problem any more than RS-232 does.

Well, RS-232 is an anti-solution, as it's always asserted. Point to point only. There's a reason I said 485 and not 422.

As for the protocols traditionally used on these interfaces, asynchronous serial with some kind of bus arbitration is standard on 485.

For some strange reason, when you search on "RS-485", you get not just the signaling standard, but also a lot of protocols that people use on it... ;-)

Tim

Tim Williams wrote on 9/23/2017 12:55 AM:

There are plenty of networks based on RS-232. As you say, a little searching helps a lot. But giving an electrical standard reference is nothing like actually giving some useful information on the networking issue.

RS-485 is half-duples master-slve systems. With a single master, it will access slave(s) sequentially by polling with some protocol.

With multi-master the only extra thing that is needed is some coordination between the master, no need to coordinate the slaves, since it is already handled by the basic poll protocol.

Since all masters are on the same RS-485 bus, they will hear each others transmissions. For instance, active master can send a handover telegram on the bus, which the passive master intercepts and becomes active and starts polling the slaves.

A more formal method is to use token passing (as in Profibus-DP) between the masters and then let each master do its own slave polling.

RS-232 multidrop would require a isolation diode for each port and a common pull-down resistor, effectively creating a wired-OR system. But this doesn't solve the arbitration problem.

I have used this for connecting a dumb terminal and an external digitizing table into a single serial line. No problem with arbitration, since the operator operated the terminal or table with the same hand :-).

Open collector wired-OR doesn't solve the arbitrary issue by itself.

If the power consumption for a standard compliant CAN transceivers is too much, low power consumption non-compliant CAN networks can be implemented with practically any full duplex transceivers with a Transmitter Enable (TE) pin. The CAN controller drives the TE pin when actively sending the Dominant ("0") state on the wire. To send the Recessive ("1") the transmitter goes three-state and the passive pull-up resistor generates the "1" state on the wire.

Before the first official CAN transceivers were available, ordinary RS-485 transceivers were used. I would not be surprised, if some LVDS transceivers could be used as well.

A "network based on RS-232" is an oxymoron. If it's RS-232 it can't be a network. As pointed out above, it's always asserted. Neither a bastardized RS-232 or RS-485 solves the arbitration problem any more than I2C.

The I2C multi-master arbitration does work, if all potential masters follow the specification. I have used it with both bit-banged software implementations and hardware-assisted implementations. For hardware, I used Atmel SAM4 TWI interfaces.

-----

'RS-232' is misused at least as much as 'RS-485'. Most often 'RS-232' seems to imply asynchronous serial data transfer, but the specification does not specify the bit stream in any way.

The same applies, to a lesser extent to 'RS-485'.

Even if the hardware follows the specification, it's doesn't guarantee a competent programmer. Just say *no*.

It does specify the drivers and receivers. It cannot be a network. If it is, it's not RS-232.

Not at all. It was designed to be multi-master (and bidirectional). Anything can be, and is, screwed by software but there is a big difference between RS-485 and RS-232.

You can't have a shared bus but you could still make a network I think, using multiple ports per device. Horrible of course :) Come to think of it modern ethernet is also like this isn't it?

Indeed.

And you can, in fact, hack a "routerless" network, using diodes (and much shorter cables, under 20m I think). Collisions are frequent if multiple nodes are talking at once, so it's slow (besides the fact that it may not enumerate higher than 10Mb!).

So you can do both, yeah, sure! :-)

On a related subject, "RS-232 hub" only turns up USB-to-(many serial) boxes. Perhaps a more specific tack is necessary. "Modbus hub" or "modbus router" seems to return useful hits, though Modbus is carried on so many PHYs that it's not obvious you'll find ones made with good old RS-232 on DE-9 connectors. Seems like the nearest thing, though!

Tim

Yes but then it is not really RS232 any more...

How can you use diodes to wire-OR the differential pairs, assuming that's what you mean?