Searching \ for '[PIC]:[EE]: problem with bitbanged I2C master mode' 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: '[EE]: problem with bitbanged I2C master mode'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]:[EE]: problem with bitbanged I2C master mode'
2005\07\09@132913 by James Humes

picon face
Hello Everyone,
 This is my first post on the list. I'm working with a PIC16F913 and trying to implement I2C master mode on two of its pins (SCL, SDA). I have put a 10K resistor on each line to pull it up to Vcc and I clear the PORTC bits associated with those lines. I set the TRISC bits associated with those lines so that the lines are floating high during the idle state.
 I've followed the guidance of a book for the routines I'm using (p. 328, p.347 Katzen), but I cannot get a reading back. The device I'm trying to read is an LM92 temperature sensor. The message format is: Assert start condition, Write 1 command byte, LM92 (slave) acks. Read 1st data byte, master ACKs, Read 2nd (and last) data byte, Master NACKs, assert stop condition.   The problem is that I keep getting back all 0's in my read bytes. Here is the I2C_IN routine I'm using. I took the main idea from the above book, but out of frustration have made several changes (that mostly affect setting up the SCL, SDA lines). One part that I'm not sure about is the testing of the incoming bit. The software is testing the TRISC register for its status and setting the bit based on that. Is that how its supposed to do? I can see why setting and clearing TRIS bits works for output on these lines, but for reading I'm not sure.
first I have these defines

#define SCL TRISC, 6
#define SDA TRISC, 7
and here is the routine to bring data in
I2C_IN
bsf STATUS, RP0 ;switch to bank 1
bcf STATUS, RP1
bcf SCL ;make sure we're starting with clock low
movlw .8
movwf GenCount ;set up counter

I2C_INLOOP

bcf SCL ;clock low
nop
nop ;for 3uS, minimum 2.5 uS
nop bsf SCL ;bring clock high
bcf STATUS, C ;clear carry bit
btfsc SDA ;test incoming bit
bsf STATUS, C ;if its a one, set carry and
rlf DATA_IN, 1 ;roll the carry into our recieved byte
decfsz GenCount, 1 ;dec counter
goto I2C_INLOOP ;and repeat 8 times

;send either an ACK or NACK depending on contents of ACK

bcf SCL ;bring clock low
bsf SDA ;float data high (NACK)
movf ACK, 0 ;see what we want to do
btfsc STATUS, Z ;if ACK != 0 then leave it NACK bcf SDA ;otherwise, bring signal low to ACK
nop
nop
bsf SCL ;now bring clock high
nop ;wait 3 uS (2.5 minimum)
nop
nop
bcf SCL ;leave with clock low
return
I can post other parts of code if needed. Thanks for any help anyone can provide.
James

2005\07\09@144658 by Bob Barr

flavicon
face
On Sat, 9 Jul 2005 11:29:13 -0600, James Humes wrote:

All of your variables (GenCount, DATA_IN, and ACK)  are in bank 1,
right?

<snip>
{Quote hidden}

2005\07\09@152922 by olin piclist

face picon face
James Humes wrote:
> I'm working with a PIC16F913 and
> trying to implement I2C master mode on two of its pins (SCL, SDA). I
> have put a 10K resistor on each line to pull it up to Vcc

That's a pretty high value.  It may cause trouble unless your bit rate is
really slow, like below 10Kbits/sec maybe.  Check the rise time on the
scope.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\07\09@194308 by Jinx

face picon face
> All of your variables (GenCount, DATA_IN, and ACK)  are
> in bank 1, right?

And SDA is set to i/p for the receive routine ?

PS

bsf STATUS, RP0 ;switch to bank 1
bcf STATUS, RP1

will change bank OK, but "banksel trisc" shows intent

Are you working with the I2C module enabled ? If so, pullups
may not meet spec

2005\07\10@003349 by Herbert Graf
flavicon
face
On Sat, 2005-07-09 at 15:29 -0400, Olin Lathrop wrote:
> James Humes wrote:
> > I'm working with a PIC16F913 and
> > trying to implement I2C master mode on two of its pins (SCL, SDA). I
> > have put a 10K resistor on each line to pull it up to Vcc
>
> That's a pretty high value.  It may cause trouble unless your bit rate is
> really slow, like below 10Kbits/sec maybe.  Check the rise time on the
> scope.

Actually that isn't that high. For example, the MChip datasheet for the
24C02C EEPROM (page 4) says:

"...the SDA requires a pull-up resistor to Vcc (typical 10k for 100kHz,
2k for 400kHz)."

While I more commonly use lower values, 10k is completely reasonable in
my mind for "normal" I2C speeds which are on the slower side, and
definitely doesn't imply running < 10khz.

TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2005\07\10@010147 by James Humes

picon face
Thanks a lot everyone. I finally got it working. The book I was using for reference actually had an error in it.  James

On 7/9/05, Herbert Graf <spam_OUTmailinglist2TakeThisOuTspamfarcite.net> wrote:
{Quote hidden}

>

2005\07\10@010608 by Jinx

face picon face
> While I more commonly use lower values, 10k is completely reasonable
> in my mind for "normal" I2C speeds which are on the slower side, and
> definitely doesn't imply running < 10khz.

The major factor I believe is buss capacitance. PIC i/o have pretty fast
rise and fall times so I guess they're quite low C. No or short cable
wouldn't present too much load

2005\07\10@021407 by Herbert Graf

flavicon
face
On Sun, 2005-07-10 at 17:06 +1200, Jinx wrote:
> > While I more commonly use lower values, 10k is completely reasonable
> > in my mind for "normal" I2C speeds which are on the slower side, and
> > definitely doesn't imply running < 10khz.
>
> The major factor I believe is buss capacitance. PIC i/o have pretty fast
> rise and fall times so I guess they're quite low C. No or short cable
> wouldn't present too much load

True, but note that the value of the pull up is more to do with the pull
up "pulling up" the bus, then the time it takes the device to pull down
the bus.

In all applications of I2C where I've plunked down a scope the "pull
down" time by whatever device is driving is MUCH faster then the "pull
up" time of the resistors' action.

If you have a longer bus (or perhaps just an average length bus but iwth
a crap load of devices), or want to go at a greater speed, then a lower
pull up is definitely a good idea, but for more average speeds and bus
configs 10k seems reasonable. However, with all that said, unless power
is of concern, you almost never loose by using a lower pull up.

In the end it doesn't matter either way, the op found the problem.

TTYL


-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2005\07\10@035211 by Dmitriy Kiryashov

picon face
Hi Herbert.

Just question out of curiousity.

Why that impossible to one person to use current source
in place of pull up resistor with the same amount of current
as pull up resistor provides when it's grounded.
Charging up the bus capacitance will become linear
and thus takes less time.


WBR Dmitry.


Herbert Graf wrote:
{Quote hidden}

> -

2005\07\10@061256 by Jinx

face picon face
> Just question out of curiousity.
>
> Why that impossible to one person to use current source
> in place of pull up resistor with the same amount of current
> as pull up resistor provides when it's grounded.
> Charging up the bus capacitance will become linear
> and thus takes less time.

Philips cover high-speed I2C and high-C busses. For normal
low speed operation resistors are fine, IM (very limited) E to
meet spec

Section 17

http://www.semiconductors.philips.com/acrobat/literature/9398/39340011.pdf

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