Searching \ for ' 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'.

No exact or substring matches. trying for part
PICList Thread
'[PICLIST] I2C pullups'
2001\03\13@223007 by Glenn Mitchell

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

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

flavicon
face
on 3/13/01 7:28 PM, Glenn Mitchell at spam_OUTgmitchTakeThisOuTspam101FREEWAY.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                 .....rmannKILLspamspam@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

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

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

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

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

flavicon
face
{Quote hidden}

    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

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@165325 by Mike Mansheim

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

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

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

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

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\14@231615 by Herbert Graf

flavicon
face
{Quote hidden}

    Ahh, well there it is, in HS mode there is no clock stretching, that's
why I've never seen it. TTYL

{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\15@044712 by mike

flavicon
face
On Wed, 14 Mar 2001 14:45:03 -0600, you wrote:

{Quote hidden}

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

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


'[PIC]: Switching INPUTS<->OUTPUTS (was I2C pullups'
2001\03\16@081126 by Bob Ammerman

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


'[PIC]: I2C pullups'
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 @spam@listservKILLspamspammitvma.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 KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


'[PIC]: Switching INPUTS<->OUTPUTS (was I2C pullups'
2001\03\16@085018 by Roman Black

flavicon
face
Bob Ammerman wrote:
{Quote hidden}

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


'[PIC]: I2C pullups'
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 spamBeGonelistservspamBeGonespammitvma.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 TakeThisOuTlistservEraseMEspamspam_OUTmitvma.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 RemoveMElistservspamTakeThisOuTmitvma.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
piclist-unsubscribe-requestEraseMEspam.....mitvma.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
EraseMEpiclist-unsubscribe-requestspammitvma.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-requestEraseMEspamEraseMEmitvma.mit.edu

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspam_OUTspamKILLspammitvma.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
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspamspammitvma.mit.edu


2001\03\17@162344 by briang

flavicon
face
In-Reply-To: <EraseME3AB3A510.5CF6spamspamspamBeGoneezy.net.au>

Roman Black <RemoveMEfastvidKILLspamspamEZY.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.
briangSTOPspamspamspam_OUTcix.compulink.co.uk

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestSTOPspamspamEraseMEmitvma.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:KILLspamkevinbspamBeGonespamWOODANDDOUGLAS.CO.UK]
> Sent: Monday, March 19, 2001 9:24 AM
> To:   EraseMEPICLISTspamEraseMEMITVMA.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" <@spam@mrjones@spam@spamspam_OUTNORTELNETWORKS.COM>
To: <spamBeGonePICLISTspamKILLspamMITVMA.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: .....avdspam_OUTspamaudiovisualdevices.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



'[PIC] I2C pullups?'
2011\01\13@153516 by PICdude
flavicon
face
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

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

flavicon
face

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

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

flavicon
face

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

face picon face
On 14/1/2011 12:19 AM, TakeThisOuTjim.....spamTakeThisOuTjpes.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

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

flavicon
face

Okay.  Whatever.

Regards,

Jim

{Quote hidden}

> -

2011\01\14@103156 by jim

flavicon
face

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

picon face
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
http://www.nxp.com/documents/user_manual/UM10204.pdf



>Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
spamBeGonespeff@spam@spamspam_OUTinterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

2011\01\14@110636 by Olin Lathrop

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

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

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

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

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

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

picon face
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 <TakeThisOuTspeffspamspaminterlog.com>

{Quote hidden}

2011\01\25@020216 by PICdude

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

{Quote hidden}

>

2011\01\25@084117 by Olin Lathrop

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

flavicon
face
Quoting Olin Lathrop <@spam@olin_piclistspam_OUTspam.....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...