I2C Protocol: Role of Clock and Data Control for Master and Slave

[Kittu20]

Hello everyone

I'm a bit puzzled when it comes to the scenario where both the master and slave control the clock and data lines.

Here's what I've got so far: I understand that when the master initiates a write operation, it takes control of the clock and data lines to send data to the slave device. However, I'm not quite clear on how the slave takes control of these lines and when exactly it does so.

Could someone kindly shed some light on this? Specifically, I'm curious about how the slave controls the clock and data lines. Does this happen during read operations from the slave device? If so, how does this process work?

Looking forward to your insights and clarification on this matter!

Thanks in advance!

[SiliconWizard]

The main case for a slave to hold SCL low is for clock stretching. (Otherwise you can have I2C topologies in which you have several masters on the same bus, but I'm assuming that's not what you are talking about here.)

Explanation here: https://www.i2c-bus.org/clock-stretching/

[ataradov]

There is also an official I2C specification, which details all possible modes and where clock stretching is allowed - https://www.nxp.com/docs/en/user-guide/UM10204.pdf

[Doctorandus_P]

Attached is an older version of UM10204 from 2017 (Edit: ataradov just beat me with his post while I was still typing), which is the official I2C specification from Philips / NXP. Later versions have dropped the "master / slave" nomenclature and that may be confusing.

I don't use I2C much. A short recap from what I remember:
The master always controls the clock line, but the data direction can vary.
Master first sends and 8-bit byte, which has 7 address bits and a read / write bit.
The ninth bit is an "acknowledge bit, which is sent by the slave, on a clock pulse generated by the master.
After that the data direction depends, on whether the master wants to send or receive data.
Each byte is followed up by an acknowledge bit, that goes in the other direction.
Except for the last byte. That byte is not acknowledged, which indicates the end of a data transfer.

[Kittu20]

The main case for a slave to hold SCL low is for clock stretching. (Otherwise you can have I2C topologies in which you have several masters on the same bus, but I'm assuming that's not what you are talking about here.)

Explanation here: https://www.i2c-bus.org/clock-stretching/

  I'd appreciate your expertise to confirm if my grasp of clock control in I2C aligns with how it actually works. 

I think slave controls the clock line during read operations through clock stretching. During write operations, the slave doesn't control the clock line in the same way. The master initiates the clock pulses while writing data to the slave.

[ataradov]

In the standard modes (Sm, Fm) the slave may apply stretching for any operation anywhere in the byte, it may stretch each bit it it wants to.

In Hs mode there are limits on where the stretching can happen.

[Kittu20]

In the standard modes (Sm, Fm) the slave may apply stretching for any operation anywhere in the byte, it may stretch each bit it it wants to.

In Hs mode there are limits on where the stretching can happen.

Can you share real-world scenarios where these differences in clock stretching behavior might have practical consequences or benefits?

[ataradov]

The reason it is different for Hs is that Hs is very different in general. Hs mode devices are very rare, so I would not consider them relevant. Everything that actually needs the high speed uses SPI.

And in practice most slaves would stretch before the ACK to let the MCU handle the data and prepare a response.

[Kittu20]

I am stumbled upon an intriguing scenario. Imagine two master devices (Master A and Master B) writing data to a single slave. Later, Master A wants to read data from the same slave.

My question is: How does the slave know which master to send the requested data to, especially when both masters have interacted with it before? I understand I2C uses addressing and read/write bits, but I'm curious about the specifics.

How does the slave differentiate between Master A and Master B?

[wek]

> How does the slave differentiate between Master A and Master B?

It does not.

In the basic protocol, only slaves have addresses, and they don't know, which master talks to them.

Of course you can build a secondary protocol upon this. Think for example of a bog standard I2C EEPROM, and a rule, that master1 reads and writes addresses below 0x100 and master 2 above 0x100.

JW

[ataradov]

Masters will negotiate the bus access. Only one master has access at a time, so the slave will not be confused.

There are two scenarios that can happen when both masters try to drive the bus:
1. They both want low state, this is fine, since there is no distinction at that point.
2. One master wants a low level and another one wants a high level. The master that wants a high level will sample a bus and see that it is driven low, it will assume there is a bus conflict and remove itself from the bus.

So, if two masters start at exactly the same time, the master that wants the bus to be high will lose to the master that wants it to be low. And the bus state in general remains consistent, since as far as the slave can see, it was always the way the winning master wanted it to be.

The other master will have to retry the access later.

In the unlikely scenario that two masters want exact same access at exact same time, it would also work fine. The slave would just see it as a single master and neither master would know that there is another master on the bus.

[Doctorandus_P]

Bus arbitration on a multi master bus is explained in detail in the manual. Arbitration can officially continue into the data part of a packet.

In practice however, many implementations are incomplete and attempting to use multi master mode on I2C often leads to lots of headaches to get it to work. I2C is quite complex for a seemingly simple two wires and two pullup resistors. From bus capacitance restart conditions clock stretching into infinity and other issues and the combinations make it quite complex.

[Kittu20]

Hey everyone,

I've run into a bit of a puzzle regarding I2C communication with multiple temperature sensors that have the same address. I hope someone can shed some light on this situation!

Here's the scenario: I have a microcontroller that's connected to two temperature sensors via I2C. Both sensors, one measuring hallway temperature and the other kitchen room temperature, share the same I2C address. This has left me scratching my head on how to communicate with them effectively.

My confusion stems from the fact that both sensors can't be uniquely identified based on their address alone. How does the microcontroller manage to communicate with each sensor separately? Are there any workarounds or strategies to overcome this address collision issue? I'm really curious to hear your insights and suggestions on this matter.

Thanks in advance for your help!

[ataradov]

There is no way to communicate with multiple devices on the same bus with the same address.

Split them over multiple buses. This is the only solution.

[SiliconWizard]

There is no way to communicate with multiple devices on the same bus with the same address.

Split them over multiple buses. This is the only solution.

Good thing - if you only have access to one I2C bus - there are I2C multiplexers, which only require an I2C bus themselves for control, that can do this for you, such as the TCA9548A. Can be pretty handy.

[ataradov]

For temperature sensors just bit-banging I2C may be easier. They don't need fast speeds and don't transfer a lot of information.

[wek]

I2C is not intended to be operated over distances of several meters, either.

Not that it won't work, slowly because of the capacitances, but you may come to unpleasant surprises due to crosstalk to power lines and various induced voltage spikes.

JW

[cv007]

Are there any workarounds or strategies to overcome this address collision issue?

No one knows what mcu you are using or what i2c device is in use, so we are left to speculate what you may or may not have for options.

In addition to previous comments-

The i2c device may have address pins that can be used to select from several addresses for this very purpose (most do), and if not there is most likely available a higher pin count version with the address pins(s). There are many i2c temperature devices to choose from, so if you need multiples of them on the same bus pick one with address pins.

Your mcu may also have an alternate set of i2c pins, and there is then no reason you cannot use both sets of pins switching to the appropriate set before each transaction- one i2c peripheral, two busses.

[rstofer]

This document may help with design of the physical bus.  I2C wasn't designed to go past the motherboard but, at slow speed, it can be designed to operate over a mile.

I would consider any other protocol.  A pair of tin cans and a string would be easier than I2C.  I would probably use RS485...

https://www.nxp.com/docs/en/application-note/AN11075.pdf

[PCB.Wiz]

Hey everyone,

I've run into a bit of a puzzle regarding I2C communication with multiple temperature sensors that have the same address. I hope someone can shed some light on this situation!

Here's the scenario: I have a microcontroller that's connected to two temperature sensors via I2C. Both sensors, one measuring hallway temperature and the other kitchen room temperature, share the same I2C address. This has left me scratching my head on how to communicate with them effectively.
..
Are there any workarounds or strategies to overcome this address collision issue? I'm really curious to hear your insights and suggestions on this matter.

I think there is a trick where you can swap the SDA and SCL lines, thus creating two i2c links.  If you only have 2 sensors, that can work.
You need SW bit bang or an i2c HW that supports pin-swap, in order to drive both versions.

eg this from Silabs part

SMBus Pin Swap
The SMBus peripheral is assigned to pins using the priority crossbar decoder. By default, the SMBus signals are assigned to port pins
starting with SDA on the lower-numbered pin, and SCL on the next available pin. The SWAP bit in the SMBus Timing Control register
can be set to 1 to reverse the order in which the SMBus signals are assigned.

[mikerj]

Here's the scenario: I have a microcontroller that's connected to two temperature sensors via I2C. Both sensors, one measuring hallway temperature and the other kitchen room temperature, share the same I2C address. This has left me scratching my head on how to communicate with them effectively.

You might want to look at 1 wire sensors like the DS18B20.  These all have a unique address that can be discovered as part of the protocol, and can even power themselves from the data line if required.  The protocol is quite slow, but perfectly fine for temperature sensors and quite easy to bit bang on a small micro and there is a lot of example/library code available for this as well.