Searching \ for '[PIC]: I2C pullups' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/i2cs.htm?key=i2c
Search entire site for: 'I2C pullups'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: I2C pullups'
2001\03\14@165122 by Barry King

flavicon
face
> 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@231543 by Herbert Graf

flavicon
face
I stand corrected, forgot about clock stretching, probably because I've
never used a device that did it. TTYL

> {Original Message removed}

2001\03\15@065303 by Roman Black

flavicon
face
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}

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

flavicon
face
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}

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

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

picon face
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

picon face
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

flavicon
face
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 spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2001\03\16@081338 by Roman Black

flavicon
face
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 .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body


2001\03\16@081523 by Roman Black

flavicon
face
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}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2001\03\16@124025 by rottosen

flavicon
face
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 .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2001\03\16@140628 by mike

flavicon
face
On Fri, 16 Mar 2001 23:59:12 +1100, you wrote:

{Quote hidden}

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 EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2001\03\16@154830 by Drew Vassallo

picon face
>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 listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2001\03\17@003823 by Roman Black

flavicon
face
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
@spam@piclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2001\03\17@005100 by Roman Black

flavicon
face
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
KILLspampiclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2001\03\17@121617 by rottosen

flavicon
face
Roman Black wrote:
{Quote hidden}

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-requestTakeThisOuTspammitvma.mit.edu

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu


2001\03\17@125623 by Roman Black

flavicon
face
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
TakeThisOuTpiclist-unsubscribe-requestEraseMEspamspam_OUTmitvma.mit.edu


2001\03\17@162344 by briang

flavicon
face
In-Reply-To: <RemoveME3AB3A510.5CF6spamTakeThisOuTezy.net.au>

Roman Black <fastvidEraseMEspam.....EZY.NET.AU> wrote:

> In a perfect world I would use a series resistor
> AND pullup resistor, and just change to input for
> checking the ACK.

No, no.

Why do you have some kind of mental block when it comes to tristating with
the TRIS register??

It's a perfectly straight forward technique.

Brian Gregory.
EraseMEbriangspamcix.compulink.co.uk

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestEraseMEspamEraseMEmitvma.mit.edu


2001\03\19@043443 by Kevin Blain

flavicon
face
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

flavicon
face
> -----Original Message-----
> From: Kevin Blain [SMTP:RemoveMEkevinbspam_OUTspamKILLspamWOODANDDOUGLAS.CO.UK]
> Sent: Monday, March 19, 2001 9:24 AM
> To:   RemoveMEPICLISTTakeThisOuTspamspamMITVMA.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}

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

flavicon
face
which you will probably be doing if you are doing I2C.
----- Original Message -----
From: "Michael Rigby-Jones" <EraseMEmrjonesspamspamspamBeGoneNORTELNETWORKS.COM>
To: <RemoveMEPICLISTKILLspamspamMITVMA.MIT.EDU>
Sent: Monday, March 19, 2001 10:00 AM
Subject: Re: [PIC]: I2C pullups


> > {Original Message removed}

2001\03\19@061227 by David Duffy

flavicon
face
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: avdSTOPspamspamspam_OUTaudiovisualdevices.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

picon face
>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

picon face
>>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

flavicon
face
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


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...