I recently realized that you can customize the clock speed for each SPI chip that you talk to, since only one is ever listening when you enable its chip select pin.
But I was wondering what you can get away with on I2C.
I currently have a PCF8523 RTC as the sole chip on my I2C bus running at 400kHz. I would love to add a MCP23008 8 bit I/O expander running at 1.7MHz, but the RTC tops out at 1MHz. Can i run the bus hot for the i/o expander at 1.7MHz, or am i running the risk that the RTC might respond in error to what it sees as a garbled, too fast message on the bus?
With I2C, is my fastest clock speed limited to the slowest component on the bus?
Are their any low-cost (compatible?) RTC’s that I could swap out that would run on a faster bus?
Could you disable the PCF8523’s I2C interface by removing it’s VDD (ie powering it with GPIO control) and leaving its VBAT connected, so that it goes into battery backup mode?
When the device is first powered up from the battery (VBAT) but without a main supply
(VDD), the PCF8523 automatically enters the standby mode. In standby mode, the
PCF8523 does not draw any power from the backup battery until the device is powered up
from the main power supply VDD. Thereafter, the device switches over to battery backup mode whenever the main power supply VDD is lost.
It seems that it would ignore anything (at whatever speed) on the I2C bus in that state, while, I presume, keeping time adequately for your needs.
The interface is disabled in battery backup operation:
• Interface inputs are not recognized, preventing extraneous data being written to the
device
• Interface outputs are high-impedance
I don’t know whether this stymies your need for interrupt outputs from the RTC but it could be a nice way to make it play with a faster I2C bus clock without too much pain. And please know that I have barely skimmed the datasheet to come up with this scheme - there may well be reasons why it won’t work that I haven’t found (because I haven’t looked!). Good luck!
The mcp47feb12 supports High-Speed mode, which it enters after sending a special address. At this point, other devices on the bus should stop listening.
In short, you would need to send the command at the standard speed, and increase the speed for the following bytes.
Alternatively, you could consider an I2C multiplexer to only talk to one device at a time.
Interesting. Difficult to tell if they are talking about normal operation (excluding battery backup mode) or all scenarios (including battery backup mode).
There are some other interesting notes that make me think if this is not for a high reliability application, it might be worth experimenting. The first is the Note 6 in the Inputs table you extracted, @romain:
[6] The I2C-bus is 5 V tolerant.
Which means maybe it is quite tough/protected. The second is the max input current is quite high, at 10mA, so depending on the setup of the internal protection diodes, it could be quite possible not to come close to that, even if SDA/SCL are at 3.3V (an assumption on my part that this circuit is operating on 3.3V) when VDD is 0V.
But like I said, my original pondering was certainly not well researched
If you are already talking about assigning a pin to turn off the RTC, I might approach this by disconnecting SCL (and optionally SDA) from the RTC with a FET and a keeper pull-up on the RTC side so that it doesn’t see any bus activity. As long as the RTC doesn’t see any activity to initiate a transfer sequence, it won’t load the SCL line to clock stretch.
Overclocking would worry me. I’m always amazed at how many ICs wedge (and/or wedge the bus) if they get a spurious start or address but invalid input (or whatever). I would either just test overclocking the bus (and then still be nervous) or isolate the low speed segment with FETs like @ToyBuilder suggested or use a repeater/isolator.
Another possibility, if you have reconfigurable hardware and/or code space to spare – make that additional pin a SCL2 and clock the RTC separately. Some MCUs will let you steer your pins / turn on alternate pin mappings to make this easy. Otherwise, you could bit bang.
