On I2C protocol

SCL is usually an open collector style of signal. As such it can only be driven low (floated high). So that means, if the slave is inserting the DELAY it will drive SCL low for the duration of the DELAY.

I believe a DELAY could occur for any of the scenerios that you mentioned.

If the master is inserting the DELAY (you have a single master system) ... it doesn't matter what the state of SCL is as long as it doesn't toggle and provide a rising edge.

Mike

This is a bad assumption. The common situations that include delays must have the SCL clock stretching from the slave. Without that clock stretching, there's no idea when b1 or b2 start. The SCL holdoff is explicitly to allow for slave latency.

For the sake of generality, the clock stretching not only applies to a byte level, it also applies to a bit level. Fortunately common situations are not general situations or it would mean that every i2c slave device would be always slower with respect to its specifications. So i can always take into account the latency as a preliminary step. But what i was investigating on was the possibility of the master to introduce a delay.

and

Mike, thanks.

In a single-master system you have complete control over the delay between SCL pulses. AFAIK there is no maximum delay spec for any of the standard (100K and 400KHz) timings, however it's not considered good practice to start a transfer you're not ready to complete (as a master). Also IIRC the SMbus allows for timeouts to prevent bus hang, so in that case there are maximum times. SCL is never presumed to be a continuous clock running at the nominal frequency. Delays from one bit to the next or from start condition to the first bit, etc. are specified as minimums. In a typical master, it wouldn't make sense to introduce a delay except between data bytes. For most I2C access you can accomplish multiple byte access to a slave either by continuous data bursting or by starting a new access. This is certainly true when accessing EEPROM. In such cases it doesn't make sense for the master to introduce delays in excess of the time it would take to stop and start a new transfer.

Just out of curiosity, whay would you want to add delays from the master?

Clock stretching is a means whereby a Slave tells the master to 'pause' - it has no real meaning in a Master context. To any slave, it is just a wider SCL pulse, and slaves only have a min time spec [unless you also have lock-out watchdogs, but they are rare]

Even Slave Clock stretching is rare. It is in the spec, but not often used. i2c speeds are very slow by modern silicon standards, so slow-down-more is not often a problem !

Serial EE proms, have chosen a polling system for their 'wait' requirements.

-jg

I don't want the master to explicitly add delays. I'm rewriting the i2c master module and i get caught by the same question again "What if the user module of the i2c core didn't provide the next data fast enough? (i also considered a fifo). I know that 100/400Khz are slow enough compared to the user mode clk speed, but i believe in black boxes or what object oriented approaches call incapsulation. The user module doesn't have to depend on its child module implementation when possible and viceversa. So i'm figuring out whether i can make the core robust such that it can recover in cases of delayed data arrival. That said, even with a robust core the user module will implement things such that delays don't happen.

see you, Gabor

Yeah, i notice the Ack polling in Microchip's seeproms.

By the way, are royalties still due to Philips? Or have the copyrights expired. Just curious, i read something about it time ago.

bye, Jim

If you limit yourself to 400 kHz and 10 bit addressing, no royalties. Our company contacted the Philips legal folks a couple years ago to clear it up for ourselves.

Thanks

Do you mean no more than 400 KHz and no more than 10 bits? Or should there be royalties for 100 KHz and 7 bit addressing? The last time I talked with Philips they said it was okay to use I2C if there were Philips chips on the bus. In our case this is generally true.

I was told recently by a NXP disti, that i2c expired a 'couple of years ago'. It was always a loose coverage they had anyway, many of the docs state ~"you are free to use, provided you adhere to spec", but I think they did charge for the i2c logo/tm and so there was a quasi-license. In the embedded space, I doubt they could care either way.

There was a 3.4MHz spec, but I never saw silicon. The new FM+ specs 20mA drivers, and lower pullups

-jg

There are I2C implementations that exceed 400 kHz (1.6 MHz?) and/or have greater than 10-bit addressing. It's these items which are still covered by Philips patents. 100 kHz and 7 bit is fine according to what we got directly from the patent holders.

O.K. I went to NXP.com and found a link to this page:

which pretty much says they're not charging royalties for licenses although it doesn't go so far as to say you don't need a license...

There's no mention of high-speed I2C licensing. Is this under a different patent holder (i.e. not Philips)?

I'm not sure. I only know the caveats that were communicated to us about the 400 kHz and 10-bit address limits.