Is I2C mixed frequency possible?

Question

Suppose we have a 400 kHz I²C bus. There is one master and a bunch of slave devices. We would like to introduce one more slave device, but unfortunately it only goes to 100 kHz .

Clearly, the solid design choices are:

• just run that bus at 100 kHz
• use separate buses for the 400 kHz and 100 kHz peripherals

But the question is just about a hack: what if we use one bus, and address the 400 kHz devices at 400 kHz, and switch the bus to 100 kHz when speaking to the 100 kHz slave?

Or could the slower slave misbehave in response to the 400 kHz hash that it sees on the I²C lines because it mistakenly thinks that it is being addressed?

Can we depend on 100 kHz devices to still be able to process 400 kHz I²C signal sufficiently well to reliably ignore messages addressed toward other slaves?

Answer 1

As you suggest, doing so is not a good engineering practice. While some devices would most ignore traffic that they are not able to receive (undersample), other devices might clutter the bus with erroneous frames.

Thus, the answer you are looking for depends on your the specifics of your application such as:

• length of your I2C connections
• pull-up resistors value
• device compatibility

Of course, it's hard to predict what would happen to a device operated outside its specs a few years down the road.

Another option is to run a shutdown line to slow devices or pass the clock line (provided they cannot generate clock signal) through an AND gate.

Answer 2

Another option, if you don't have an additional I2C bus coming out of your master is to use an I2C switch, such as the PCA9543A/43B. Put the 400kHz slaves on one branch and the 100kHz slaves on the other and switch it as necessary.

Answer 3

There's no guarantee that the 100kHz device will not misbehave when exposed to 400kHz traffic - anything from NACKs to bus hangs are possible.

You should either run the entire bus at 100kHz or have a separate low-speed bus for your slow peripheral.

Answer 4

Other options. Instead of having two busses, you could simple use one extra line (Easier with a software/bitbanged I²C). A separate clock line, or a separate data line. Or use a I²C buffer or I²C switch to put that single 100MHz chip on it's own segment, without having to change anything else.

Or just test it out on a single bus. It's quite possible that the 100kHz chip would affect the line. It could read every 4th bit and end up thinking it's been addressed. But it would have to see a valid start condition, and then read every 4th bit out of the next 32 bits as it's exact address, then it would either have to try to read the next couple of bytes as valid information to write to it's registers, or try to clock out data. I don't think it's too likely a situation. Best bet is to simple wire it up in a test circuit and check it out.

Two things to note, if this is a one off circuit, or you are only making a few, it's easy enough to risk it, or change it. If it's a mass produced item, you might just want to have the second bus. The other, is that you have to consider that the 100kHz chip was simply produced to the original I²C spec, and might very well support higher clock speeds. It just wasn't tested to the higher speed 400kHz spec.

Answer 5

The design of the I2C bus is such that -

1. when an falling edge occurs on SCL, that may cause a slave device to immediately assert SDA, without any particular minimum delay;
2. the relative ordering of rising and falling edges is of critical importance.

Because of difference in driver strength and line capacitance, it would be theoretically possible that one device might respond to a somewhat slow falling edge on SCL by driving SDA so fast that another device would see SDA fall first.

It might have been possible to define multiple logic thresholds on SCL, and specify that for a falling edge on SCL to be considered as coming after an edge on SDA, it must still be above 2/3 VDD when the edge on SDA is detected, but a device may not assert SDA in response to a falling edge on SCL until it has fallen below 1/3 VDD, but the spec is not written in such terms.

Instead, devices which see near-simultaneous falling edges on SDA and SCL will generally regard the edge on SCL as having happened first unless it is substantially preceded by the edge on SDA. Some I2C implementations handle this by synchronizing SCL and SDA to some external clock and requiring that a falling edge of SDA be observed two periods before that of SCL in order to be regarded as having come first. If the speed of operations on SCL and SDA is too fast relative to the synchronizing clock, the devices may perceive arbitrary sequences of high and low signals on SCL and SDA; if one of those sequences looks like it is addressing the slow device, it may react accordingly, squashing any other communications that may be going on.

There's no particular reason that devices on an I2C bus should have to rely upon synchronization to a system clock (being able to sense two discrete thresholds on SCL would be better), but the fact is that some devices in fact work that way. Note that even if a device which was limited to slow speeds internally wanted to coexist with a fast bus, it would likely have to at minimum employ clock stretching any time something was going on that it might be interested in.

This would cause some communications to occur more slowly than they otherwise might, but the speed degradation likely wouldn't be nearly so bad as is required with the clock-synchronized design (the actual amount by which the slow device stretches clocks likely wouldn't be so bad as the amount by which the clock must be slowed down to avoid worst-case-scenario failures in the synchronized clock units).