On Jul 23, 1:12 pm, "devices" <me@home> wrote:
> "John_H" <newsgr...@johnhandwork.com> wrote in message
>
> news:[email protected]..
>
> >>>>>>>> As for the I2C Master, assuming no clock stretching
> >>>>>>>> is issued by the Slave,
> > 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.


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?