Searching \ for '[PIC]: f877 I2C routines' 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: 'f877 I2C routines'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: f877 I2C routines'
2003\02\01@205550 by Jai Dhar

flavicon
face
Hi there all,

  First of all, along with the rest of you, my heart goes out to the seven
brave souls who suffered a great tragedy today. We back home were especially
proud of Kalpana being the first Indian woman in space. May they rest in peace.

Aside from this, 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. I then started to look on MC's web
site for their I2C routines, and came across Application Note 554: Software
implementation of an I2C Bus Master. This seemed to be exactly what I need -
it had good routines for lowlevel/high-level implementation. But there is one
problem... the files they mention in their pdf, i2c_low.asm and i2c_high.asm
don't seem to be part of their source code zip??? So I can't really implement
anything!! does anyone know where I can find theM? Or any other sources that
shows examples of using I2c with an f877 or related...

Any suggestions are appreciated,

Jai





----------------------------------------
This mail sent through http://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

2003\02\02@120338 by Olin Lathrop

face picon face
part 1 1063 bytes content-type:text/plain; (decoded 7bit)

> 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




part 2 11394 bytes content-type:application/octet-stream; (decode)

part 3 2 bytes
-

2003\02\02@195317 by Jai Dhar

flavicon
face
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, 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. I'm almost ready to give up at this point; anyone
have any suggestions? Just for reference, I have my code to Get a Byte from
the TC74.


SDAInput
LoopPoint
call CycleSCLK   ;This cycles the SCLK pin w/ built-in delays
btfss _SDA        ;Test the SDA pin
 movlw 0x00
btfsc _SDA
 movlw 0x01
call LCDBin       ;This function of mine prints out whatever is in W onto an
LCD
call Delay
decfsz counter,f
 goto LoopPoint

Any suggestions at all will be appreciated!

Jai

Quoting Olin Lathrop <spam_OUTolin_piclistTakeThisOuTspamEMBEDINC.COM>:

{Quote hidden}

----------------------------------------
This mail sent through http://www.mywaterloo.ca

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

2003\02\03@081607 by Olin Lathrop

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

2003\02\03@082827 by Jai Dhar

flavicon
face
Quoting Olin Lathrop <.....olin_piclistKILLspamspam@spam@EMBEDINC.COM>:

{Quote hidden}

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.

{Quote hidden}

And yes, on the ninth clock cycle, I set the TRIS bit so that SDA becomes an
input. That's how it seems to get pulled low successfully. Reading the config
register (0x01 instead of 0x00) also returns all 0's. And I know it's getting
the TC74 correctly because I changed the address I was sending out just for
kicks, and I ended up with no ACK. So I must be doing something right :-)


{Quote hidden}

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

2003\02\03@084458 by Olin Lathrop

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

2003\02\03@085737 by Jai Dhar

flavicon
face
Quoting Olin Lathrop <olin_piclistspamKILLspamEMBEDINC.COM>:

{Quote hidden}

My mistake (again). SDA doesn't get pulled low BEACUSE of the TRIS bit. All I
meant was that I know I was setting the TRIS bit at the right time since it
was successfully getting pulled low by the Slave :-) Like I mentioned, when I
changed the address to something not of the slave, it didn't respond by
pulling it low, so that's how I know the TRIS part is ok. I am afraid that it
might be something in my reading sequence that is wrong - but I'm not sure
what.


{Quote hidden}

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

2003\02\03@103356 by Alan B. Pearce

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

2003\02\03@104224 by Jai Dhar

flavicon
face
Quoting "Alan B. Pearce" <.....A.B.PearceKILLspamspam.....RL.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).

{Quote hidden}

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

2003\02\03@110053 by

flavicon
face
What's wrong with the 877 data sheet ?

Jan-Erik Söderholm

Jai Dhar wrote :
>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).

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\03@110643 by

flavicon
face
And the "Midrange ref manual" have even more detailed
information on this subject.

Jan-Erik Söderholm.

{Original Message removed}

2003\02\03@115900 by Jai Dhar

flavicon
face
Those two manuals were my first references to turn to , and the reason why I went software is because in the Mid-range ref manual, page 248 (design tips):
"Question 2: Using I2C mode, I do not seem able to make the master mode work.
Answer: The SSP module does not have the master mode fully automated in hardware. If you require a fully automated hardware implementation of I2C MasteR Mode, please refer to the ...."

This seems to indicate that it is not capable - but reading other paragraphs in the reference indicates that I2C Master Mode can be implemented. I guess I got confused and decided to write my own routines - doing so unsuccessfully thusfar. Either way, I cannot find examples of I2C Master Mode initialization/implementation in either manual.

Quoting "Jan-erik Söderholm (QAC)" <EraseMEJan-erik.Soderholmspam_OUTspamTakeThisOuTPAC.ERICSSON.SE>:

> And the "Midrange ref manual" have even more detailed
> information on this subject.
>
> Jan-Erik Söderholm.
>
> {Original Message removed}

2003\02\03@121120 by Alan B. Pearce

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

2003\02\03@122120 by Olin Lathrop

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

That's probably because it's so easy that very little code is required,
and people don't think of it as being something worthwhile to publish.


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

2003\02\03@122341 by Olin Lathrop

face picon face
>>
Those two manuals were my first references to turn to , and the reason why
I
went software is because in the Mid-range ref manual, page 248 (design
tips):
"Question 2: Using I2C mode, I do not seem able to make the master mode
work.
Answer: The SSP module...
<<

Yes, but the 16F877 has a MSSP module.  The "M" stands for "master".


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

2003\02\03@122756 by Byron A Jeff

face picon face
On Mon, Feb 03, 2003 at 11:57:24AM -0500, Jai Dhar wrote:
> Those two manuals were my first references to turn to , and the reason why I
> went software is because in the Mid-range ref manual, page 248 (design tips):
> "Question 2: Using I2C mode, I do not seem able to make the master mode work.
> Answer: The SSP module does not have the master mode fully automated in
> hardware. If you require a fully automated hardware implementation of I2C
> MasteR Mode, please refer to the ...."
>
> This seems to indicate that it is not capable - but reading other paragraphs
> in the reference indicates that I2C Master Mode can be implemented. I guess I
> got confused and decided to write my own routines - doing so unsuccessfully
> thusfar. Either way, I cannot find examples of I2C Master Mode
> initialization/implementation in either manual.

You got bit by the same issue I did my friend: the 16F877 doesn't have SSP
which is chapter 15 of the midrange manual. It has MSSP which is covered in
a quite long chapter 17. It's way to easy to overlook.

I would suggest that you take some time to go over the chapter and examine
the code. BTW the end of the chapter points to several application notes
on the subject.

BAJ

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\03@122811 by Jai Dhar

flavicon
face
Quoting Olin Lathrop <olin_piclistspamspam_OUTEMBEDINC.COM>:

> >>
> Those two manuals were my first references to turn to , and the reason why
> I
> went software is because in the Mid-range ref manual, page 248 (design
> tips):
> "Question 2: Using I2C mode, I do not seem able to make the master mode
> work.
> Answer: The SSP module...
> <<
>
> Yes, but the 16F877 has a MSSP module.  The "M" stands for "master".
>

Ok, so I know I'm not the smartest cookie around :-) Anyway, I will focus my
efforts on doing it the proper way through the MSSP (good thing I know what it
stands for now) module. Thanks for your all your help (and patience).


{Quote hidden}

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

2003\02\03@130302 by Jai Dhar

flavicon
face
AN735 seems to have everything I was looking for and answers all my questions.
IF I just read chapter 17.... anyway, thank you all once again.

Quoting "Alan B. Pearce" <@spam@A.B.PearceKILLspamspamRL.AC.UK>:

{Quote hidden}

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

2003\02\03@130925 by Henrik Nielsen

flavicon
face
have a' look at
www.microchip.com/download/appnote/pic16/00735a.pdf
this work http://www.microchip.com/download/lit/suppdoc/toots/i2c.pdf
kind regards
   henrik
{Original Message removed}

2003\02\03@153504 by Olin Lathrop

face picon face
From: "Royce Simmons" <KILLspamw2rbnKILLspamspamprodigy.net>
> I wonder if you would send me the include file you used?

Include file to what?  Used where?

Please copy enough of whatever you are replying to into your reply so that
someone can tell what it's about.


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

2003\02\04@050913 by dr. Imre Bartfai

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


{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body

2003\02\04@090526 by Jai Dhar

flavicon
face
I agree. I have been trying the 'simple' way using the MSSP, and still have
had relatively low success. I can still manage to get a successful ACK, but
for some reason, when I read from my Slave, it keeps reading the slave's
address into SSPBUF? Odd. I will keep rying tho.

Quoting "dr. Imre Bartfai" <TakeThisOuTrootEraseMEspamspam_OUTPROF.PMMF.HU>:

{Quote hidden}

----------------------------------------
This mail sent through http://www.mywaterloo.ca

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspammitvma.mit.edu with SET PICList DIGEST in the body

2003\02\04@114903 by Olin Lathrop

face picon face
From: "Royce Simmons" <RemoveMEw2rbnEraseMEspamEraseMEprodigy.net>
> The include file in the routine you attached ti this note.
>
> If it is too much trouble for you then forget about it.

It's not much trouble, but that include file contains things that belong
to a customer and would be inappropriate for me to give out.  That's why I
indicated the one /FLAG directive that I knew the IIC routines would need.

> If you attach something it should be complete.

Well excuuuuuuuuse me.  I don't owe you anything at all.  I did give out a
tested and well documented module that implements an IIC master in
software.  I thought this would be useful too look at as an example, and
didn't present it as something ready to build.  Sorry you didn't think it
was worth the price you got it for.  I was actually thinking of releasing
a stripped down version of the include file to make the IIC module
buildable, but not after your last comment.


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

2003\02\04@120935 by Jai Dhar

flavicon
face
Quoting Olin Lathrop <RemoveMEolin_piclistTakeThisOuTspamspamEMBEDINC.COM>:

> From: "Royce Simmons" <EraseMEw2rbnspamspamspamBeGoneprodigy.net>
> > The include file in the routine you attached ti this note.
> >
> > If it is too much trouble for you then forget about it.
>
> It's not much trouble, but that include file contains things that belong
> to a customer and would be inappropriate for me to give out.  That's why I
> indicated the one /FLAG directive that I knew the IIC routines would need.
>
> > If you attach something it should be complete.
>
> Well excuuuuuuuuse me.  I don't owe you anything at all.  I did give out a
> tested and well documented module that implements an IIC master in
> software.  I thought this would be useful too look at as an example, and
> didn't present it as something ready to build.  Sorry you didn't think it
> was worth the price you got it for.  I was actually thinking of releasing
> a stripped down version of the include file to make the IIC module
> buildable, but not after your last comment.

Thanks a lot buddy, I could have used that module :-)
j/k

{Quote hidden}

----------------------------------------
This mail sent through http://www.mywaterloo.ca

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservSTOPspamspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

2003\02\04@235550 by Jai Dhar

flavicon
face
Ok, I have tried EVERYTHING possible in trying to get this I2C working, but I
can't :-( I have gone back to trying to get a successful ACK now, and can't do
it. Here is the code I'm using below, just to write one byte of data (the
address 1001 0000)... using an 16f877 with Port C pins 3 and 4. And I have
checked all my #define's to make sure they refer to the right thing. Help
PLEASE!!!

TGetTemp

bank1

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

return


Quoting spamBeGoneMartin.BuehlerSTOPspamspamEraseMEKEYMILE.COM:

{Quote hidden}

----------------------------------------
This mail sent through http://www.mywaterloo.ca

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservspam_OUTspammitvma.mit.edu with SET PICList DIGEST in the body

2003\02\05@012432 by Jason Harper

picon face
Jai Dhar wrote:
> movlw 0x09                 ;This will hold our Baud Rate!
> movwf SSPADD

Are you sure you aren't simply running the baud rate too high?  If you have
a 20 MHz clock, I think this setting will produce a 1 MHz I2C rate!  I'd
use a baud rate of 0xFF for testing.

> movlw b'00011000'
> iorwf TRISC,f

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
TakeThisOuTpiclist-unsubscribe-request.....spamTakeThisOuTmitvma.mit.edu>

2003\02\05@020235 by dr. Imre Bartfai

flavicon
face
part 1 385 bytes content-type:TEXT/PLAIN; charset=US-ASCII
Hi All,

attached is a hardware MSSP routine for F87x for your convenience. It is
based on appropriate AN of uChip, here is the structure from. Only the
content is rewritten, though. The CVASM syntax is used, however. But it
works (WRITE is untested, though).

Regards,

Imre


--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestKILLspamspamspammitvma.mit.edu




part 2 7872 bytes content-type:TEXT/PLAIN; charset=iso8859-1; name="EEPROMI2.SRC"
(decoded base64)

; PIC16CXX to 24LC0XB communication code.



; FUSE SETTINGS:

; OSC = XT, WDT = ON



; INTRODUCTION:

; This appliction note is intended to provide users with highly compressed

; assembly code for communication between the EEPROM and the Microcontroller,

; which will leave the user a maximum amount of code space for the core

; application. The built-in I2C peripherial is used.

; This file

; contains the EEPROM subroutines and the constants used in them.  Also

; included but commented out is the EEPROM initialization required before

; calling the subroutines.



; EEPROM SUBROUTINES:

; Write_Byte   - Write data supplied in EEDTA at address supplied in EEADD

; Read_Random  - Read data into EEDTA from address supplied in EEADD

; Read_Current - Read data into EEDTA from address currently in EEPROM

;

;        Program:          EEPROM.ASM

;        Revision Date:

;                          01-29-03        Compatibility with CVASM16 6.0

;

;**********************************************************************

;



;***************************************************************************

;***************************  Variable Listing        ****************************

;***************************************************************************



;----        Constants

;----        Internal Ones

OK        EQU        1

NO        EQU        0

;----        External Ones

;SCL        EQU        Port.x                ; EEPROM Clock, SCL (I/O bit x)

;SDA        EQU        Port.y                ; EEPROM Data,        SDA (I/O bit y)

;----        Variables

       ORG        EE_DATA

PC_OFFSET DS        1                ; PC offset register (low order 4 bits),

                               ;  value based on operating mode of EEPROM.

                               ;  Also, bit 7 used for EE_OK flag

EE_OK        EQU        PC_OFFSET.7        ; Bit 7 in PC_OFFSET used as OK flag for EE



EEADDR        DS        1                ; EEPROM Address

EEDTA        DS        1                ; EEPROM Data

EEBYTE        DS        1                ; Byte sent to or received from

                               ; EEPROM (control, address, or data)

EE_DATA_END EQU        $



       ORG        EE_CODE

;***************************************************************************

;***************************  EEPROM Subroutines  **************************

;***************************************************************************

; Communication for EEPROM based on I2C protocoll, with Acknowledge.

;

; Byte_Write: Byte write routine

;        Inputs:  EEPROM Address   EEADDR

;                 EEPROM Data          EEDTA

;        Outputs: Return 01 in W if OK, else return 00 in W

;

; Read_Current: Read EEPROM at address currently held by EE device.

;        Inputs:  NONE

;        Outputs: EEPROM Data           EEDTA

;                 Return 01 in W if OK, else return 00 in W

;

; Read_Random: Read EEPROM byte at supplied address

;        Inputs:  EEPROM Address    EEADDR

;        Outputs: EEPROM Data           EEDTA

;                 Return 01 in W if OK, else return 00 in W

;

; Note: EEPROM subroutines will set bit 7 in PC_OFFSET register if the

;        EEPROM acknowledged OK, else that bit will be cleared.        This bit

;        can be checked instead of refering to the value returned in W

;***************************************************************************



;********************** Set up EEPROM control bytes ************************

;***************************************************************************

READ_CURRENT Mov PC_OFFSET,#85h        ; PC offset for read current addr

                               ; Load PC offset with set EE_OK

       Mov        W,#10100001b        ; Set up read control byte, ready to send to EEPROM

       Jmp        START_BIT        ; bit 0 = '1' for read operation



WRITE_BYTE Mov        W,#80h                ; PC offset for write byte.  EE_OK set

       Jmp        INIT_WRITE_CONTROL



REPTD_START SetB RP0                ; Bank #1

       SetB        RSEN                ; Repeated Start

:here        JB        RSEN,:here        ; wait until cleared

       ClrB        RP0                ; back to Bank #0

       Jmp        PREP_TRANSFER_BYTE



READ_RANDOM Mov W,#83h                ; PC offset for read random.  EE_OK set



INIT_WRITE_CONTROL Mov PC_OFFSET,W ; Load PC offset register, value preset in W

       Mov        W,#10100000b        ; Control byte with write bit, bit 0 = '0'



START_BIT ClrB        WCOL                ; for security reason

       SetB        RP0                ; Bank #1

       ClrB        BF                ; set initial condition

       SetB        SEN                ; start condition

:here        JB        SEN,:here        ; will be cleared by hardware

       ClrB        RP0                ; Back to Bank #0



;******* Set up output data (control, address, or data) ********************

;***************************************************************************

PREP_TRANSFER_BYTE ClrB        SSPIF        ; clear IT flag

       Mov        SSPBUF,W ; Byte to transfer to EEPROM already in W

;************  Clock out data (control, address, or data) byte        ************



;**************************  Acknowkedge Check *****************************

;***************************************************************************

OUTPUT_BYTE JNB        SSPIF,OUTPUT_BYTE ; wait for 9th bit transferred

       ClrB        SSPIF                ; clear byte

       SetB        RP0                ; Select Bank #1

       Mov        W,SSPCON2        ; fetch ACk register

       ClrB        RP0

       And        W,#01000000b        ; pos of ACK bit

       SZ                        ; Check for acknowledge (low)

       ClrB        EE_OK                ; If ACKSTAT high (no ack), set error flag

       JNB        EE_OK,STOP_BIT        ; If no error continue, else stop bit



;*****        Set up program counter offset, based on EEPROM operating mode  *****

;***************************************************************************

       Mov        PCLATH,#$<

       Mov        W,PC_OFFSET

       And        W,#00001111b

       Jmp        PC+W

       Jmp        INIT_ADDRESS        ;PC offset=0, write control done, send address

       Jmp        INIT_WRITE_DATA        ;PC offset=1, write address done, send data

       Jmp        STOP_BIT        ;PC offset=2, write done, send stop bit

       Jmp        INIT_ADDRESS        ;PC offset=3, write control done, send address

       Jmp        INIT_READ_CONTROL ;PC offset=4, send read control

       Jmp        READ_BYTE       ;PC offset=5, set counter and read byte

       Jmp        STOP_BIT        ;PC offset=6, random read done, send stop



;**********  Initalize EEPROM data (address, data, or control) bytes  ******

;***************************************************************************

INIT_ADDRESS Inc PC_OFFSET        ; Increment PC offset to 2 (write) or to 4 (read)

       Mov        W,EEADDR        ; Put EEPROM address in W, ready to send to EEPROM

       Jmp        PREP_TRANSFER_BYTE



INIT_WRITE_DATA Inc PC_OFFSET        ; Increment PC offset to go to STOP_BIT next

       Mov        W,EEDTA                ; Put EEPROM data in W, ready to send to EEPROM

       Jmp        PREP_TRANSFER_BYTE



INIT_READ_CONTROL

       Inc        PC_OFFSET        ; Increment PC offset to go to READ_BIT_COUNTER next

       Mov        W,#10100001b        ; Set up read control byte, ready to send to EEPROM

;        Jmp        START_BIT        ; bit 0 = '1' for read operation

       Jmp        REPTD_START



;**************************  Read EEPROM data  *****************************

;***************************************************************************

READ_BYTE SetB RP0                ; Bank #1

       ClrB        BF                ; set initial condition

       SetB        RCEN                ; receive enable

:here        JB        RCEN,:here        ; wait until data read

;        SetB        ACKDT                ; NO ACK

;        SetB        ACKEN                ; same

       ClrB        RP0                ; back to Bank #0

       Mov        EEDTA,SSPBUF        ; fetch read data

;******************  Generate a STOP bit and RETURN  ***********************

;***************************************************************************

STOP_BIT SetB        RP0                ; Bank #1

       SetB        PEN                ; initiate stop condition

       ClrB        RP0                ; back to Bank #0

:here        JNB        SSPIF,:here        ; wait until complete

       ClrB        SSPIF

       SB        EE_OK                ; Check for error

       RetW        NO                ; if error, send back NO

       RetW        OK                ; if no error, send back OK



;Note: SDA and SCL still being driven by master, both set to outputs.

;****************************************************************************

;************************  End EEPROM Subroutines  **************************





;***************************  Initalize EEPROM        ****************************

;***************************************************************************

EE_START SetB        RP0

       SetB        SCL                ; SDA and SCL = output

       SetB        SDA

       ClrB        SMP                ; slew rate control enabled

       ClrB        CKE                ; IıC conformity

       Mov        SSPADD,#16        ; divisor for cca 60kHz @ 4MHz

       ClrB        RP0

       Mov        SSPCON,#00101000b

       Ret


part 3 2 bytes
-

2003\02\05@075126 by Jai Dhar

flavicon
face
Quoting Jason Harper <.....JasonRandHarperspamRemoveMECOMPUSERVE.COM>:

> Jai Dhar wrote:
> > movlw 0x09                 ;This will hold our Baud Rate!
> > movwf SSPADD
>
> Are you sure you aren't simply running the baud rate too high?  If you have
> a 20 MHz clock, I think this setting will produce a 1 MHz I2C rate!  I'd
> use a baud rate of 0xFF for testing.
>

On a 4 MHZ OSC however, it's not too fast at all.

> > movlw b'00011000'
> > iorwf TRISC,f
>

This piece of code, I only used because I was trying to follow AN735 as close
as possible after it wouldn't work my way - but trust me, I did it just using
bsf before.. still didn't work. And don't worry, I dont make it a habit doing
it this way - I personally dislike it :-)

{Quote hidden}

----------------------------------------
This mail sent through http://www.mywaterloo.ca

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-request@spam@spamspam_OUTmitvma.mit.edu>

2003\02\05@082927 by Olin Lathrop

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

I would also have initialized SSPCON2 before enabling the MSSP.

>  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
TakeThisOuTpiclist-unsubscribe-requestspamspammitvma.mit.edu>

2003\02\05@083758 by Olin Lathrop

face picon face
From: "Brian Smith" <bsmiths2EraseMEspamattbi.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-requestEraseMEspamspam_OUTmitvma.mit.edu>

2003\02\05@084016 by Jai Dhar

flavicon
face
Quoting Olin Lathrop <@spam@olin_piclistRemoveMEspamEraseMEEMBEDINC.COM>:

{Quote hidden}

This is true - but also keep in mind I am just trying to get the darn thing
working at this point. THe way I code, I will get the basics working, and then
will proceed to optimize/comment it. When I end up re-arranging half of the
stuff that I write, comments just become useless. Besides, they aren't causing
me the problem right now :-)

> I would also have initialized SSPCON2 before enabling the MSSP.
>

I wil try this.


{Quote hidden}

And I am also aware of this - as I said, just trying to see if it will work
now. I can then proceed to do all the fancy stuff to make it a better generic
library.

{Quote hidden}

And this - how would I check it? I mean the data goes out too fast for me to
watch with a DMM. It's not like my first attempt when I wrote the routines
myself and I could slow it down to a point where I could watch what it was
doing. So I'm not sure how I would watch for activity on these lines.

Btw: regarding the pullup's that should be on SCLK/SDA - are 2.7k ones ok? I
was reading the Philips I2C spec, and they recommended a MIN of 1.7k for +Vdd
= 5V , so I figure 2.7 was ok. I did also try 5k though.


{Quote hidden}

----------------------------------------
This mail sent through http://www.mywaterloo.ca

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestspam_OUTspam.....mitvma.mit.edu>

2003\02\05@084018 by Jai Dhar

flavicon
face
Just a question - how come I'm not seeing half of these messages (ie: the one
below, I didn't get it). Was it sent privately, or is just swarming through
the hordes of piclist email a tough job to do!

Quoting Olin Lathrop <spamBeGoneolin_piclistEraseMEspamEMBEDINC.COM>:

{Quote hidden}

----------------------------------------
This mail sent through http://www.mywaterloo.ca

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-request@spam@spamEraseMEmitvma.mit.edu>

2003\02\05@094038 by Olin Lathrop

face picon face
> This is true - but also keep in mind I am just trying to get the darn
thing
> working at this point. THe way I code, I will get the basics working,
and then
> will proceed to optimize/comment it. When I end up re-arranging half of
the
> stuff that I write, comments just become useless. Besides, they aren't
causing
> me the problem right now :-)

Argh!!!

This is one of the most irresponsible statements I've read recently.  I
was really trying to help you until now, but this attitude only deserves
contempt (and contempt for those who taught you to program and let you get
away with this attitude problem).  Let's take this one fallacy at a time:

> 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
.....piclist-unsubscribe-requestRemoveMEspammitvma.mit.edu>

2003\02\05@094046 by Olin Lathrop

face picon face
> Just a question - how come I'm not seeing half of these messages (ie:
the one
> below, I didn't get it). Was it sent privately, or is just swarming
through
> the hordes of piclist email a tough job to do!

Unfortunately sometimes people send mail to me privately when it's not
really a private issue.  One way I discourage it is to respond publicly,
if at all.


*****************************************************************
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-requestSTOPspamspam@spam@mitvma.mit.edu>

2003\02\05@095235 by Jai Dhar

flavicon
face
Quoting Olin Lathrop <olin_piclistEraseMEspam@spam@EMBEDINC.COM>:

> > This is true - but also keep in mind I am just trying to get the darn
> thing
> > working at this point. THe way I code, I will get the basics working,
> and then
> > will proceed to optimize/comment it. When I end up re-arranging half of
> the
> > stuff that I write, comments just become useless. Besides, they aren't
> causing
> > me the problem right now :-)
>
> Argh!!!
>
> This is one of the most irresponsible statements I've read recently.  I
> was really trying to help you until now, but this attitude only deserves
> contempt (and contempt for those who taught you to program and let you get
> away with this attitude problem).  Let's take this one fallacy at a time:
>

Woa there.... I don't mean my poor commenting styles to be of offense to
anyone, including you, so please don't take any. Granted I realize that my
commenting styles aren't the best - but I am relatively new to PIC's and ASM.
Had I been coding in a language I'm much more comfortable with, C for example,
I would be doing everything as you suggested - but that is because I have had
time to learn what works for me and what doesn't, and how I can comment my
code best so that both I and others can understand it thoroughly. 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.
Sorry if my bad habits have offended you :-) I will try and comment better
before posting. But like I said, good-commenting style is a neccessity
(especially in ASM), and is one that I have overlooked recently. My apologies.
With my specific case here, it just seems like I am missing something in my
code, rather than doing something wrong since I have derived most of it from
Microchip's documentation.


{Quote hidden}

----------------------------------------
This mail sent through http://www.mywaterloo.ca

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu>

2003\02\05@102523 by Olin Lathrop

face picon face
> 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 that forcing yourself to write good comments will help you
learn the processor and the language more quickly.  Good comments don't
cost time, they save time, whether you are familiar with the environment
or not.


*****************************************************************
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-requestspam_OUTspam@spam@mitvma.mit.edu>

2003\02\05@103455 by Larry Bradley

flavicon
face
Right on, Olin!

Ideally, the comments should be written first, then the code filled in to
do what the comments say!

I spent MANY years as an assembler programmer for IBM mainframes,
maintaining and modifying the operating system. High-level languages may be
self-commenting (hah!) but assembler sure isn't. Without good comments
telling me what the original programmer THOUGHT he was doing, I'd have had
to spend a lot more time figuring things out. And of course, if the
comments aren't kept up to date, things go to hell in a handbasket quite
quickly! Because we tend to believe the comments, rather than figure out
the code. Nothing is worse than comments saying "If the input value is
greater than 20, then ..." while the code is comparing against 15.

Even if you are writing test code, you should comment it. Assembler is
non-obvious, even if you have been doing it for years. It is a 'write-only'
language :)  A day later, a perfectly obvious piece of code can be
completely unreadable.

Comments should tell you what the code does, and WHY it does it. Comments
such as "increment x by 1" are not terribly useful.

The two things programmers hate above all else are documenting and
commenting. Skip the former if you must; be lavish with the latter.

Thus endeth today's sermon.



Larry Bradley
Orleans (Ottawa), Ontario, CANADA

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-request@spam@spammitvma.mit.edu>

2003\02\05@105657 by Alan B. Pearce

face picon face
> 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
RemoveMEpiclist-unsubscribe-requestEraseMEspamKILLspammitvma.mit.edu>

2003\02\05@112834 by Olin Lathrop

face picon face
> 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
spamBeGonepiclist-unsubscribe-requestspam_OUTspamRemoveMEmitvma.mit.edu>

2003\02\05@114910 by Jai Dhar

flavicon
face
Ok ok ok, so now that you guys have made me truly feel like a horrible person
on the inside, I have redone my ASM file and commented every bit of
commentable code, and then some. I hope it helps me when debugging this thing.

Quoting Olin Lathrop <.....olin_piclistspamRemoveMEEMBEDINC.COM>:

{Quote hidden}

----------------------------------------
This mail sent through http://www.mywaterloo.ca

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

2003\02\05@185911 by Jai Dhar

flavicon
face
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" <RemoveMEA.B.PearceKILLspamspamTakeThisOuTRL.AC.UK>:

{Quote hidden}

----------------------------------------
This mail sent through http://www.mywaterloo.ca

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

2003\02\05@190048 by Jai Dhar

flavicon
face
part 1 2522 bytes content-type:text/plain; charset=ISO-8859-1 (unknown type 8bit not decoded)

Ooops, actually forgot the file :-)

Quoting Jai Dhar <jdharspamspamENGMAIL.UWATERLOO.CA>:

{Quote hidden}

----------------------------------------
This mail sent through http://www.mywaterloo.ca

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamBeGonespam.....mitvma.mit.edu




part 2 5219 bytes content-type:text/plain; name="i2c.asm"
(decoded base64)



#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                        

movlw 0x01                        ;Output the config register (0x01) as the destination for the write command
call I2CWrite

call I2CStartBit                ;Send another start bit

movlw b'10010001'                ;Send the address with a read bit.
;Data:  1001000-                The address of the Slave: 1001 000
;       -------1                Send a read bit for reading the register.
call I2CWrite

call I2CRead                        ;Read the data from the port.
call LCDBinFull                ;Display it on the LCD

call I2CStopBit                ;Send Stop Bit.

return

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

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.
bsf _SDA_TRIS                        ;SDA = Pin 4 , Port C
bsf _SCLK_TRIS                        ;SCLK = Pin 3, Port C

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


;---------------------------------------------------------------;
;                                                                ;
;   I2CRead                                                          ;
;                                                                ;
;   Inputs: Reads one byte from slave device                        ;
;   Outputs: W register will contain the read data                ;
;                                                                ;
;---------------------------------------------------------------;

I2CRead

banksel SSPCON2
bsf _RCEN                        ;Bank 1 - SSPCON2, bit 3. Enables Rx of one byte

                               ;Check to see when Read is completed
btfsc SSPCON2,RCEN                ;RCEN will be clear when READ is completed
 goto $-1
 
banksel SSPBUF
movf SSPBUF,w                        ;SSBUF will contain the read data.

banksel SSPCON2
bsf _ACKDT                        ;Send the NACK Sequence
bsf _ACKEN

bank0

call LCDBinFull                ;---------------------------------------;
                               ;  For TESTING purposes                        ;
                               ;  Call LCDBin to display value in W        ;
                               ;---------------------------------------;

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

return

;------------------------------------------------------------;
;                                                             ;
;    I2CStopBit                                                     ;
;                                                             ;
;    Inputs: None                                             ;
;    Outputs: Sends a stop bit to slave                     ;
;                                                             ;
;-------------------------------------------------------------


I2CStopBit

banksel SSPCON2
bsf _PEN                        ;Enable Tx of Stop Bit (P)

btfsc _PEN                        ;Test for completion
 goto $-1
bank0

return











part 3 2 bytes
-

2003\02\06@035006 by

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

2003\02\06@083957 by Jai Dhar

flavicon
face
part 1 856 bytes content-type:text/plain; charset=ISO-8859-1 (decoded quoted-printable)

My bad :-) I have re-attached.

Thanks,

Jai

Quoting "Jan-erik Söderholm (QAC)" <KILLspamJan-erik.Soderholmspam.....PAC.ERICSSON.SE>:

{Quote hidden}

----------------------------------------
This mail sent through http://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




part 2 5219 bytes content-type:text/plain; name="i2c.txt"
(decoded base64)



#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                        

movlw 0x01                        ;Output the config register (0x01) as the destination for the write command
call I2CWrite

call I2CStartBit                ;Send another start bit

movlw b'10010001'                ;Send the address with a read bit.
;Data:  1001000-                The address of the Slave: 1001 000
;       -------1                Send a read bit for reading the register.
call I2CWrite

call I2CRead                        ;Read the data from the port.
call LCDBinFull                ;Display it on the LCD

call I2CStopBit                ;Send Stop Bit.

return

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

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.
bsf _SDA_TRIS                        ;SDA = Pin 4 , Port C
bsf _SCLK_TRIS                        ;SCLK = Pin 3, Port C

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


;---------------------------------------------------------------;
;                                                                ;
;   I2CRead                                                          ;
;                                                                ;
;   Inputs: Reads one byte from slave device                        ;
;   Outputs: W register will contain the read data                ;
;                                                                ;
;---------------------------------------------------------------;

I2CRead

banksel SSPCON2
bsf _RCEN                        ;Bank 1 - SSPCON2, bit 3. Enables Rx of one byte

                               ;Check to see when Read is completed
btfsc SSPCON2,RCEN                ;RCEN will be clear when READ is completed
 goto $-1
 
banksel SSPBUF
movf SSPBUF,w                        ;SSBUF will contain the read data.

banksel SSPCON2
bsf _ACKDT                        ;Send the NACK Sequence
bsf _ACKEN

bank0

call LCDBinFull                ;---------------------------------------;
                               ;  For TESTING purposes                        ;
                               ;  Call LCDBin to display value in W        ;
                               ;---------------------------------------;

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

return

;------------------------------------------------------------;
;                                                             ;
;    I2CStopBit                                                     ;
;                                                             ;
;    Inputs: None                                             ;
;    Outputs: Sends a stop bit to slave                     ;
;                                                             ;
;-------------------------------------------------------------


I2CStopBit

banksel SSPCON2
bsf _PEN                        ;Enable Tx of Stop Bit (P)

btfsc _PEN                        ;Test for completion
 goto $-1
bank0

return











part 3 2 bytes
-

2003\02\06@084002 by Olin Lathrop

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

{Quote hidden}

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.

{Quote hidden}

= (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.
{Quote hidden}

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 ;
>
;---------------------------------------;
{Quote hidden}

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

2003\02\06@084003 by Olin Lathrop

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

Look at the IIC lines and see whether the address byte is getting out
there right.  The easiest way to do this is to put the code in a loop
where it does start, send address byte, wait a little.  That should allow
you to see the what is going on with an ordinary oscilloscope.  Then
you'll know whether the transmitter or the receiver is at fault.  Of
course if you have a logic analyzer, you can just use it directly.  Do you
have the ICE-2000?  It comes with 8 bits of logic analyzer that is
suitable for this purpose.


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

2003\02\06@085229 by Jai Dhar

flavicon
face
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 <spam_OUTolin_piclistspamKILLspamEMBEDINC.COM>:

{Quote hidden}

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.

{Quote hidden}

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.

{Quote hidden}

Reading the datasheet, SSPCON2 is initialized automatically to 0x00 on POR -
isn't this sufficient, or should I add it anyway?

{Quote hidden}

----------------------------------------
This mail sent through http://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

2003\02\06@091646 by Olin Lathrop

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

If you are going to do this kind of thing, or just about any electronics,
get an oscilloscope.  You can get good used and refurbished scopes for a
few hundred $$, sometimes less if you spend a lot of time scrounging
around.


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

2003\02\14@060931 by Eric Bohlman

picon face
2/5/03 10:47:09 AM, Jai Dhar <RemoveMEjdharRemoveMEspamEraseMEENGMAIL.UWATERLOO.CA> wrote:

>Ok ok ok, so now that you guys have made me truly feel like a horrible person
>on the inside, I have redone my ASM file and commented every bit of
>commentable code, and then some. I hope it helps me when debugging this thing.

I hope this is just rhetorical exaggeration.  Nobody's been slamming you personally.  They've just
been warning you (sometimes rather strongly) not to fall into certain very common traps.  Possibly a
reason that the warnings are so strong is that they're coming from people who once fell into those
traps themselves and wound up wasting a lot of time (and possibly money) pulling themselves out.
They're giving you an opportunity to learn from their own experiences, to get up to speed faster
than they did.  Such an opportunity is extremely valuable.

In his classic _The Psychology of Computer Programming_, Gerald Weinberg asserted, with what I
believe to be good evidence, that programmers who don't take criticism of their code personally will
write better code than those who do.  Because if you view any flaw in your code as a personal flaw,
your automatic, practically unconscious inclination is going to be to avoid looking for flaws in
your code.  And humans have a vastly overdeveloped capacity for not seeing what they don't want to
see.

(Two other reasons not to invest too much of your ego in your code: 1) If you and the processor have
an argument over what your code should mean, the processor will always win it.  2) It's very often
the case that you spend a lot of time writing some code, creating what you might regard as a genuine
masterpiece, and then a change in requirements forces you to scrap most or all of it.)

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservspamspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body

2003\02\14@063650 by Eric Bohlman

picon face
2/6/03 7:52:15 AM, Jai Dhar <jdharspamspamENGMAIL.UWATERLOO.CA> wrote:

> 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

I second Olin's advice that you should make getting your hands on a scope a priority.  Not only
will it make some things that are currently impossible for you possible, it will make many things
that are currently frustrating seem enjoyable.  It will help you work smarter rather than harder.

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

Safety is the right term.  The more assumptions you make about which banks are set, the more
likely your code is to fall apart when you make an apparently minor change.  Times when your code
is rapidly changing (because you're trying to get it to work) are the times when it's most
important to set everything explicitly.  You can always "optimise" later on when the code is in
its final form, *if* that would gain you anything (unless your total code is only a few bytes over
the chip's capacity or only a few microseconds too slow, it usually won't).

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

Relying on power-up settings more than you absolutely have to is, IMHO, poor practice.  For one
thing, you might wind up porting your code to a different chip that has different powerup
defaults.  For another, you might add some code somewhere else that changes one of the settings
from its default.  A *very* large percentage of bugs are the result of assumptions about the
default values of memory, SFRs, and the like that turn out to be incorrect.  Many of those bugs
are *very* hard to track down because they result in code that works *sometimes*.  They often
result in "action at a distance" where one part of your code stops working as a result of a change
you made somewhere else, usually in a part that at first glance is completely unrelated to the
code that breaks.  Many of the principles of good software engineering are based on minimizing the
chances for action at a distance.

(22 years ago I was working on the code for a cash register that interfaced to gas pumps.  I had
made some changes to some code dealing with obtaining credit-card authorization, and I made an
assumption about the initial value of a task's stack pointer.  The new authorization routines
worked just fine, but the code that was supposed to flash a light and beep five times when a
customer lifted the pump handle suddenly stopped working.  When the customer lifted the handle
(OK, when I flipped the toggle switch on the mockup interface board), the printer would spit out
five lines of gibberish.  At exactly the proper cadence for the beeps.)

It's true that in embedded programming, as opposed to desktop programming, you sometimes *do* have
to "micro-optimise" by writing tricky code or eliminating redundant initializations.  But it's not
enough to know *how* to micro-optimise; you also have to know *when* and, most importantly, *when
not* to do it.  And the time when you're trying to get things working is *never* the right time to
micro-optimise.  Making it right has to come before making it smaller or making it faster.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspamBeGonespamRemoveMEmitvma.mit.edu with SET PICList DIGEST in the body

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