Post by thread:[PIC]:[EE]: problem with bitbanged I2C master mode

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

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

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

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/

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_OUTmailinglist2TakeThisOuTfarcite.net> wrote: {Quote hidden}> > 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/ > >

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/

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

> 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