Hi, Unfortunately, I do not have access to tools such as an o-scope or logic analyzer. Just my trusty DMM :-( So there's no way, as of yet, that I can track the data that is coming out. And I see what you mean by tab stops - my apologies for that, wasn't aware that they could be different. I am going to order a few more TC74's just to make sure I haven't fried the two that I already have when I wrote the code manually - this might make a difference. Now on to the code... Quoting Olin Lathrop : > First, don't put tab characters in the source code. You have no way of > knowing what other people's tab stops are set to. Your code looked like a > mess when I got it, since my tabs are apparently set differently from > yours. I converted it to spaces with tab stops every column starting at > 30. > > Second, proportionally spaced fonts are also a bad idea for the same > reason. You have no way of knowing what my font settings are. Note that > some things now look like a mess in fixed spaced font. > > > #define _SEN SSPCON2,SEN > > #define _PEN SSPCON2,PEN > > #define _RCEN SSPCON2,RCEN > > #define _ACKDT SSPCON2,ACKDT > > #define _ACKSTAT SSPCON2,ACKSTAT > > #define _SDA_TRIS TRISC,4 > > #define _SCLK_TRIS TRISC,3 > > > > > > ;---------------------------------------------------------------; > > ; ; > > ; ; > > ; HIGH LEVEL ROUTINES ; > > ; ; > > ; ; > > ;---------------------------------------------------------------; > > > > > > TGetTemp > > > > call I2CInit ;Initialize the registers > > > > call I2CStartBit ;Send a start bit. > > > > movlw b'10010000' > > ;Data: 1001000- The address of the Slave: 1001 000 > > ; -------0 Send a write bit for writing a command > > call I2CWrite > > You should stop the code here to find out whether you get an ACK on the > address byte. Since you send another byte right away, the LCD display > won't show you the address byte ACK/NACK. > The code does check for an ACK. If you look inside the I2CWrite routine, it does a check for an ACK and outputs either 0 or 1 to the LCD. You are right, I should add an abort feature to it... since I just had it go on without aborting.. but either way, that's how I know this isn't working in the first place - my ACK's aren't coming through. They are just built into the I2CWrite routine tho. > The code here should also check for the ACK and abort on NACK. > > > ... > > > > > ;---------------------------------------------------------------; > > ; ; > > ; ; > > ; LOW LEVEL ROUTINES ; > > ; ; > > ; ; > > ;---------------------------------------------------------------; > > > > ;---------------------------------------------------------------; > > ; ; > > ; I2CInit ; > > ; ; > > ; Initializes the I2C ports and registers ; > > ; ; > > ;---------------------------------------------------------------; > > > > I2CInit > > > > banksel SSPADD > > movlw 0xff ;Holds transmission Using equation SSPADD > = (Fosc/Baudrate)/4 - 1 > > movwf SSPADD ;@ Fosc = 4 MHz, 0xff yields rate of 3.9 > KHz (slowest possible for testing purposes). > > > > ;Configure the I2C Port > > Shouldn't there be a bank switch to SSPSTAT here? Technically, yes - but SSPADD/SSPSTAT/TRISC are all in the same bank (bank1) so I didn't feel the need to keep putting in my banksel routine. For safety's sake, I will stick it in there however. > > > bcf SSPSTAT,6 ; select I2C input levels instead of > SMBUS > > bsf SSPSTAT,7 ; Disable slew rate for high speed (400 > KHZ) by setting bit. > > > > > > ;Setup the TRIS registers for SDA/SCLK > pins as inputs. > > Again, bank settings? > > > bsf _SDA_TRIS ;SDA = Pin 4 , Port C > > bsf _SCLK_TRIS ;SCLK = Pin 3, Port C > > As I said last time, I would also initialize SSPCON2 just to be sure. Reading the datasheet, SSPCON2 is initialized automatically to 0x00 on POR - isn't this sufficient, or should I add it anyway? > > > banksel SSPCON > > > > movlw b'00111000' ;Enable the MSSP port. > > ;SSPCON:0------- WCOL bit > > ; -0------ SSPOV - no overflow > > ; --1----- Enables Serial Port > > ; ---x---- Clock polarity; don't care in I2C master > mode. > > ; ----1000 I2C Master mode > > movwf SSPCON > > > > return > > > > ... > > > > ;------------------------------------------------------------; > > ; ; > > ; I2CWrite ; > > ; ; > > ; Inputs: W Register ; > > ; Outputs: Output the value to the slave device. ; > > ; ; > > ;------------------------------------------------------------- > > > > I2CWrite > > > > > > banksel SSPBUF > > movwf SSPBUF ;Move the contents of W into SSPBUF in > bank 0. > > banksel SSPSTAT > > > > btfsc SSPSTAT,R_W ;Test to see when write is completed. R_W > bit will be clear when completed. > > goto $-1 > > > > movlw 0x00 > > btfss _ACKSTAT ;Successful if the ACKSTAT bit is clear. > W will contain 1 if successful. > > movlw 0x01 > > > > bank0 > > call LCDBin ;---------------------------------------; > > ; For TESTING purposes ; > > ; Call LCDBin to display value in W ; > > > ;---------------------------------------; > > return > > > > ;------------------------------------------------------------; > > ; ; > > ; I2CStartBit ; > > ; ; > > ; Inputs: none ; > > ; Outputs: Sends a start bit to slave ; > > ; ; > > ;------------------------------------------------------------- > > > > > > > > I2CStartBit > > > > > > banksel SSPCON2 > > bsf _SEN ;Enable Tx of Start (S) > > > > btfsc _SEN ;Test for completion > > goto $-1 > > > > bank0 > > You can use this convention if you like, but in the end I think you'll > find it's easier to assume subroutines trash the bank setting. > > > return > > ... > > > ***************************************************************** > Embed Inc, embedded system specialists in Littleton Massachusetts > (978) 742-9014, http://www.embedinc.com > > -- > http://www.piclist.com hint: PICList Posts must start with ONE topic: > [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads > ---------------------------------------- This mail sent through www.mywaterloo.ca -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads