> > I seem to be experiencing difficulties getting an f877 to
> > communicate with a Temperature sensor (TC74) using I2C. I first decided
> to try
> > and code my own routines, considering they didn't seem that hard. But
> after
> > trying for a full day, I have had no luck.
>
> The 16F877 has a MSSP module, which can take care of the IIC low level
> details.  However, if you only need to be a master, then writing your own
> IIC routines is easy too.  The attached file contains software IIC master
> routines from a particular project although they should be reasonably
> general.  It relies on the declaration:
>
> /flag    ackb  ;need to acknowledge previously received IIC byte
>
> in the project include file, and probably a few other things.  It is also
> written using our PIC development environment described at
> http://www.embedinc.com/pic.  However, it shouldn't be that hard to
> follow.
>
> --
> 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
>
>
>

> > After almost a whole day of trying to look at code and fixing mine, I
> think I
> > finally got somewhere. The procedure for obtaining the temperature for a
> TC74
> > seems to be this (correct me if I'm wrong:
> >
> www.microchip.com/download/lit/pline/analog/thermal/tempsens/serial
> /2146
> > 2c.pdf). Anyway, the way I'm doing it is:
> >
> > Send 7-bits of address (I have the part # with address 1001 000) and
> then one
> > bit of R/W. The first phase of transfer always seems to be write, so I
> send a
> > 0.
> > First byte out then becomes: 1001 0000.
> > I then get a successful ACK (I set SDA high intentionally, and the slave
> > succesfully pulls it low).
> >
> > I then send the command to read the temperature,
>
> You should do a bus STOP here, followed by a bus START before the next
> command.

>
> > which is 00h. I also get a
> > successful ACK on this. According to the datasheet, it says to re-send
> the
> > slave address accept with the R/W bit set this time, so I send: 1001
> 0001.
> > And again, I get a successful ACK.
> >
> > Next, I should just send 8 clock pulses and be able to read the data on
> SDA,
> > but instead I get all 0's.
>
> Good.  That's better than all 1s because somebody is at least pulling the
> bus low.  Did you make sure the master released SDA before sending the 8
> clocks?  If it did, then the slave thinks it's addressed but probably
> confused.  That could be explained by the missing STOP/START.  Or, is it
> really cold in your office <g>?
>

>
> *****************************************************************
> Embed Inc, embedded system specialists in Littleton Massachusetts
> (978) 742-9014, http://www.embedinc.com
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.
>

> > > You should do a bus STOP here, followed by a bus START before the next
> > > command.
> >
> > Regarding this, in the command sequence diagram, it shows just to just
> send a
> > BUS Start bit, not stop and start. I was doing this, but neglected to
> mention
> > it.
>
> That should be OK.  All devices are supposed to reset their bus logic on a
> start, regardless of what state it was in at the time.  In multi-master
> mode doing just a start is actually a good idea so that no other master
> can get in there between commands.
>
> > And yes, on the ninth clock cycle, I set the TRIS bit so that SDA
> becomes an
> > input.
>
> You should do that in the low phase before the ninth clock cycle, not "on"
> the ninth clock cycle (whatever that means).
>
> > That's how it seems to get pulled low successfully.
>
> Huh?  Setting the TRIS bit should cause SDA to float high.  Something is
> very wrong if setting the TRIS bit causes SDA to go low.

>
>
> *****************************************************************
> Embed Inc, embedded system specialists in Littleton Massachusetts
> (978) 742-9014, http://www.embedinc.com
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.
>

>
> And yes, you should be using pull up resistors on both the clock and data
> line as your PIC should have both lines as "open collector" types. This is
> done automatically by the MSSP hardware, but is why you need to use the TRIS
> registers to set the bits to a 0 state when doing a bit bang implementation.
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.
>

>
> *****************************************************************
> Embed Inc, embedded system specialists in Littleton Massachusetts
> (978) 742-9014, http://www.embedinc.com
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.
>

> >When searching for information on the 877, it seemed that I could only find
> >software implementations of the I2C routines when the PIC would be acting
> as a
> >master. For slave I found plenty of implementations using the built in
> >hardware, but I could not find anything using hardware as a master. Could
> you
> >perhaps point me in some direction? (I was using AN554 on Microchip's
> website
> >is my main reference). Then I won't have to go through the uneccessary hell
> of
> >coding this by hand - and re-coding it with TRIS registers now (since I
> have
> >been doing that much wrong so far).
>
> Well you found one application note, but what about Microchip AN734, 735 and
> 578? These all relate to using the MSSP, one about slave use, one master,
> and one multimaster. There is a bug in the code listing on the master AN,
> but search the piclist archives and you will find details of it, I do not
> have them to hand at the immediate moment.
>
> Also go to the Philips website and search for I2C, you should be able to
> find the I2C specification document, which is what tells you about the
> pullups, using in multi-voltage environments, and all sorts of other bits
> and pieces.
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.
>

> Quoting "Alan B. Pearce" <RemoveMEA.B.PearceTakeThisOuTRL.AC.UK>:
>
> > >And I shouldn't be communicating using bsf/bcf on
> > >the ports.. instead use the TRIS bits? This seems odd.
> >
> > What is even more odd is why you seem to be using a software bit bang of the
> > I2C instead of using the internal MSSP I2C hardware. Your subject line says
> > you are using an 877 which has this and it is real easy to use.
>
> When searching for information on the 877, it seemed that I could only find
> software implementations of the I2C routines when the PIC would be acting as a
> master. For slave I found plenty of implementations using the built in
> hardware, but I could not find anything using hardware as a master. Could you
> perhaps point me in some direction? (I was using AN554 on Microchip's website
> is my main reference). Then I won't have to go through the uneccessary hell of
> coding this by hand - and re-coding it with TRIS registers now (since I have
> been doing that much wrong so far).
>
> >
> > And yes, you should be using pull up resistors on both the clock and data
> > line as your PIC should have both lines as "open collector" types. This is
> > done automatically by the MSSP hardware, but is why you need to use the TRIS
> > registers to set the bits to a 0 state when doing a bit bang implementation.
> >
> > --
> > http://www.piclist.com hint: The PICList is archived three different
> > ways.  See http://www.piclist.com/#archives for details.
> >
>
>
>
>
> ----------------------------------------
> This mail sent through http://www.mywaterloo.ca
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.
>

> Hi,
>
> I just working on such a project. It'll be finished very soon. BTW it is
> not so simple as it seems to be...
>
> Regards,
> Imre
>
>
> > Quoting "Alan B. Pearce" <RemoveMEA.B.PearceTakeThisOuTRL.AC.UK>:
> >
> > > >And I shouldn't be communicating using bsf/bcf on
> > > >the ports.. instead use the TRIS bits? This seems odd.
> > >
> > > What is even more odd is why you seem to be using a software bit bang of
> the
> > > I2C instead of using the internal MSSP I2C hardware. Your subject line
> says
> > > you are using an 877 which has this and it is real easy to use.
> >
> > When searching for information on the 877, it seemed that I could only
> find
> > software implementations of the I2C routines when the PIC would be acting
> as a
> > master. For slave I found plenty of implementations using the built in
> > hardware, but I could not find anything using hardware as a master. Could
> you
> > perhaps point me in some direction? (I was using AN554 on Microchip's
> website
> > is my main reference). Then I won't have to go through the uneccessary hell
> of
> > coding this by hand - and re-coding it with TRIS registers now (since I
> have
> > been doing that much wrong so far).
> >
> > >
> > > And yes, you should be using pull up resistors on both the clock and
> data
> > > line as your PIC should have both lines as "open collector" types. This
> is
> > > done automatically by the MSSP hardware, but is why you need to use the
> TRIS
> > > registers to set the bits to a 0 state when doing a bit bang
> implementation.
> > >
> > > --
> > > http://www.piclist.com hint: The PICList is archived three different
> > > ways.  See http://www.piclist.com/#archives for details.
> > >
> >
> >
> >
> >
> > ----------------------------------------
> > This mail sent through http://www.mywaterloo.ca
> >
> > --
> > http://www.piclist.com hint: The PICList is archived three different
> > ways.  See http://www.piclist.com/#archives for details.
> >
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> email listservEraseME.....mitvma.mit.edu with SET PICList DIGEST in the body
>

>
>
> *****************************************************************
> Embed Inc, embedded system specialists in Littleton Massachusetts
> (978) 742-9014, http://www.embedinc.com
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> email RemoveMElistservKILLspammitvma.mit.edu with SET PICList DIGEST in the body
>

> that's not too odd.
> i only use software i2c as this allows me to run i2c at 1kHz, allowing
> long distance i2c.
> it also allows me to use the same periphery drivers on all pics.
> tino
>
>
>
>
>
> "Alan B. Pearce" <KILLspamA.B.PearcespamBeGoneRL.AC.UK>
> Gesendet von: pic microcontroller discussion list <EraseMEPICLISTEraseMEMITVMA.MIT.EDU>
> 03.02.03 16:33
> Bitte antworten an pic microcontroller discussion list
>
>
>         An:     @spam@PICLIST@spam@spam_OUTMITVMA.MIT.EDU
>         Kopie:
>         Thema:  Re: [PIC]: f877 I2C routines
>
>
> >And I shouldn't be communicating using bsf/bcf on
> >the ports.. instead use the TRIS bits? This seems odd.
>
> What is even more odd is why you seem to be using a software bit bang of
> the
> I2C instead of using the internal MSSP I2C hardware. Your subject line
> says
> you are using an 877 which has this and it is real easy to use.
>
> And yes, you should be using pull up resistors on both the clock and data
> line as your PIC should have both lines as "open collector" types. This is
> done automatically by the MSSP hardware, but is why you need to use the
> TRIS
> registers to set the bits to a 0 state when doing a bit bang
> implementation.
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> email spamBeGonelistservKILLspammitvma.mit.edu with SET PICList DIGEST in the body
>

> A word of warning: read-modify-write instructions on TRISC are NOT safe
> when the SSP is in use - they will read the current direction of the
> SDA/SCL pins and write them back, possibly disabling the SSP module's
> ability to change directions later.  The code I quoted comes before you
> enable the SSP, and so is safe, but you could run into trouble if you use
> this style of TRIS setting later in the program.
>         Jason Harper
>



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

> >  bank1
>
> This is a bug waiting to happen.  The exact address of TRISC is known at
> assembly time, so there is no reason the assembler can't compute the bank
> for you.  Sooner or later you are going to manually select the wrong bank.
> See my DBANKIF and related macros in STD.INS.ASPIC at
> http://www.embedinc.com/pic.
>
> >  movlw b'00011000'
> >  iorwf TRISC,f
> >
> >  movlw 0x09                 ;This will hold our Baud Rate!
> >  movwf SSPADD
> >  bcf SSPSTAT,6              ; select I2C input levels
> >  bcf SSPSTAT,7              ;
> >  bank0
> >  movlw b'00101000'
>
> This should be documented better.  I write it like this:
>
>    movlw b'00101000'
>          ; 0-------  reset write collision flag
>          ; -0------  reset read overflow flag
>          ; --1-----  enable the MSSP
>          ; ---X----  clock stretch not used in master mode
>          ; ----1000  select IIC master mode
>

> >  movwf SSPCON
> >
> >  bank1
> >  bsf _SEN                   ;Enable the start bit tx.
> >  btfsc _SEN                 ;Check to see when it's done.
> >   goto $-1
> >  bank0
> >
> >  movlw b'10010000'          ;Move the address and tx it.
>
> This is really the address shifted left 1 bit with the R/W bit in bit 0.
> You are therefore starting a read sequence to slave address 48h.  This
> should have been shown something like:

>
>    movlw slave_adr << 1       ;get address byte for read sequence
>
> >  movwf SSPBUF
> >  bank1
> >  btfsc SSPSTAT,R_W          ;Check to see when it's done.
> >   goto $-1
> >  movlw 0x00
> >  btfss _ACKSTAT          ;successful if the ACKSTAT bit is clear. 1 =
> success.
> >   movlw 0x01
> >
> >  bank0
> >
> >  call LCDBin               ;Print either 0 or 1.
>
> You say you don't get an ACK from the slave, but what are the IIC lines
> doing?  Can you see the address byte going out?  Does it look right?
>

>
> *****************************************************************
> Embed Inc, embedded system specialists in Littleton Massachusetts
> (978) 742-9014, http://www.embedinc.com
>
> --
> http://www.piclist.com hint: To leave the PICList
> EraseMEpiclist-unsubscribe-request@spam@mitvma.mit.edu
>

> From: "Brian Smith" <bsmiths2spamBeGoneattbi.com>
> > Well, whatever the attitude of Royce, I appreciate you
> > opening up your source code to the rest of us.  Also,
> > please don't quit contributing to the piclist even if
> > some people don't agree with your style.  While I may
> > or may not agree with every one of your responses, I
> > can unequivocally laud your unstinting gift of time
> > and expertise.
>
> Thanks.
>
> > I may use your I2C routines in the near future, so,
> > thanks!  If I can't figure out how to do I2C with your
> > source snippet and the PIC manuals, I don't deserve to
> > be called a software engineer. :-)
>
> > P.S. Is this message void of the quoted-printable
> > setting?
>
> Yes, and a reply to it worked fine.
>
>
> *****************************************************************
> Embed Inc, embedded system specialists in Littleton Massachusetts
> (978) 742-9014, http://www.embedinc.com
>
> --
> http://www.piclist.com hint: To leave the PICList
> RemoveMEpiclist-unsubscribe-request@spam@spamBeGonemitvma.mit.edu
>

> > This is true - but also keep in mind I am just trying to get the darn
> thing
> > working at this point.
>
> Good comments and style are an integral part of the code, and writing
> comments is an important and useful part of writing code.  Writing good
> comments forces you to explain the purpose of each line, which points out
> most problems before they become bugs.  Comments also show what you
> intended something to do, which is very useful to other people trying to
> help you with bugs.  In the end, writing proper code with good style and
> comments right from the beginning gets you to the desired end faster.
> "Just getting it working" first, then adding comments later doesn't save
> time, it **costs** time.  Also, the vast majority of times I've seen
> people use this method, the comments never do get added later.
>
> > THe way I code, I will get the basics working, and then
> > will proceed to optimize/comment it.
>
> Then you need to fix this first, especially before you ask others for
> help.
>
> > When I end up re-arranging half of the
> > stuff that I write, comments just become useless.
>
> Only if you allow them to or they were bad comments in the first place.
> Again, comments are an integral part of the code.  If the code gets
> modified, the comments need to be modified with it.
>
> > Besides, they aren't causing
> > me the problem right now :-)
>
> WRONG!!  Lack of attention to detail and general misconceptions may well
> be the problem.  Writing good comments as an inseperable part of writing
> the code helps with both of these.
>
> Writing good comments is easy to do but apparently difficult to learn.
> The vast majority (well over 90% in my opinion) of code, including
> professionally written code, is poorly commented.  Doing it right won't
> come overnight, but it will never come without the right attitude (maybe
> that's the hard part to learn?).  Unfortunately most examples, including
> most things I've seen cross this list and everything I've seen from
> Microchip, are poorly commented.  However, that doesn't make it right nor
> is it a valid excuse.  Take a look at lots of source code at
> http://www.embedinc.com/pic for examples of one way to do it right.
>
>
> *****************************************************************
> Embed Inc, embedded system specialists in Littleton Massachusetts
> (978) 742-9014, http://www.embedinc.com
>
> --
> http://www.piclist.com hint: To leave the PICList
> RemoveMEpiclist-unsubscribe-requestspamBeGonemitvma.mit.edu
>

> > Right on, Olin!
> >
> > Ideally, the comments should be written first, then the code filled in
> to
> > do what the comments say!
> >
> > ...
> >
> > Thus endeth today's sermon.
>
> And if the religious arguments don't persuade you, here's a practical one:
>
> One of our current projects is to help a customer get a particular circuit
> board into production.  This is an ISA bus board that lives inside a PC
> running an RTOS which controls a complicated high end mechanical measuring
> system that costs multiple 100s of K$.  The board contains some
> intrumentation analog electronics, 14 bit A/Ds, FIFOs, and other stuff.
> Everything on the board is controlled by an Altera Max 7000 CPLD.  Contact
> with the original designer has been lost, but the schematics and CPLD
> source code are available.
>
> Unfortunately, the original designer didn't write a theory of operation
> document and the CPLD source code is only sparesly commented.  The
> customer is seeing some problems but is having a hard time chasing them
> down because nobody understands how this board works.  We are getting paid
> thousands of dollars just to understand and document every little detail
> of the board's operation, and eventually advise the customer on how to fix
> the problems.  Right now I'm knee deep in the CPLD source code.  I've
> already taken the original 250 line file and expanded it to 650 lines just
> by documenting the inputs and outputs.  I've still got most of the
> internal variables and about half the logic equations left to go.
>
> The moral of the story is bad commenting and documentation costs serious
> money, and that cleaning up other people's bad documentation is
> profitable.
>
>
> *****************************************************************
> Embed Inc, embedded system specialists in Littleton Massachusetts
> (978) 742-9014, http://www.embedinc.com
>
> --
> http://www.piclist.com hint: To leave the PICList
> piclist-unsubscribe-request@spam@mitvma.mit.edu
>

> > But with ASM in PIC's, I am just trying to focus my attention
> >on becoming familiar with as much as I can before I work on
> >my coding style(s). I agree that commenting is an integral
> >part to coding, it's just not everyone can do it all at once.
>
> You will find it a lot easier to get something going properly by writing
> just comments as a pseudo code to get the program flow correct to start
> with, and then intersperse the actual code in between the comments. This way
> it does not matter which language you are using. It may become apparent as
> you write the pseudo code that certain parts are better in an HLL, and
> others better in assembler, but at the pseudo code stage this does not
> matter.
>
> I have found that doing things this way also help to identify portions that
> are best suited to a procedure or subroutine, rather than inline code.
>
> --
> http://www.piclist.com hint: To leave the PICList
> spamBeGonepiclist-unsubscribe-request@spam@mitvma.mit.edu
>

> Well well, despite all this recoding, and recommenting... guess what, still
> no
> work :-( My first question is that is it possible that when I was trying to
> code the routines manually (instead of through the MSSP), could I have
> damaged
> the pins of the TC74? Even though I was getting successful ACK's at that
> point...
> anyway, I'm really running out of options here. Almost considering ordering
> some more TC74's just to make sure that they aren't the problem. I have
> attached my section of code that I am using. The first function, TGetTemp,
> is
> what is called from my main routine.
>
> Any help, as always, is appreciated.
>
> Jai
>
> Quoting "Alan B. Pearce" <spam_OUTA.B.Pearcespam_OUTspam_OUTRL.AC.UK>:
>
> > > But with ASM in PIC's, I am just trying to focus my attention
> > >on becoming familiar with as much as I can before I work on
> > >my coding style(s). I agree that commenting is an integral
> > >part to coding, it's just not everyone can do it all at once.
> >
> > You will find it a lot easier to get something going properly by writing
> > just comments as a pseudo code to get the program flow correct to start
> > with, and then intersperse the actual code in between the comments. This
> way
> > it does not matter which language you are using. It may become apparent as
> > you write the pseudo code that certain parts are better in an HLL, and
> > others better in assembler, but at the pseudo code stage this does not
> > matter.
> >
> > I have found that doing things this way also help to identify portions
> that
> > are best suited to a procedure or subroutine, rather than inline code.
> >
> > --
> > http://www.piclist.com hint: To leave the PICList
> > piclist-unsubscribe-requestspam_OUTmitvma.mit.edu> > >
>
>
>
>
> ----------------------------------------
> This mail sent through http://www.mywaterloo.ca
>
> --
> http://www.piclist.com hint: To leave the PICList
> RemoveMEpiclist-unsubscribe-requestKILLspam@spam@mitvma.mit.edu
>

> Just a tip (and not just to you, Jai :-) )
> > When attaching *anything* that actualy is a text
> file, rename it into .TXT so it can be read easily.
> > My box where I read mail can't open .ASM files...
> > Jan-Erik Söderholm.
> > --
> http://www.piclist.com hint: PICList Posts must start with ONE topic:
> [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
>

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

> ...

>
> ;---------------------------------------------------------------;
> ;                                   ;
> ;                                   ;
> ;                              LOW LEVEL ROUTINES   ;
> ;                                   ;
> ;                                   ;
> ;---------------------------------------------------------------;
>
> ;---------------------------------------------------------------;
> ;                                   ;
> ;  I2CInit                         ;
> ;                                   ;
> ;  Initializes the I2C ports and registers   ;
> ;                                   ;
> ;---------------------------------------------------------------;
>
> I2CInit
>
>  banksel SSPADD
>  movlw 0xff                    ;Holds transmission Using equation SSPADD

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

> 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

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

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

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