Electronic – Does the STOP condition have any meaning on a single master I2C system

While multi-master I2C may seem like a superset of single-master I2C, it's perhaps most useful to think of them as though they were separate, since a lone master is allowed to act in ways that would be illegitimate for a bus-sharing master, and such actions can recover easily from failure modes which would be harder to deal with in a bus-sharing system. For an I2C master to coexist with other masters on the same bus, it must include support in hardware and software for such coexistence; this support must, among other things, to include time-out logic to handle the scenario of another master starting communication and then getting reset while SDA and SCK were released (or getting reset while SDA was released and releasing SCK as a consequence of the reset). In that scenario, neither master would be allowed to communicate until both had seen SDA and SCK high for sufficiently long as to conclude that anyone who had held the bus must have "died". Lone-master I2C would not have such an issue, since there will never be any transactions pending it doesn't know about, and time it doesn't want a transaction to be pending it can reset the bus by releasing SCK and SDA (if already asserted), waiting for SCK to go high, and if SDA is low at that time, asserting SCK and restarting the procedure (which may be necessary at most nine times); once SDA and SCK are both high, it can begin the next transaction by asserting SDA.

Because of the differences in design between shared-bus and lone-master firmware, most lone-bus applications would require substantial rework to coexist with other bus masters. Since multi-master hardware would be useless without corresponding firmware, I don't see any need for a device which will be used as a lone master to include the hardware necessary for multi-master arbitration.

BTW, one thing I've not seen supported in hardware, but which would IMHO be useful, would be a means of performing shared-address multi-slave arbitration. The signalling protocol would make it easy for a I2C device to support a "prepare to read device IDs" write address and a "get next device ID" read addresses. The former command would "activate" the read-ID mode of all devices receiving it; the latter would cause any device whose read-ID mode was active to try to output its ID (dropping out if it lost arbitration to any other device); any device which successfully output its ID would deactivate its read-ID mode. Under such a scheme, a master which output a "prepare to read device IDs" and then issued multiple "read device ID" requests would receive back the IDs of all connected devices in a fashion much smoother and easier than that used by one-wire protocol.

It is perfectly possible for two masters to send a start bit at exactly the same time, where with exactly I mean that the difference between the start bits falling fronts is smaller than the smaller measurable difference by the masters.

That's the point: when a master is writing on the i2c bus it is also monitoring it, thus it is possible to determine if a collision is occurring.

Let's say that two masters, A and B, connected to the same bus, want to address two different devices, one with address 0xAE (from A), the other with address 0xA6 (from B). The masters send the start bit at almost the same time, then begin sending the address. Since 0xA = 0b1010 they send the sequence 1010, so far so good, but 0xE = 0b1110, while 0x6 = 0b0110. The fifth bit differs, and A tries to send a 1, while B sends a 0.

Who wins? B of course, because i2c is an open collector bus, lines can only be tied low. To send a 1 you just turn off the output and an external pull up resistor ties the line high, while to send a 0 you turn on a pull down. Master A then is sending a 1, but measuring a 0. Big red flag, bus collision! Master A state machine should properly handle the situation, leaving the bus to B.

Please note that from B point of view nothing has happened, and it continues happily with the frame. That is very good because no time is lost and B can do whatever it needs to do.

While it seems that an open collector bus is the solution to all the problems, unfortunately it is not so. The bus can easily be blocked by any malfunctioning device that decides to hold SCL or SDA low. In such situations it is very difficult to reset the bus, sometimes devices have a reset pin, sometimes you have to power cycle them, sometimes you have to think of something even different. Had to do all the three in different applications.

As a side note be aware that not all masters implement the full spec, some masters do not implement bus collision detection and this can be very bad. In the previous example, if nor A nor B can detect loss of arbitration the address sent on the bus is 0b10100110, i.e. B slave address, but when the ACK comes A thinks it comes from its slave, and after that things can get very bad.

There also is the possibility that A and B wants the same slave. If this happens the ACK is received, and then many things can happen.

Usually i2c devices have many registers that can be written and/or read, the communication frame then looks something like:

slave address; ACK; reg address; data;

(Omitting start and stop bits and WR bit).

The masters start sending the register address. If they want to access a different register it just happens what would happen for the slave address: at a certain point one of them detects the loss of arbitration and gives up.

If the masters want to access the same register, or the i2c device has a default behaviour like "if I detect my address I'll tell you the temperature", then... Everything is perfectly fine! Both masters wanted exactly the same thing, and they are getting it, and this is OK per the standard.

Two communications in only one frame, take that Nyquist!