Is there a minimum clock rate specified by I2C? I know the most widely used clock rate is 100kHz and there is a "fast" mode of 400kHz supported by some devices, and a faster yet mode supported by other devices (I think 1MHz?). Since the SCK signal is generated by the master I presume one could operate at a much slower speed than any of those - is there a lower bound in practice? To what extent do slave devices care about the clock rate (e.g. is it common for them to have short timeouts)? The reason I'm asking is that I'm wondering if could possibly run I2C over a longer distance (e.g. 20 feet) to program I2C EEPROMs reliably in a production tester setup. I'm assuming it won't work reliably over that distance at the standard data rates. Am I off-base entirely in thinking that slowing down the clock speed will improve reliability over longer distances (e.g. is it really a question of drive strength and rise/fall times)?
-
\$\begingroup\$ Hi-Speed mode allows a 3.4 MHz clock at max. 100 pF bus capacitance. \$\endgroup\$– stevenvhCommented Jul 12, 2012 at 15:37
3 Answers
No, there is no minimum frequency, minimum clock frequency is 0, or DC. See the specification, page 48.
But you will have to pay attention to rise and fall times. Those are 1000 ns and 300 ns maximum, resp. And a longer cable, with some capacitance will influence edges, regardless of frequency.
It's that capacitance, together with pull-up resistances that will determine rise time. Fall time is not a problem because the FET which pulls the line low has a very low resistance, and then the fall time time constant will be very low as well. So we're left with the rise time. To get a 1000 ns rise time on a 200 pF cable your pull-up resistors shouldn't be larger than 2.2 kΩ. (rise time to 90 % of end value.)
The graph shows maximum pull-up resistance (in Ω) versus cable capacitance (in pF) to get 1000 ns rising edges. Note that I2C devices don't have to sink more than 3 mA, therefore at 3.3 V the bus capacitance shouldn't be higher than about 395 pF, otherwise the pull-up resistance would have to be smaller than 1100 Ω, and allow more than the 3 mA. That's the greenish dashed lines. For 5 V operation the allowed capacity is even 260 pF, for a 1667 Ω pull-up value (the purple dashed lines).
-
\$\begingroup\$ Who says that I2C-device can max sink 3mA? My I2C devices has VOL =0,4 V for IOL = 20mA. This mean it can sink much more current so can the pull-up resistors be smaller. This cause that more capacitance can be handled. @stevenvh \$\endgroup\$– KonoCommented May 29, 2018 at 15:31
-
\$\begingroup\$ An example is Arduino slaves. They can sink up to 10mA before VOL = 0,4-0,5V. This means they can drive much higher loaded busses. \$\endgroup\$– KonoCommented May 29, 2018 at 15:36
-
\$\begingroup\$ Most of the I2C devices can indeed sink only 3mA, but the nowdays there are much more devices with more sink capabilities. Lucky! \$\endgroup\$– KonoCommented May 29, 2018 at 15:43
I have run I2C at about 100Hz with no problem. Like @stevenvh said, just worry about max speed and line capacitance.
-
3\$\begingroup\$ I have single-stepped i2c. That doesn't guarantee every device you find will be made that way, but there's nothing technically to prevent it working "down to DC". \$\endgroup\$– gbarryCommented Jul 12, 2012 at 17:05
You should be able to solve the line length issues with careful selection of drivers and impedance matching.
Another option, assuming the long run is part of the setup and not the product, might be to use something that handles distance well such as RS422 (or practically speaking even RS232) to talk to a microcontroller placed in the connector of the test harness, which would then talk i2c over a fairly short distance to the target.
Or you could do probably do this without the intelligence, using a little board that bridged a differential signalling protocol with Schmidt trigger receivers to and from the i2c signalling at the target.
Your runs are likely not long enough that signal propagation times (absent settling issues) would require particularly slow clock rates to avoid turning the bus around while old data is still in flight.
Of course you will want to do a readback verification of the data you have just programmed.
Just for sake of comparison, IIRC VGA monitors have an i2c (or is it i2c-like) ID readout, which probably still works if you add a 6-foot extension cable to the stock 3 or 4 foot cable.
