FPGA Central

As for the I2C Master, assuming no clock stretching
is issued by the Slave, here is a common situation and
its concerning counterparts.

Usual scenario:

1) Start - b1 - b2 - Stop

And relative CONCERNING scenarios:

2) Start - b1 - DELAY - b2 - Stop
3) Start - b1 - b2 - DELAY - Stop

(and why not) Start - DELAY - b1 - b2 - Stop

Where:

b1 is a completely transferred and acked byte
b2 as above
DELAY is at least, more than a single SCL period.

The difference between 1 and 2, 3 is the DELAY.
Is such a delay allowed? If it is, which is the
polarity of SCL when the master is (let's say)
"stretching"? Low? (i'm not considering a multi-master
bus)

"devices" <me@home> wrote in message
news:46a4bbc3$0$37203$4fafbaef@reader3.news.tin.it ...
> As for the I2C Master, assuming no clock stretching
> is issued by the Slave, here is a common situation and
> its concerning counterparts.
>
> Usual scenario:
>
> 1) Start - b1 - b2 - Stop
>
> And relative CONCERNING scenarios:
>
> 2) Start - b1 - DELAY - b2 - Stop
> 3) Start - b1 - b2 - DELAY - Stop
>
> (and why not) Start - DELAY - b1 - b2 - Stop
>
> Where:
>
> b1 is a completely transferred and acked byte
> b2 as above
> DELAY is at least, more than a single SCL period.
>
> The difference between 1 and 2, 3 is the DELAY.
> Is such a delay allowed? If it is, which is the
> polarity of SCL when the master is (let's say)
> "stretching"? Low? (i'm not considering a multi-master
> bus)
>
>
>
>

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

"devices" <me@home> wrote in message
news:46a4bbc3$0$37203$4fafbaef@reader3.news.tin.it ...
> 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.
<end>

> here is a common situation and
> its concerning counterparts.
>
> Usual scenario:
>
> 1) Start - b1 - b2 - Stop
>
> And relative CONCERNING scenarios:
>
> 2) Start - b1 - DELAY - b2 - Stop
> 3) Start - b1 - b2 - DELAY - Stop
>
> (and why not) Start - DELAY - b1 - b2 - Stop
>
> Where:
>
> b1 is a completely transferred and acked byte
> b2 as above
> DELAY is at least, more than a single SCL period.
>
> The difference between 1 and 2, 3 is the DELAY.
> Is such a delay allowed? If it is, which is the
> polarity of SCL when the master is (let's say)
> "stretching"? Low? (i'm not considering a multi-master
> bus)

"John_H" <newsgroup@johnhandwork.com> wrote in message
news:13a9hnjl693afc@corp.supernews.com...

>>>>>>>> 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.

"Mike Lewis" <someone@micrsoft.com> wrote in message
news:c2ac4$46a4c534$401a86c3$18437@PRIMUS.CA...
>
>
> "devices" <me@home> wrote in message
> news:46a4bbc3$0$37203$4fafbaef@reader3.news.tin.it ...
> > As for the I2C Master, assuming no clock stretching
> > is issued by the Slave, here is a common situation and
> > its concerning counterparts.
> >
> > Usual scenario:
> >
> > 1) Start - b1 - b2 - Stop
> >
> > And relative CONCERNING scenarios:
> >
> > 2) Start - b1 - DELAY - b2 - Stop
> > 3) Start - b1 - b2 - DELAY - Stop
> >
> > (and why not) Start - DELAY - b1 - b2 - Stop
> >
> > Where:
> >
> > b1 is a completely transferred and acked byte
> > b2 as above
> > DELAY is at least, more than a single SCL period.
> >
> > The difference between 1 and 2, 3 is the DELAY.
> > Is such a delay allowed? If it is, which is the
> > polarity of SCL when the master is (let's say)
> > "stretching"? Low? (i'm not considering a multi-master
> > bus)
> >
> >
> >
> >
>
> 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
>

Mike, thanks.

On Jul 23, 1:12 pm, "devices" <me@home> wrote:
> "John_H" <newsgr...@johnhandwork.com> wrote in message
>
> news:13a9hnjl693afc@corp.supernews.com...
>
> >>>>>>>> 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?

devices wrote:

> "John_H" <newsgroup@johnhandwork.com> wrote in message
> news:13a9hnjl693afc@corp.supernews.com...
>
>
>>>>>>>>>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.

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

"Gabor" <gabor@alacron.com> wrote in message
news:1185213106.689869.270290@m3g2000hsh.googlegro ups.com...

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

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

"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message
news:46a51c8d$1@clear.net.nz...

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

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

devices wrote:
> "Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message
> news:46a51c8d$1@clear.net.nz...
>
>> Serial EE proms, have chosen a polling system for their 'wait'
>> requirements.
>>
>>
>> -jg
>
> 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.

"John_H" <newsgroup@johnhandwork.com> wrote in message
news:minpi.2790$b04.1328@trndny06...
> devices wrote:
> > "Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message
> > news:46a51c8d$1@clear.net.nz...
> >
> >> Serial EE proms, have chosen a polling system for their 'wait'
> >> requirements.
> >>
> >>
> >> -jg
> >
> > 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

On Jul 24, 9:39 am, John_H <newsgr...@johnhandwork.com> wrote:
> devices wrote:
> > "Jim Granville" <no.s...@designtools.maps.co.nz> wrote in message
> >news:46a51c8d$1@clear.net.nz...
>
> >> Serial EE proms, have chosen a polling system for their 'wait'
> >> requirements.
>
> >> -jg
>
> > 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.


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.

Gabor wrote:
> On Jul 24, 9:39 am, John_H <newsgr...@johnhandwork.com> wrote:
>
>>devices wrote:
>>>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.
>
>
>
> 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

"Gabor" <gabor@alacron.com> wrote in message
news:1185308366.265115.156820@m3g2000hsh.googlegro ups.com...
> On Jul 24, 9:39 am, John_H <newsgr...@johnhandwork.com> wrote:
>> devices wrote:
>> > "Jim Granville" <no.s...@designtools.maps.co.nz> wrote in message
>> >news:46a51c8d$1@clear.net.nz...
>>
>> >> Serial EE proms, have chosen a polling system for their 'wait'
>> >> requirements.
>>
>> >> -jg
>>
>> > 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.
>
>
> 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.

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.

On Jul 24, 6:02 pm, "John_H" <newsgr...@johnhandwork.com> wrote:
> "Gabor" <ga...@alacron.com> wrote in message
>
> news:1185308366.265115.156820@m3g2000hsh.googlegro ups.com...
>
>
>
> > On Jul 24, 9:39 am, John_H <newsgr...@johnhandwork.com> wrote:
> >> devices wrote:
> >> > "Jim Granville" <no.s...@designtools.maps.co.nz> wrote in message
> >> >news:46a51c8d$1@clear.net.nz...
>
> >> >> Serial EE proms, have chosen a polling system for their 'wait'
> >> >> requirements.
>
> >> >> -jg
>
> >> > 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.
>
> > 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.
>
> 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:

http://www.semiconductors.philips.co...ing/index.html

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)?

"Gabor" <gabor@alacron.com> wrote in message
news:1185389927.265918.274300@o61g2000hsh.googlegr oups.com...
>
> O.K. I went to NXP.com and found a link to this page:
>
> http://www.semiconductors.philips.co...ing/index.html
>
> 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.