I2C speed

400khz is the standard value everybody knows. For example I play in these days a little with NCA9555 and the datasheet said 400khz. But I know from experiment that 2000khz works well. We can not complain that someone sell us something better we paid for.

Olaf

I forget who it was that said we should make things as simple as possible, but not simpler.

The specs, tLOW and tHIGH do not create a spec for the minimum period. Your idea that you should be able to cycle the clock at 526 kHz is faulty. While that might satisfy both tLOW and tHIGH, there are other factors inside a given chip or interface that sets the minimum period to 2,500 ns. There is nothing in this spec that says it's ok to use the minimum value of both tLOW and tHIGH, if the sum is less than 2,500 ns.

I forget the part number, but there's a well known chip for interfacing a basic 20x2 (and other sizes) LCD display to an MCU. It has a number of specifications that allow the bus cycle to operate at up to some MHz value. But... there are some instructions that run slower, so this max bus rate can not be used with *those* instructions. I believe there is a FSM inside (perhaps even a crude MCU) that interprets the instructions sent to the chip, such as "clear all". I think it copies null data to all memory locations, sequentially.

Sure, and that's what I'm going to do. I'm just curious where the missing 126kHz are. 526/400 is quite a substantial transmission speedup, so IMHO the question is worth asking. A conforming slave needs to meet the t-s anyway, so why capping it by the f-s?

Best regards, Piotr

And we can not complain if the first few units we test work much faster, but our production runs fail to work in the field because we are running it outside the spec. PVT, Process, Voltage and Temperature. We can control and test over V and T, but P is beyond our control and therefore ability to test.

I am not arguing with that and had already chosen to follow the way suggested by DonY before starting this thread. I'm asking what technical reasons imply specifying it the way it's been specified. What needs the additional delay? Best regards, Piotr

It's not about exceeding the specs, the (particular instances of) parts work at 526kHz just fine. I just don't understand where the f-related delay goes, because it leaves a hefty headroom relatively to what the t-s say.

I plan to meet all the criteria, that's not the point.

Best regards, Piotr

Than you, I think I can see what you mean. But look what I2C *is*:

1. There's the protocol control part (the S/P/repeated S) that is not periodic, so it is defined purely in terms of t-s. That part is crystal clear.

1. The content transfer indeed depends on a periodic SCL signal, but then a conforming implementation must discriminate between SDA_ACTVE and SDA_IDLE reliably, and the same about the clock signal segments. This reliability is defined in terms of tLOW and tHIGH. Anything that recognizes idle for >=600ns and active for >=1300ns is conforming. That's clear, too.

2. Anything that can work with 600ns pulses should have no issues with

1900ns pulses either. Because physics.

1. So since the circuit must have decoded the 600ns pulses reliably

*and* these are already available on the silicon chip *and* the receiver is a synchronous shift register clocked by the SCL in that transfer phase, what makes this shift register incapable of shifting data at 526kHz? The specs says 1/(600ns+1300ns+x)<=400kHz. What's the x? Even the most simplistic implementations of the shift register would have the x==0 (i.e. the setup and hold times would be hidden under the timing of the other protocol segments that follow), so who ordered that x >> 0? What's the rationale behind the f cap?

Best regards, Piotr

søndag den 30. juli 2023 kl. 09.15.38 UTC+2 skrev Piotr Wyderski:

see it as limit on duty cycle not frequency

so at a frequency there is limit on duty cycle, but I'm sure there is a way to write pages of nitpick about it ...

You trimmed my post where I explain why the LCD controller was like this. What part of that did you not understand?

How do you expect anyone else to know the details of a spec they didn't write?

One point I forgot to mention is that this is an open collector/drain bus. There needs to be time allowed for settling of the bus, i.e. transition time. Not that this will account for the remaining time. Do they specify the tLOW and tHIGH to include the transition time, or are these numbers exclusive of the transition times?

Table 11 in Rev. 7.0 — 1 October 2021 of the specs, available at

, contains a column called "Fast-mode Plus" and shows f_SCL_MAX=1000kHz.

Danke,

Never mind. Your desire to use fast mode is clearly stated above. "Misery loves company." It also confuses me when things won't add up. My instinct is to blame it on sloppy, half-baked, work product.

Danke,

The slowest slave on the bus is specified to support only fast mode, so I have no choice but to comply.

Best regards, Piotr