No exact or substring matches. trying for part
PICList
Thread
'[PICLIST] I2C pullups'
2001\03\13@223007
by
Glenn Mitchell
Hello. I am looking at the datasheets for 24LC32 and 24LC256 EEPROMS. The
datasheets state the SDA line needs to be pulled up. No mention of using a
pullup on SCL. Then in Serial PIC'n it says pullups are required on both
lines. Which is correct? Thanks for any help.
Glenn Mitchell.
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
2001\03\13@224024
by
David Duffy
Glenn wrote:
>Hello. I am looking at the datasheets for 24LC32 and 24LC256 EEPROMS. The
>datasheets state the SDA line needs to be pulled up. No mention of using a
>pullup on SCL. Then in Serial PIC'n it says pullups are required on both
>lines. Which is correct? Thanks for any help.
Yes, you always need a pullup on the SDA line. (4K7 or 2K2)
If the master (which always drives SCL) tri-states the SCL line
then you do need the pullup on SCL. If you only have one master
in your setup and it actually swings hi-lo then you don't need it.
Regards...
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
2001\03\13@224434
by
Rick Mann
on 3/13/01 7:28 PM, Glenn Mitchell at spam_OUTgmitchTakeThisOuT
101FREEWAY.COM wrote:
> Hello. I am looking at the datasheets for 24LC32 and 24LC256 EEPROMS. The
> datasheets state the SDA line needs to be pulled up. No mention of using a
> pullup on SCL. Then in Serial PIC'n it says pullups are required on both
> lines. Which is correct? Thanks for any help.
Both lines require pullups. You might want to check the Phillips
Semiconductor I2C specification. It's downloadable free from their website,
but I don't remember the exact location.
------------------------------------------------------------
Roderick Mann .....rmannKILLspam
@spam@latencyzero.com.sansspam
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
2001\03\13@235656
by
Herbert Graf
> Hello. I am looking at the datasheets for 24LC32 and 24LC256
> EEPROMS. The
> datasheets state the SDA line needs to be pulled up. No mention
> of using a
> pullup on SCL. Then in Serial PIC'n it says pullups are required on both
> lines. Which is correct? Thanks for any help.
It depends on you're masters. If you only have one master and that
master can only be used in a one master environment (ie. a PIC which never
selects it's SCL as an input) then it is possible that you will never need a
pullup on SCL. However, to be safe I recommend putting one on the line
anyways. The value depends on what kind of devices and distances are
involved. TTYL
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
'[PICLIST] [PIC] Re: I2C pullups'
2001\03\14@014547
by
Glenn Mitchell
Sorry, I forgot the [PIC] tag on this. The master is an 16F876 and it the
only master. The distances are just board level. If there is not a problem
leaving the pullup on SCL then I will leave it. I am guessing there is a
problem with the code. There's not a lot of examples of hardware I2C to
EEPROM.. I also saw something in the archives about adding capacitance to
the lines. Anything on this? Thanks.
Glenn Mitchell.
{Original Message removed}
2001\03\14@040846
by
Roland Andrag
Glen, the newest 17C756 datasheet shows this nicely (search for pull-up in
the document, you will find it eventually). Basically capacitance can be
added to the lines in combination with small series resistors to each
device. This makes the line less prone to interference. If I remember
correctly, the datasheet says something like 10 pF to 400 pF on each line.
Roland
{Original Message removed}
'[PICLIST] I2C pullups'
2001\03\14@154908
by
Mike Mansheim
|
>> Hello. I am looking at the datasheets for 24LC32 and 24LC256 EEPROMS.
>> The datasheets state the SDA line needs to be pulled up. No mention of
>> using a pullup on SCL. Then in Serial PIC'n it says pullups are
>> required on both lines. Which is correct? Thanks for any help.
> If the master (which always drives SCL) tri-states the SCL line
> then you do need the pullup on SCL. If you only have one master
> in your setup and it actually swings hi-lo then you don't need it.
> It depends on you're masters. If you only have one master and that
> master can only be used in a one master environment (ie. a PIC which
> never selects it's SCL as an input) then it is possible that you will
> never need a pullup on SCL.
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. Perhaps these particular
devices never do this - I don't know - but they are allowed to by the i2c
spec. So to have a standard i2c interface, you need pullups on both SDA
and SCL, and the only way you make either high is to set it as an input
and let the pullup float it high.
--
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
2001\03\14@161553
by
Herbert Graf
|
{Quote hidden}> >> Hello. I am looking at the datasheets for 24LC32 and 24LC256 EEPROMS.
> >> The datasheets state the SDA line needs to be pulled up. No mention of
> >> using a pullup on SCL. Then in Serial PIC'n it says pullups are
> >> required on both lines. Which is correct? Thanks for any help.
>
> > If the master (which always drives SCL) tri-states the SCL line
> > then you do need the pullup on SCL. If you only have one master
> > in your setup and it actually swings hi-lo then you don't need it.
>
> > It depends on you're masters. If you only have one master and that
> > master can only be used in a one master environment (ie. a PIC which
> > never selects it's SCL as an input) then it is possible that you will
> > never need a pullup on SCL.
>
> 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. Perhaps these particular
> devices never do this - I don't know - but they are allowed to by the i2c
> spec. So to have a standard i2c interface, you need pullups on both SDA
> and SCL, and the only way you make either high is to set it as an input
> and let the pullup float it high.
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. TTYL
--
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
2001\03\14@165122
by
Barry King
|
> 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.
By the spec, slaves MAY drive SCL low, which is called clock
stretching. The purpose is that a slow slave can hold SCL low, after
the master has released it, until the next bit is ready. The Master
must wait for the actual rising edge to know the bit is valid.
I have never seen a slave implementation that USES clock stretching
(example: EEPROMs don't) EXCEPT one that's important to us: PIC's SSP
in slave mode. As a slave, it ALWAYS pulls SCL low from the time it
recognizes its slave read address, until the first byte of the
response is loaded by the firmware.
So it you are using a PIC as a slave, follow the spec, and provide
pullups on both lines, and make sure the master is operating "open-
drain", that is, pull down when presenting a low, and float the line
and let the pull up present the high level.
> 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.
TRUE. If you write I2C slave code for a PIC, you've got to be darn
careful that you always respond to the SSPIF, even if you don't
"think" the master wants any more data now. The SSP WILL lock the
bus if you leave a slave-read (PIC slave sends data to master)
transfer unfinished.
-Barry.
------------
Barry King
NRG Systems "Measuring the Wind's Energy"
http://www.nrgsystems.com
Check out the accumulated (PIC) wisdom of the ages at:
PIC/PICList FAQ: http://www.piclist.com/faq
--
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
2001\03\14@165325
by
Mike Mansheim
|
>> 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
2001\03\14@170347
by
Andrew Warren
|
Mike Mansheim wrote:
> A slave on the i2c bus can .... 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.
and Herbert Graf <PICLIST
KILLspamMITVMA.MIT.EDU> replied:
> 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.
Herbert:
Mike's correct; once the master has driven SCL low, a slave can
hold it low. I don't think any 24Cxx serial EEPROMs do that,
but other slaves do.
> Slaves tell the master that something went wrong by holding SDA
> low.
Well, yeah... But only in the same sense that reverse-biased
electrolytic caps "tell you that something went wrong" by
exploding.
Generally speaking, I2C devices don't contain special "error
state" logic; if the bus locks up, it's usually just a natural
side-effect of the communications failure.
-Andy
=== Andrew Warren --- .....aiwKILLspam
.....cypress.com
=== IPD Systems Engineering, CYSD
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation
--
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
2001\03\14@172004
by
M. D. Miller
The details below are correct ... as a GENERAL rule, both SDA and SCL should
not be DRIVEN high, rather allowed to swing high by use of a pull-up
resistor. Having said that, however, I have seen many designs where the
master drives the SCL high and LOW. While that may work in many scenarios,
this is not to spec.
-- Mitch
{Original Message removed}
2001\03\14@172202
by
M. D. Miller
> Well, yeah... But only in the same sense that reverse-biased
> electrolytic caps "tell you that something went wrong" by
> exploding.
I love it!!
--
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
2001\03\14@231543
by
Herbert Graf
I stand corrected, forgot about clock stretching, probably because I've
never used a device that did it. TTYL
> {Original Message removed}
2001\03\14@231615
by
Herbert Graf
|
{Quote hidden}> >> 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)."
Ahh, well there it is, in HS mode there is no clock stretching, that's
why I've never seen it. TTYL
{Quote hidden}> 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
>
>
>
--
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
2001\03\15@044712
by
mike
|
On Wed, 14 Mar 2001 14:45:03 -0600, you wrote:
{Quote hidden}>>> Hello. I am looking at the datasheets for 24LC32 and 24LC256 EEPROMS.
>>> The datasheets state the SDA line needs to be pulled up. No mention of
>>> using a pullup on SCL. Then in Serial PIC'n it says pullups are
>>> required on both lines. Which is correct? Thanks for any help.
>
>> If the master (which always drives SCL) tri-states the SCL line
>> then you do need the pullup on SCL. If you only have one master
>> in your setup and it actually swings hi-lo then you don't need it.
>
>> It depends on you're masters. If you only have one master and that
>> master can only be used in a one master environment (ie. a PIC which
>> never selects it's SCL as an input) then it is possible that you will
>> never need a pullup on SCL.
>
>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. Perhaps these particular
>devices never do this - I don't know - but they are allowed to by the i2c
>spec. So to have a standard i2c interface, you need pullups on both SDA
>and SCL, and the only way you make either high is to set it as an input
>and let the pullup float it high.
Although the spec allows for it, I have never encountered a device
which does this. EEProms certainly never do. In practice you shouldn't worry about driving SCL both ways and
omitting the pullup unless the slave device datasheet says it uses
clock stretching. If a device _did_ use clock stretching, you would have to adapt the
code as well to cope with it.
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2001\03\15@065303
by
Roman Black
|
Mike, I have a question, hope you can help! :o)
I am just finishing off a board design using a
16F876 talking to 24LC256 eeprom.
I am using the PIC MSSP outputs for clk and data,
do these go open drain? Must they have pullup
resistors? I wanted to keep the option of using
bit-banging I2C (not the MSSP module) and in this
mode the data and clk will be normal PIC output
pins.
So do I read you right that I need 2 pullup
resistors, AND also 2 pass resistors to stop
problems when the PIC pins go high and the eeprom
pins may hold low?? I really don't want to switch
the PIC pins from outputs to inputs at high
frequencies. I prefer to leave them always as
outputs, at least the clk pin.
Thanks,
-Roman
Mike Harrison wrote:
{Quote hidden}> >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. Perhaps these particular
> >devices never do this - I don't know - but they are allowed to by the i2c
> >spec. So to have a standard i2c interface, you need pullups on both SDA
> >and SCL, and the only way you make either high is to set it as an input
> >and let the pullup float it high.
> Although the spec allows for it, I have never encountered a device
> which does this. EEProms certainly never do.
> In practice you shouldn't worry about driving SCL both ways and
> omitting the pullup unless the slave device datasheet says it uses
> clock stretching.
> If a device _did_ use clock stretching, you would have to adapt the
> code as well to cope with it.
>
>
> --
>
http://www.piclist.com hint: The PICList is archived three different
> ways. See
http://www.piclist.com/#archives for details.
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2001\03\15@082640
by
mike
|
On Thu, 15 Mar 2001 22:52:47 +1100, you wrote:
>Mike, I have a question, hope you can help! :o)
>I am just finishing off a board design using a
>16F876 talking to 24LC256 eeprom.
>I am using the PIC MSSP outputs for clk and data,
>do these go open drain? I have no direct experience of using the on-board I2C module, but the
datasheet shows that it uses the pins as open-drain to be able to
implement the full spec for the devices that need it, so you'd need
both pullups.
>Must they have pullup
>resistors? I wanted to keep the option of using
>bit-banging I2C (not the MSSP module) and in this
>mode the data and clk will be normal PIC output
>pins.
If you're bit-banging and driving SCL fully, you don't need the
pullup. Yuu always need an SDA pullup.
>So do I read you right that I need 2 pullup
>resistors, AND also 2 pass resistors to stop
>problems when the PIC pins go high and the eeprom
>pins may hold low??
No - you never need series resistors. If you have slave devices which
can stretch the clock, you use a pullup and drive it open-drain.
> I really don't want to switch
>the PIC pins from outputs to inputs at high
>frequencies. I prefer to leave them always as
>outputs, at least the clk pin.
You will always have to switch SDA in/out to fake an open-drain
output. Unless you implement clock-stretching you can keep SCL as an
output all the time.
To summarise, If you're just talking to an eeprom, you don't need an
SCL pullup if bit-bashing, but would if using the MSSP. I'd allow for
an SCL pullup on the PCB - it won't hurt if you don't use it but would
be a pain to add later if you decided to use the MSSP!
{Quote hidden}>Thanks,
>-Roman
>
>
>
>Mike Harrison wrote:
>
>> >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. Perhaps these particular
>> >devices never do this - I don't know - but they are allowed to by the i2c
>> >spec. So to have a standard i2c interface, you need pullups on both SDA
>> >and SCL, and the only way you make either high is to set it as an input
>> >and let the pullup float it high.
>> Although the spec allows for it, I have never encountered a device
>> which does this. EEProms certainly never do.
>> In practice you shouldn't worry about driving SCL both ways and
>> omitting the pullup unless the slave device datasheet says it uses
>> clock stretching.
>> If a device _did_ use clock stretching, you would have to adapt the
>> code as well to cope with it.
>>
>>
>> --
>>
http://www.piclist.com hint: The PICList is archived three different
>> ways. See
http://www.piclist.com/#archives for details.
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2001\03\15@114954
by
Mike Mansheim
> ... I really don't want to switch
> the PIC pins from outputs to inputs at high
> frequencies. I prefer to leave them always as
> outputs, at least the clk pin.
I get the feeling this is a general rule of thumb amongst veteran pic
users. If anyone feels like discussing it, I'd like to learn why!
Also, is the high frequency in this case your i2c bus frequency?
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2001\03\15@172252
by
M. D. Miller
|
Roman,
> So do I read you right that I need 2 pullup
> resistors, AND also 2 pass resistors to stop
> problems when the PIC pins go high and the eeprom
> pins may hold low?? I really don't want to switch
> the PIC pins from outputs to inputs at high
> frequencies. I prefer to leave them always as
> outputs, at least the clk pin.
In my designs, I have always switched from I to O and back as needed. Set
the pin to I for a logic 1, and to O (that's an O for output, not a zero) to
drive the pin low. At the same time, I also make sure that the
corresponding bit is low so it drives the pin low (as opposed to
accidentally driving it high when low was intended). That's according to
spec, but have seen lots o' designs which drive SCL both directions. Also,
my designs are all bit-banged I2C, not using an MSSP. If their devices are
following the spec, they should never be driving the line high, either, and
therefore you wouldn't need the current limiting resistors, just the
pull-up's.
-- Mitch
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2001\03\15@195751
by
Bob Ammerman
I see no problems with setting/clearing bits in the TRIS register to toggle
an output between a driven zero and "open drain". This doesn't even have the
read-modify-write problem that a normal reference to a bit in the PORT
register has.
Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)
{Original Message removed}
2001\03\16@075847
by
Roman Black
|
Mike Mansheim wrote:
>
> > ... I really don't want to switch
> > the PIC pins from outputs to inputs at high
> > frequencies. I prefer to leave them always as
> > outputs, at least the clk pin.
>
> I get the feeling this is a general rule of thumb amongst veteran pic
> users. If anyone feels like discussing it, I'd like to learn why!
> Also, is the high frequency in this case your i2c bus frequency?
Yes the high frequency is the I2C bus frequency.
I don't like changing from in to outs as I am a
hardware guy. I like to design the input and output
circuits as best as I can and that means making them
dedicated with whatever capacitance and filtering
is best for their exact purpose.
Changing them from out to in means they go from
being held at a steady voltage to going high impedance,
floating if you like. The rare times I do this I
prefer to change from output to input, wait for
a settling time, then use as an input. I'm just a
fussy hardware guy that likes to design stuff that
leaves no failure "grey areas".
In this case I do need to change from out to in
to sense the ack signal from the eeprom slave, so
I will do this only when it is required and actively
drive the SDA for all other data.
Many guys who know PICs much better than me always
design stuff to constantly switch between inputs and
outputs. Must be a personality thing?? I just like
the least possible things that can go wrong. ;o)
-Roman
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUT
TakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body
'[PIC]: Switching INPUTS<->OUTPUTS (was I2C pullups'
2001\03\16@081126
by
Bob Ammerman
|
Roman,
You said:
> I don't like changing from in to outs as I am a
> hardware guy. I like to design the input and output
> circuits as best as I can and that means making them
> dedicated with whatever capacitance and filtering
> is best for their exact purpose.
and also:
> Many guys who know PICs much better than me always
> design stuff to constantly switch between inputs and
> outputs. Must be a personality thing?? I just like
> the least possible things that can go wrong. ;o)
Well, I certainly don't think I know PICs much better than you, and I
emphatically don't know as much electronics as you do, but....
If you look at the pin circuit inside the PIC, as described in the data
sheet, you can see exactly what is happening when you set the TRIS bit for a
pin: specifically neither the pull-up or pull-down FET can be turned on.
There is no 'magic' here, and everything is well defined. Why are you
uncomfortable using this capability to simulate an open-drain?
What possible things do you see that can go wrong?
Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv
spam_OUTmitvma.mit.edu with SET PICList DIGEST in the body
'[PIC]: I2C pullups'
2001\03\16@081338
by
Roman Black
Bob Ammerman wrote:
>
> I see no problems with setting/clearing bits in the TRIS register to toggle
> an output between a driven zero and "open drain". This doesn't even have the
> read-modify-write problem that a normal reference to a bit in the PORT
> register has.
Thanks Bob. :o)
-Roman
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspam
mitvma.mit.edu with SET PICList DIGEST in the body
2001\03\16@081523
by
Roman Black
|
Thanks Mitch. I think i have settled on only
switching to input for the ack wait period.
I am sending blocks of 32 bytes, so my plan
is to just drive SDA from the PIC using
bit-banging and then switch to input for
the ack. Its the simplest way i think. :o)
-Roman
M. D. Miller wrote:
{Quote hidden}>
> Roman,
>
> > So do I read you right that I need 2 pullup
> > resistors, AND also 2 pass resistors to stop
> > problems when the PIC pins go high and the eeprom
> > pins may hold low?? I really don't want to switch
> > the PIC pins from outputs to inputs at high
> > frequencies. I prefer to leave them always as
> > outputs, at least the clk pin.
>
> In my designs, I have always switched from I to O and back as needed. Set
> the pin to I for a logic 1, and to O (that's an O for output, not a zero) to
> drive the pin low. At the same time, I also make sure that the
> corresponding bit is low so it drives the pin low (as opposed to
> accidentally driving it high when low was intended). That's according to
> spec, but have seen lots o' designs which drive SCL both directions. Also,
> my designs are all bit-banged I2C, not using an MSSP. If their devices are
> following the spec, they should never be driving the line high, either, and
> therefore you wouldn't need the current limiting resistors, just the
> pull-up's.
>
> -- Mitch
>
> --
>
http://www.piclist.com hint: The PICList is archived three different
> ways. See
http://www.piclist.com/#archives for details.
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspam
mitvma.mit.edu with SET PICList DIGEST in the body
'[PIC]: Switching INPUTS<->OUTPUTS (was I2C pullups'
2001\03\16@085018
by
Roman Black
|
Bob Ammerman wrote:
{Quote hidden}>
> Roman,
>
> You said:
>
> > I don't like changing from in to outs as I am a
> > hardware guy. I like to design the input and output
> > circuits as best as I can and that means making them
> > dedicated with whatever capacitance and filtering
> > is best for their exact purpose.
>
> and also:
>
> > Many guys who know PICs much better than me always
> > design stuff to constantly switch between inputs and
> > outputs. Must be a personality thing?? I just like
> > the least possible things that can go wrong. ;o)
>
> Well, I certainly don't think I know PICs much better than you, and I
> emphatically don't know as much electronics as you do, but....
>
> If you look at the pin circuit inside the PIC, as described in the data
> sheet, you can see exactly what is happening when you set the TRIS bit for a
> pin: specifically neither the pull-up or pull-down FET can be turned on.
>
> There is no 'magic' here, and everything is well defined. Why are you
> uncomfortable using this capability to simulate an open-drain?
>
> What possible things do you see that can go wrong?
It's not really the inside of the PIC that scares
me, more the external hardware. Most of my inputs
have RC filtering or such, and many of my outputs
are very specific again with high loads or PWM
RC networks etc.
Just a general attitude that I like to make inputs
be inputs and outputs should be outputs. I do make
use of the RC analog converter trick, pulling a cap
low and then switching pin to input and then timing
how long it takes to charge, but I also use dead
periods in software before I start checking the input
and if I'm being extra paranoid I even write to the
TRIS register twice.
Possible problems:
* Read/mod/write does exist with tris change, imagine
a capacitive load at 5v, you change to an input, input
pin reads 5v, it may take microseconds before that
capacitive load drops to the proper 0v of the actual
input signal. A port read reads the pin, the pin
voltage can be very affected by external circuitry.
Hence a settling delay in software is nice.
* Switching an output to input may cause the ouptut
load to turn on/off. This could cause power or inductive
spike depending on load type, causing cmos register
corruption, etc. I like to bring the port output to a
known "safe" condition before swithing to an input,
and I often write to TRIS, wait a nop or two and write
to TRIS again. Just in case. Little cost, little
probability but high consequence. :o)
So i'm paranoid and a safety nut! Pretty funny that I
get real safe and conservative about my hardware, then
on weekends jump on a 150hp motorcycle and blast around
a racetrack. Maybe it's a yin/yang balance thing?? ;o)
-Roman
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuT
mitvma.mit.edu with SET PICList DIGEST in the body
'[PIC]: I2C pullups'
2001\03\16@124025
by
rottosen
Roman Black wrote:
>
> Thanks Mitch. I think i have settled on only
> switching to input for the ack wait period.
> I am sending blocks of 32 bytes, so my plan
> is to just drive SDA from the PIC using
> bit-banging and then switch to input for
> the ack. Its the simplest way i think. :o)
> -Roman
Roman:
I haven't doe I2C for a while but I wonder if you can do what you say
and still meet the I2C protocal requirements.
-- Rich
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGone
mitvma.mit.edu with SET PICList DIGEST in the body
2001\03\16@140628
by
mike
|
On Fri, 16 Mar 2001 23:59:12 +1100, you wrote:
{Quote hidden}>Mike Mansheim wrote:
>>
>> > ... I really don't want to switch
>> > the PIC pins from outputs to inputs at high
>> > frequencies. I prefer to leave them always as
>> > outputs, at least the clk pin.
>>
>> I get the feeling this is a general rule of thumb amongst veteran pic
>> users. If anyone feels like discussing it, I'd like to learn why!
>> Also, is the high frequency in this case your i2c bus frequency?
>
>
>Yes the high frequency is the I2C bus frequency.
>I don't like changing from in to outs as I am a
>hardware guy. I like to design the input and output
>circuits as best as I can and that means making them
>dedicated with whatever capacitance and filtering
>is best for their exact purpose.
>
>Changing them from out to in means they go from
>being held at a steady voltage to going high impedance,
>floating if you like. No they don't as there is an external pullup.
>Many guys who know PICs much better than me always
>design stuff to constantly switch between inputs and
>outputs. Must be a personality thing?? I just like
>the least possible things that can go wrong. ;o)
If it makes you feel happier, think of it as not so much switching
from input to output as enabling a pull-down to create an effectively
open-drain signal.
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservEraseME
spam_OUTmitvma.mit.edu with SET PICList DIGEST in the body
2001\03\16@154830
by
Drew Vassallo
>Thanks Mitch. I think i have settled on only
>switching to input for the ack wait period.
>I am sending blocks of 32 bytes, so my plan
>is to just drive SDA from the PIC using
>bit-banging and then switch to input for
>the ack. Its the simplest way i think. :o)
Sorry to enter the discussion so late, but I second Bob's recommendation
that the TRIS toggling method is safe. I've got it running at 20MHz
clearing/setting the TRIS bits to simulate open-drain operation without a
single glitch. Actually, I would feel less comfortable in driving the
signals directly due to the bus contention in the case of the slave holding
the clock low.
--Andrew
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistserv
TakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body
2001\03\17@003823
by
Roman Black
|
Richard Ottosen wrote:
>
> Roman Black wrote:
> >
> > Thanks Mitch. I think i have settled on only
> > switching to input for the ack wait period.
> > I am sending blocks of 32 bytes, so my plan
> > is to just drive SDA from the PIC using
> > bit-banging and then switch to input for
> > the ack. Its the simplest way i think. :o)
> > -Roman
>
> Roman:
> I haven't doe I2C for a while but I wonder if you can do what you say
> and still meet the I2C protocal requirements.
Hi Rich. I have read the eeprom datasheet pretty
thoroughly and this should work with this particular
eeprom chip. I'm not trying to get a "proper"
universal I2C bus going.
The eeprom datasheet says "the master must release
the SDA line at this point to allow the slave to
generate an ack" which seems to imply to me that
the entire 32byte block can be sent without
releasing the SDA, then just release it for the ack.
:o)
-Roman
--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestEraseME
.....mitvma.mit.edu
2001\03\17@005100
by
Roman Black
Drew Vassallo wrote:
>
> >Thanks Mitch. I think i have settled on only
> >switching to input for the ack wait period.
> >I am sending blocks of 32 bytes, so my plan
> >is to just drive SDA from the PIC using
> >bit-banging and then switch to input for
> >the ack. Its the simplest way i think. :o)
>
> Sorry to enter the discussion so late, but I second Bob's recommendation
> that the TRIS toggling method is safe. I've got it running at 20MHz
> clearing/setting the TRIS bits to simulate open-drain operation without a
> single glitch. Actually, I would feel less comfortable in driving the
> signals directly due to the bus contention in the case of the slave holding
> the clock low.
Ok guys, i'm bending to your way now. :o)
My bit rate is slow anyway, about 7500Hz.
-Roman
--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-request
mitvma.mit.edu
2001\03\17@121617
by
rottosen
|
Roman Black wrote:
{Quote hidden}>
> Richard Ottosen wrote:
> >
> > Roman Black wrote:
> > >
> > > Thanks Mitch. I think i have settled on only
> > > switching to input for the ack wait period.
> > > I am sending blocks of 32 bytes, so my plan
> > > is to just drive SDA from the PIC using
> > > bit-banging and then switch to input for
> > > the ack. Its the simplest way i think. :o)
> > > -Roman
> >
> > Roman:
> > I haven't doe I2C for a while but I wonder if you can do what you say
> > and still meet the I2C protocal requirements.
>
> Hi Rich. I have read the eeprom datasheet pretty
> thoroughly and this should work with this particular
> eeprom chip. I'm not trying to get a "proper"
> universal I2C bus going.
>
> The eeprom datasheet says "the master must release
> the SDA line at this point to allow the slave to
> generate an ack" which seems to imply to me that
> the entire 32byte block can be sent without
> releasing the SDA, then just release it for the ack.
> :o)
> -Roman
>
When you put it that way, it does make it sound OK. :-)
I do, however, vote for using the TRIS register to do an open drain
output. As mentioned by others, speed of read/modify/writes does not
apply to the internal register since there is no unknown capacitive load
on the TRIS register "pin".
-- Rich
> --
> http://www.piclist.com hint: To leave the PICList
> RemoveMEpiclist-unsubscribe-requestEraseME
EraseMEmitvma.mit.edu
--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspam_OUT
KILLspammitvma.mit.edu
2001\03\17@125623
by
Roman Black
|
Richard Ottosen wrote:
> > The eeprom datasheet says "the master must release
> > the SDA line at this point to allow the slave to
> > generate an ack" which seems to imply to me that
> > the entire 32byte block can be sent without
> > releasing the SDA, then just release it for the ack.
> >:o)
> > -Roman
> >
>
> When you put it that way, it does make it sound OK. :-)
>
> I do, however, vote for using the TRIS register to do an open drain
> output. As mentioned by others, speed of read/modify/writes does not
> apply to the internal register since there is no unknown capacitive load
> on the TRIS register "pin".
Yep. I think I have been swayed to this method
by quite a few posts, thank you Richard and also
thanks to everyone who offered advice.
Seems the possible problems of conflicting high/low
on the I2C SDA line is greater than the possible
problems from switching the pin from output to
input with every bit.
In a perfect world I would use a series resistor
AND pullup resistor, and just change to input for
checking the ACK. But my board is so full it already
has no room and is costing us extra for hole density
per square inch.
It's a small board with LOTS of air... :o)
-Roman
--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuT
spammitvma.mit.edu
2001\03\17@162344
by
briang
2001\03\19@043443
by
Kevin Blain
When you TRIS a pin as input, then read it, does that not put a logic 1 in
the PORT register if the pin is pulled up? If so, when the pin is TRIS'd to
output again, it will be outputting logic 1.??
Therefore, care should be taken when doing I2C in this method to make sure
that the pin is set to output 0 whenever you tris back to an output.
Regards, Kevin.
--
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
2001\03\19@050018
by
Michael Rigby-Jones
|
> -----Original Message-----
> From: Kevin Blain [SMTP:KILLspamkevinbspamBeGone
WOODANDDOUGLAS.CO.UK]
> Sent: Monday, March 19, 2001 9:24 AM
> To: EraseMEPICLIST
EraseMEMITVMA.MIT.EDU
> Subject: Re: [PIC]: I2C pullups
>
> When you TRIS a pin as input, then read it, does that not put a logic 1 in
> the PORT register if the pin is pulled up? If so, when the pin is TRIS'd
> to
> output again, it will be outputting logic 1.??
>
The port latch is only changed if a Write or Read Modify Write instruction
is executed on the port. So if a pin is set as an input, and then a BSF/BCF
etc is performed on the port, the port latch for that pin will be set to
whatever state the pin is at. This won't happen by simply reading the state
of the port however.
Regards
Mike
{Quote hidden}> Therefore, care should be taken when doing I2C in this method to make sure
> that the pin is set to output 0 whenever you tris back to an output.
>
> Regards, Kevin.
>
> --
>
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
>
>
--
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
2001\03\19@053411
by
Kevin Blain
2001\03\19@061227
by
David Duffy
|
Kevin wrote:
>When you TRIS a pin as input, then read it, does that not put a logic 1 in
>the PORT register if the pin is pulled up? If so, when the pin is TRIS'd to
>output again, it will be outputting logic 1.??
>
>Therefore, care should be taken when doing I2C in this method to make sure
>that the pin is set to output 0 whenever you tris back to an output.
As an aside, when doing open-collector code I clear the port pin just before
I change it to output. Just to sure that the pin will be low when I need it
to be!
Helps to avoid having a nasty level collision on a OR'd bus line.
Regards...
___________________________________________
David Duffy Audio Visual Devices P/L
U8, 9-11 Trade St, Cleveland 4163 Australia
Ph: +61 7 38210362 Fax: +61 7 38210281
New Web: http://www.audiovisualdevices.com.au
New email: .....avdspam_OUT
audiovisualdevices.com.au
___________________________________________
--
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
2001\03\19@085413
by
Drew Vassallo
>Therefore, care should be taken when doing I2C in this method to make sure
>that the pin is set to output 0 whenever you tris back to an output.
Also, don't overlook the fact that whenever ANY bit operation is done on ANY
pin on the same port that you've got the I2C, you have to reset the latch to
zero before you use your I2C routines again. Note that this applies to
interrupt routines as well.
--Andrew
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
--
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
2001\03\19@085637
by
Drew Vassallo
>>Therefore, care should be taken when doing I2C in this method to make sure
>>that the pin is set to output 0 whenever you tris back to an output.
>
>As an aside, when doing open-collector code I clear the port pin just
>before
>I change it to output. Just to sure that the pin will be low when I need it
>to be!
>Helps to avoid having a nasty level collision on a OR'd bus line.
>Regards...
I would be careful using this method of resetting the latches, because this
won't work if you have ISR's that access the port pins. You have to reset
the latch inside the ISR, not just before you tris the pin.
--Andrew
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
--
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
2001\03\19@092404
by
mike
|
On Mon, 19 Mar 2001 09:23:35 -0000, you wrote:
>When you TRIS a pin as input, then read it, does that not put a logic 1 in
>the PORT register if the pin is pulled up? If so, when the pin is TRIS'd to
>output again, it will be outputting logic 1.??
No. However if you do a read-modify write (bsf,bcf) on another pin on the
port (e.g. SCL), and the input is pulled high externally. this WILL
rewrite the output register with a 1, so you do need to be careful. If
in doubt use a BCF or explicit zero write on the pin before turning it
back to an output. BCF is ok on the pin in question as it will ignore
the previous state, but this is not a good idea if there are other
input pins on the port whose output ports you don't want to change.
This is actually another argument for not using open-drain on SCL, so
you don't have to worry about messing up SCL when SDA changes!
>Therefore, care should be taken when doing I2C in this method to make sure
>that the pin is set to output 0 whenever you tris back to an output.
Exactly.
--
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
'[PIC] I2C pullups?'
2011\01\13@153516
by
PICdude
I'm looking at figure 22-2 in the 16F1936 datasheet (MSSP block diagram - I2C Master Mode), and I see nothing internal to the chip that would pull that line high, so that suggests that a pull-up resistor would be required. (It's an open drain output, with no pull up).
Previously I was using a PIC16F877A which shows a buffer at that output pin, and I've never used a pull-up resistor on that line (only on the SDA line), to interface to a serial EEPROM. So I'm assuming I need a pull-up resistor for the 16F1936's SCL line now. How do I go about calculating the value of said resistor? The datasheet says nothing about it other than for SPI mode, "External pull-up/pull-down resistors may be desirable depending on the application."
Thanks,
-Neil.
2011\01\13@160852
by
Olin Lathrop
PICdude wrote:
> I'm looking at figure 22-2 in the 16F1936 datasheet (MSSP block
> diagram - I2C Master Mode), and I see nothing internal to the chip
> that would pull that line high, so that suggests that a pull-up
> resistor would be required. (It's an open drain output, with no pull
> up).
Right. That's how IIC works. Both lines passively float high and are
pulled actively down. Sometimes that's useful as it gets around collisions
and allows multiple devices to be driving a line low, and provides a
guaranteed idle state. This comes in handy for the ACK bit, during clock
stretching, and in multi-master operation, for example.
> Previously I was using a PIC16F877A which shows a buffer at that
> output pin,
I'm not sure what you mean by "shows a buffer". Of course all PIC outputs
have drivers (buffers) for that purpose. These are enabled when the PIC is
driving the pin, as apposed to it being a input. A few PIC pins are open
drain, meaning the "buffer" is only a low side, not high/low driver. Some
PIC pins, including a few on the 16F877A have passive pullups built in.
These are usually too high impedence for making a good IIC bus, and don't
come on by themselves just because you're using the pin for IIC.
> and I've never used a pull-up resistor on that line (only
> on the SDA line), to interface to a serial EEPROM.
Wow, either you got very lucky or there is really a pullup lurking
somewhere. Maybe you are using a pin with a weak internal pullup and it's
on and you don't realize it.
> So I'm assuming I
> need a pull-up resistor for the 16F1936's SCL line now. How do I go
> about calculating the value of said resistor?
Ohms = volts / amps
For example, if your system is using a 3.3V supply, then
Ohms = 3.3V / 3mA = 1.1K Ohms
That would be the minimum allowed pullup without exceeding the IIC spec.
You want to be a little higher for safe margin, but not too much. 1.2K Ohms
would be good if you want to go as fast as possible, otherwise 1.5K Ohms
would be nice and safe with plenty of margin. Higher values are possible if
you can guarantee to go slowly. However, higher values don't represent much
of a power savings since the bits will have to be longer to compensate for
the lower pullup current and the resulting longer slew times. Higher
pullups also leave you open for more noise coupling.
********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014. Gold level PIC consultants since 2000
2011\01\13@164013
by
jim
|
Neil,
Depending on the capacitance of the load (up to 200pf or so), you want
the pullup current to be between 3
and 12 ma generally. Obviously, the higher the current, the faster you
can go, but you'll also use more
power. So, unless this application is a really speed sensitive, don't
care about power type, stay at the
lower end of the renge. I have had good luck with resistors between
about 1.2K and 10K. Generally, I use
4.7K as a rule. But the I2C comms I carry out aren't seepd sensitive
meaning I don't have to talk fast. Just reliably.
But, to stay within the I2C spec, you'll want at least 3ma of pullup
current. With a 4.7K ohm resistor and 5v parts, you're talking about ~1ma, which isn't even close to being in
spec. However, as I mentioned above, my applications use relatively slow comm rates, so I can get by
with the lower current.
The final choice is your. You could experiment to see what works best
for you. But the spec calls for a
pullup current of between 3 and 12ma. This equates to a resistance of
between about 1.66K (3ma) to about 416 ohms (12ma).
Regards,
Jim
> ---{Original Message removed}
2011\01\13@171926
by
Olin Lathrop
jim@jpes.com wrote:
> Depending on the capacitance of the load (up to 200pf or so), you
> want the pullup current to be between 3 and 12 ma generally.
Don't listen to this folks, it's just plain wrong.
Standard IIC nodes are only required to provide a minimum of 3mA pulldown
current to get to a logic low (The optional "fast" IIC bus specs requires up
to 6mA pulldown capability). This means pullup current must be less than or
equal to 3mA at logic low, not greater than 3mA. The supply voltage and the
3mA spec therefore define a *minimum* value pullup resistor.
> Obviously, the higher the current, the faster
> you can go,
Yes.
> but you'll also use more power.
Not necessarily. Bus idle takes no power regardless of the pullup value.
All the power is spent holding the bus lines low. The time spent low for a
fixed message is inversely proportional to the bit rate. Therefore, going
faster saves power. If you halve the pullup resistors but double the speed,
the power will be about the same.
The minimum power requirement is therefore a function of the capacitive
loading, since that governs how fast you can go for a given pullup. Lower
pullup resistors give you better noise immunity from outside influences, so
there is some advantage to using lower pullups and going proportionately
faster.
> Generally, I use 4.7K as a rule.
Which is rather different than the pullup current between 3 and 12 mA you
recommended earlier. At 5V with 4.7K Ohms, you get barely over 1mA.
Fortunately that is within spec, so it's OK if you've taken your slew rate
into account and adjusted the maximum speed accordingly.
> But, to stay within the I2C spec, you'll want at least 3ma of pullup
> current.
Wrong.
> With a 4.7K ohm resistor and
> 5v parts, you're talking about ~1ma, which isn't even close to being
> in spec.
Wrong again.
> But the spec calls for a pullup current of between 3 and 12ma.
Not any IIC spec I've seen.
********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014. Gold level PIC consultants since 2000
2011\01\13@181913
by
jim
No it isn't wrong. Read the spec. For HS I2C comms, the min is 3ma
pullup current, and the max is 12ma pullup current. See the spec document 39340011, page
35.
Regards,
Jim
> ---{Original Message removed}
2011\01\14@034002
by
Wouter van Ooijen
On 14/1/2011 12:19 AM, TakeThisOuTjim.....
TakeThisOuTjpes.com wrote:
>
> No it isn't wrong. Read the spec. For HS I2C comms, the min is 3ma
> pullup current, and
> the max is 12ma pullup current. See the spec document 39340011, page
> 35.
There are indeed figures of 3 and 12 mA on that page, but it is definitely not about the current through the pullup resistors! Don't you pay any attention to the context in which a figure is mentioned??
--
Wouter van Ooijen
-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu
2011\01\14@074139
by
Olin Lathrop
jim@jpes.com wrote:
> No it isn't wrong. Read the spec.
I have, and what you said is wrong and certainly bad advice.
The spec even shows a graph of the minimum allowed pullup resistor versus
supply voltage. The document I use from Phillips (the originators of IIC)
is called "The IIC Bus and How to Use It". I have had it so long I don't
remember exactly where on the Phillips site it came from, but I put a copy
temporarily at http://www.embedinc.com/temp/iic.pdf.
> For HS I2C comms, the min is 3ma
> pullup current, and the max is 12ma pullup current.
For *HS* mode, which is certainly not the default unless you explicitly say
so. Using HS mode parameters with ordinary IIC devices (which the
discussion was about and your statement referred to) is actually out of spec
and can cause the bus not to work. Basically HS IIC is a different bus and
requires different devices and electrical parameters to IIC. The general
signalling method and the name are the same, but the electrical specs are
incompatible.
HS mode came much later. In fact, the addition of HS mode appears to be the
main difference between the document I referenced above and yours. In any
case, if you mean HS mode, you need to say so explicitly. Most devices out
there are not HS mode compliant, and recommending up to 12mA without
explaining this applies to HS mode only is wrong and will get people into
trouble.
********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014. Gold level PIC consultants since 2000
2011\01\14@102031
by
jim
|
Okay. Whatever.
Regards,
Jim
{Quote hidden}> -------- Original Message --------
> Subject: Re: [PIC] I2C pullups?
> From: "Olin Lathrop" <
TakeThisOuTolin_piclistKILLspam
spamembedinc.com>
> Date: Fri, January 14, 2011 6:42 am
> To: "Microcontroller discussion list - Public." <
.....piclist
RemoveMEmit.edu>
>
>
>
RemoveMEjim
spamBeGonejpes.com wrote:
> > No it isn't wrong. Read the spec.
>
> I have, and what you said is wrong and certainly bad advice.
>
> The spec even shows a graph of the minimum allowed pullup resistor versus
> supply voltage. The document I use from Phillips (the originators of IIC)
> is called "The IIC Bus and How to Use It". I have had it so long I don't
> remember exactly where on the Phillips site it came from, but I put a copy
> temporarily at
http://www.embedinc.com/temp/iic.pdf.
>
> > For HS I2C comms, the min is 3ma
> > pullup current, and the max is 12ma pullup current.
>
> For *HS* mode, which is certainly not the default unless you explicitly say
> so. Using HS mode parameters with ordinary IIC devices (which the
> discussion was about and your statement referred to) is actually out of spec
> and can cause the bus not to work. Basically HS IIC is a different bus and
> requires different devices and electrical parameters to IIC. The general
> signalling method and the name are the same, but the electrical specs are
> incompatible.
>
> HS mode came much later. In fact, the addition of HS mode appears to be the
> main difference between the document I referenced above and yours. In any
> case, if you mean HS mode, you need to say so explicitly. Most devices out
> there are not HS mode compliant, and recommending up to 12mA without
> explaining this applies to HS mode only is wrong and will get people into
> trouble.
>
>
> ********************************************************************
> Embed Inc, Littleton Massachusetts,
http://www.embedinc.com/products
> (978) 742-9014. Gold level PIC consultants since 2000.
> -
2011\01\14@103156
by
jim
|
Okay. Whatever. But these are the specs I've come to know and use
ocassionally. I have had no problems
using the values I mentioned. I don't use them very often, but I when
I do, these are the values I use.
If they are wrong, then I guess they're wrong. But I have several
projects out there that use these values, and they are still operating the same way they did when I first
built them. And yes, they worked
then as they were designed to.
If you want to advise people to not use these values, then by all means
go ahead. But I plan to keep on using these values in the future. I'm not going to change something
when what I have works fine. It's
one of those "if it ain't broke, don't fix it" sort of things for me.
And if this seems to be bad engineering practice to you, then so be it.
But it has proven to be fine to me,
and that's what I'll go by. If in the future, something happens to
change my mind, then I'll change.
But until such a time comes, I'll go with what works.
Regards,
Jim
> ---{Original Message removed}
2011\01\14@103946
by
Spehro Pefhany
2011\01\14@110636
by
Olin Lathrop
jim@jpes.com wrote:
> But these are the specs I've come to know and use
> ocassionally.
You mentioned different values. The pullup resistor values you said you
used are actually in spec as they result in around 1mA required pulldown
current.
> I have had no problems using the values I mentioned.
If you used the 1mA pullups, then you are in spec and it should work.
Otherwise your test cases only failed to prove the design is bad, not prove
that the design is good.
> But I have several
> projects out there that use these
> values, and they are still operating the same way they did when I
> first built them.
Again, that's no proof of correctness, only proof of no blatant errors. A
lot of IIC chips will successfully pull down with more than the minimum 3mA
they are required to, so lower pullup resistors will likely work much of the
time. However, that can change over temperature, from one manufacturing lot
to another, after a die shrink, etc.
> It's one of those "if it ain't broke, don't fix it"
> sort of things for me.
For you apparently. For others it is broken, just that the symptoms haven't
manifested themselves yet.
What you are doing (more than 3mA pulldown current required on a standard
IIC bus) is bad design, plain and simple. Now you're just trying to save
face by making it sound acceptable somehow. Unfortunately that may give
some bystanders the impression it is OK. It's not. It's bad design. Don't
do this folks.
> And if this seems to be bad engineering practice to you, then so be
> it. But it has proven to be fine to me,
That is logically incorrect. You have only failed to prove it is bad.
********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014. Gold level PIC consultants since 2000
2011\01\14@111110
by
Wouter van Ooijen
> And if this seems to be bad engineering practice to you, then so be it.
> But it has proven to be fine to me,
> and that's what I'll go by.
If the specs don't convince you I can't guess what will.
I guess you once crossed a highway without being hit, so you will continue to do that?
IIRC you quoted the right resistor values but the wrong currents, so your circuits will work, but others that base their deign on the current you mention will fail :(
--
Wouter van Ooijen
-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu
2011\01\14@111745
by
Olin Lathrop
Spehro Pefhany wrote:
> Here are some more actual specs:
>
> www.nxp.com/acrobat_download2/literature/9398/39340011.pdf
> http://www.nxp.com/documents/user_manual/UM10204.pdf
The second has a nice chart on page 36 that makes it quite clear. For both
standard and fast mode 3mA current to ground must be able to bring a bus
line to 400mV or less. In fast mode 6mA sink must also bring the bus to
600mV or less. Only in high speed mode (which that document calls "fast
mode plus") is 20mA sink capability required, and in that case to the 400mV
level.
********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014. Gold level PIC consultants since 2000
2011\01\14@113133
by
jim
Okay. But it works for me. That's what I'm saying here.
If it's bad, it's bad. I'm not trying to 'SAVE' anything.
I'm flatly stating that what I have done works for me.
If you don't want to try it, don't try it. If you want to
advise people not to try it, go ahead and advise.
But it works for me. And I'm not going to change just because you say so. If it catches up with me, then so be it.
That will be my problem. And then you can say "I told you so".
But until that time, I'm going to go on using the values I have been using.
I'm done talking about it. You have your opinon and I have mine.
So until the next subject I'm stopping my input to this thread.
Regards,
Jim
> ---{Original Message removed}
2011\01\14@115544
by
Wouter van Ooijen
> But until that time, I'm going to go on using the values I have
> been using.
So then tell others those values (IIRC 2k2), and not a current that is simply wrong (by the standard, and also not the current you use!).
--
Wouter van Ooijen
-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu
2011\01\14@131811
by
Olin Lathrop
jim@jpes.com wrote:
> Okay. But it works for me. That's what I'm saying here.
Do what you want, but please stop making it sound somehow reasonable or a
good practise to others. What you are doing is irresponsible and bad
engineering. That's your business until you try to advise other to do it or
leave the impression that it is acceptable.
> And I'm not going to change just
> because you say so.
I'm not trying to convince you. If the datasheet can't, I have no chance.
Besides I don't care what you do or think. I do care, however, when you
advise others to follow your bad example.
********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014. Gold level PIC consultants since 2000
2011\01\15@064719
by
Vicent Colomar Prats
Sphero, thank you for that contribution.
I did not know about that manual, specially second from NXP. I like it, is
very well explained and, think, is easy to understand.
Greetings.
2011/1/14 Spehro Pefhany <TakeThisOuTspeffspam
interlog.com>
{Quote hidden}
2011\01\25@020216
by
PICdude
|
Back. I did some checking, testing, etc, and reailzed I failed with my original question -- I do need SCL pullups, but the reason I did not have it in the 16F877A circuit was that I forgot that I had bit-banged that (~6 years ago) on two regular I/O pins. The SCL line went to logic high or low (never floating). On that, the SDA line had a 3.9k pullup, and I frankly don't remember how I calculated it. That controlled a single serial EEPROM at a very low speed.
Ran a quick test using the actual MSSP module now, and used a very high 10Mohm pull-down (to verify whether I really needed a pullup up or not, by ensuring that if it floats, it would get pulled to ground), and it did not work. Adding a 3.9k the pullup solved it.
The spec is great, and answers my question. Thanks.
Cheers,
-Neil.
Quoting Vicent Colomar Prats <RemoveMEvicentecolomarEraseME
spam_OUTgmail.com>:
{Quote hidden}> Sphero, thank you for that contribution.
>
> I did not know about that manual, specially second from NXP. I like it, is
> very well explained and, think, is easy to understand.
>
> Greetings.
>
>
> 2011/1/14 Spehro Pefhany <
@spam@speffRemoveME
EraseMEinterlog.com>
>
>> At 10:31 AM 14/01/2011, you wrote:
>>
>> > Okay. Whatever. But these are the specs I've come to know and use
>> >ocassionally.
>>
>> <many words snipped>
>>
>> Here are some more actual specs:
>>
>> www.nxp.com/acrobat_download2/literature/9398/39340011.pdf
>> www.nxp.com/documents/user_manual/UM10204.pdf
>>
>>
>>
>> >Best regards,
>>
>> Spehro Pefhany --"it's the network..." "The Journey is the
>> reward"
>>
EraseMEspeff
@spam@interlog.com Info for manufacturers:
>>
http://www.trexon.com
>> Embedded software/hardware/analog Info for designers:
>>
http://www.speff.com
>>
>>
>
2011\01\25@084117
by
Olin Lathrop
PICdude wrote:
> The SCL line went to logic high or low (never floating).
That's a bad idea in general. You can get away with it if you're not using
multi-master and you're really sure none of the slave devices on the bus do
clock stretching.
You can still do it right easily enough with bit banging (in fact I usually
do, due to so many problems with the MSSP in IIC mode), just bang the TRIS
bit while keeping the port bit 0, and of course add a pullup. You can use a
pin with a internal pullup if you slow the clock enough to compensate for
the slow rise times.
********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014. Gold level PIC consultants since 2000
2011\01\25@112755
by
PICdude
Quoting Olin Lathrop <@spam@olin_piclistspam_OUT
.....embedinc.com>:
> PICdude wrote:
>> The SCL line went to logic high or low (never floating).
>
> That's a bad idea in general. You can get away with it if you're not using
> multi-master and you're really sure none of the slave devices on the bus do
> clock stretching.
Correct.
> You can still do it right easily enough with bit banging (in fact I usually
> do, due to so many problems with the MSSP in IIC mode), just bang the TRIS
> bit while keeping the port bit 0, and of course add a pullup. You can use a
> pin with a internal pullup if you slow the clock enough to compensate for
> the slow rise times.
That's what's I was doing on the SDA line, but had no need for it on the SCL line. Will be doing this for a newer use, where I'll be running I2C faster, and clock-stretching will be possible.
Cheers,
-Neil.
More... (looser matching)
- Last day of these posts
- In 2011
, 2012 only
- Today
- New search...