The I2C Clock Speed – Why Accuracy Doesn’t Matter

With an asynchronous transmission such as RS232 the clock is not sent along with the data: the receiver has to rely entirely on the sender’s timing accuracy, so the baud rate must stay constant and precise. The I2C bus works the other way round — it is synchronous, the clock travels with the data on SCL and every device synchronises to it. That is why I2C defines maximum clock rates rather than exact baud rates.

The I2C Speed Grades

These figures are maximum ratings, not requirements. Compliant hardware is guaranteed to work up to the stated clock rate — anything slower, even with a slightly variable bit rate, is perfectly legal. In practice the real bus speed always stays somewhat below the configured value:

Why the Real Speed Stays Below the Maximum

• Open-drain technology. A device never drives a high level — it only pulls the line to ground and releases it. How quickly the level returns depends on the electrical environment: bus termination, series resistors, bus capacitance, cable length and bus voltage.
• Read-back before proceeding. Devices therefore check the actual level of both SDA and SCL after driving a line and continue only once it has really settled — a master writes a zero, reads the line back and only then clocks the next step.
• The effect grows with speed. The higher the clock rate, the larger the share of these settle times. A master configured for 100 kHz usually achieves less — and the gap widens at higher grades.

Practical Takeaway

I2C transfers are short — a few bytes per message — so the exact bit rate hardly matters. In case of doubt it is much better to keep the bit rate below the maximum rating at all times than to occasionally exceed it.

Speed Grades

Several speed grades are defined