piclist 2001\03\14\165325a >
Thread: I2C pullups
www.piclist.com/techref/i2cs.htm?key=i2c
flavicon
face BY : Mike Mansheim email (remove spam text)



>> I must disagree.  A slave on the i2c bus can also drive SCL low (clock
>> stretching) - so if you actually drive SCL high with the master, and
>> the slave drives SCL low, you've got a short.

> I'm relatively certain that slaves do NOT drive SCL, mainly because if
> you had a locked up slave holding SCL low it would prevent ANY
> communication on the bus. Slaves can of course drive SDA. Slaves tell the
> master that something went wrong by holding SDA low.

Copied verbatim from the Phillips i2c bus specification .pdf file:

"8.3 Use of the clock synchronizing mechanism as a handshake

In addition to being used during the arbitration procedure, the clock
synchronization mechanism can be used to enable receivers to cope with
fast data transfers, on either a byte level or a bit level.

On the byte level, a device may be able to receive bytes of data at a
fast rate, but needs more time to store a received byte or prepare
another byte to be transmitted. Slaves can then hold the SCL line LOW
after reception and acknowledgment of a byte to force the master into a
wait state until the slave is ready for the next byte transfer in a type
of handshake procedure (see Fig.6).

On the bit level, a device such as a microcontroller with or without
limited hardware for the I2C-bus, can slow down the bus clock by
extending each clock LOW period. The speed of any master is thereby
adapted to the internal operating rate of this device.

In Hs-mode, this handshake feature can only be used on byte level
(see Section 13)."

I've reversed the order that the information appears in the spec, so
the above makes more sense in light of a discussion earlier in this
section:

"8.1 Synchronization

All masters generate their own clock on the SCL line to transfer messages
on the I2C-bus. Data is only valid during the HIGH period of the clock.
A defined clock is therefore needed for the bit-by-bit arbitration
procedure to take place.

Clock synchronization is performed using the wired-AND connection of I2C
interfaces to the SCL line. This means that a HIGH to LOW transition on
the SCL line will cause the devices concerned to start counting off their
LOW period and, once a device clock has gone LOW, it will hold the SCL
line in that state until the clock HIGH state is reached (see Fig.8).
However, the LOW to HIGH transition of this clock may not change the state
of the SCL line if another clock is still within its LOW period. The SCL
line will therefore be held LOW by the device with the longest LOW
period. Devices with shorter LOW periods enter a HIGH wait-state during
this time.

When all devices concerned have counted off their LOW period, the clock
line will be released and go HIGH. There will then be no difference
between the device clocks and the state of the SCL line, and all the
devices will start counting their HIGH periods. The first device to
complete its HIGH period will again pull the SCL line LOW.  In this way,
a synchronized SCL clock is generated with its LOW period determined by
the device with the longest clock LOW period, and its HIGH period
determined by the one with the shortest clock HIGH period."

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


<OFEA56B073.485ECFB6-ON86256A0F.00764885@graco.com>

See also: www.piclist.com/techref/i2cs.htm?key=i2c
Reply You must be a member of the piclist mailing list (not only a www.piclist.com member) to post to the piclist. This form requires JavaScript and a browser/email client that can handle form mailto: posts.
Subject (change) I2C pullups

month overview.

new search...