Searching \ for '[PIC:] MSSP module' 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/microchip/devices.htm?key=pic
Search entire site for: 'MSSP module'.

Exact match. Not showing close matches.
PICList Thread
'[PIC:] MSSP module'
2004\06\25@073205 by Jinx

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

I think I've got the basics of the MSSP module licked. Can
someone critique this code and results please. 9th clock
pulses are marked, $55 is sent out, $55 comes back so I'm
reasonably confident

TIA

============================================

i2c      mov     b'00101000',sspcon1
;                    1               SSPEN
;                      1000          master

        mov     b'10000000',sspstat
;                  1                 slew rate off

        mov     0x61,sspadd   ;I2C baud rate, 100kHz @ 39.3216MHz

;write/read $55

        bsf     startb        ;start bit
        btfsc   startb
        bra     $-2

        mov     0xa0,sspbuf   ;slave address, write mode
        btfsc   sspstat,r_w
        bra     $-2

        mov     0x01,sspbuf   ;word address MSB
        btfsc   sspstat,r_w
        bra     $-2

        mov     0x23,sspbuf   ;word address LSB
        btfsc   sspstat,r_w
        bra     $-2

        bcf     pir1,sspif
        mov     0x55,sspbuf   ;send data
        btfsc   pir1,sspstat,r_w
        bra     $-2

        bcf     pir1,sspif     ;wait for ACK
        btfss   pir1,sspif
        bra     $-2

        bsf     stopb         ;stop bit
        btfsc   stopb
        bra     $-2

        call    ms05          ;5ms write cycle delay

;===============================================

        bsf     startb        ;start bit
        btfsc   startb
        bra     $-2

        mov     0xa0,sspbuf   ;slave address, write mode
        btfsc   sspstat,r_w
        bra     $-2

        mov     0x01,sspbuf   ;word address MSB
        btfsc   sspstat,r_w
        bra     $-2

        bcf     pir1,sspif
        mov     0x23,sspbuf   ;word address LSB
        btfsc   sspstat,bf
        bra     $-2

        btfss   pir1,sspif     ;wait for ACK
        bra     $-2

        bsf     stopb         ;stop bit
        btfsc   stopb
        bra     $-2

        bsf     startb        ;start bit
        btfsc   startb
        bra     $-2

        mov     0xa1,sspbuf   ;slave address, read mode
        btfsc   sspstat,r_w
        bra     $-2

        bsf     sspcon2,rcen  ;enable reception
        btfss   sspstat,bf
        bra     $-2

        bcf     pir1,sspif
        bsf     sspcon2,ackdt ;send NACK
        bsf     sspcon2,acken
        btfss   pir1,sspif
        bra     $-2
        bcf     pir1,sspif

        bsf     stopb         ;stop bit
        btfsc   stopb
        bra     $-2

        btfss   pir1,sspif     ;wait for ACK
        bra     $-2

        movfw   sspbuf        ;store received byte
        movwf   dg1

==============================================
Research is what I'm doing when I don't know what I'm doing
- Wernher von Braun

--
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 3587 bytes content-type:image/gif; (decode)

2004\06\25@074909 by Jinx

face picon face
BTW, before anyone else spots it

        bcf     pir1,sspif
        mov     0x55,sspbuf   ;send data
        btfsc   pir1,sspstat,r_w
        bra     $-2

somehow got corrupted from

        bcf     pir1,sspif
        mov     0x55,sspbuf   ;send data
        btfsc   pir1,sspif
        bra     $-2

I have an idea it was a copy/paste error in the original after
compilation - must have been why I got asked to save changes

==============================================
Research is what I'm doing when I don't know what I'm doing
- Wernher von Braun

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\06\25@080153 by hael Rigby-Jones

picon face
>-----Original Message-----
>From: Jinx [spam_OUTjoecolquittTakeThisOuTspamCLEAR.NET.NZ]
>Sent: 25 June 2004 12:32
>To: .....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU
>Subject: [PIC:] MSSP module
>
>         bcf     pir1,sspif
>         mov     0x55,sspbuf   ;send data
>         btfsc   pir1,sspstat,r_w
>         bra     $-2
>
>         bcf     pir1,sspif     ;wait for ACK
>         btfss   pir1,sspif
>         bra     $-2
>

I'm a little surprised that this works.  The SSPIF bit gets set at the same
time that RW gets cleared, which is on the falling edge of the acknowledge
clock pulse.  Unless I have missed something, you are clearing SSPIF
directly after it has been set, and are then waiting for it to be set again.

Regards.

Mike




=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to
postmasterspamKILLspambookham.com.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\06\25@090133 by Jinx

face picon face
> >         bcf     pir1,sspif
> >         mov     0x55,sspbuf   ;send data
> >         btfsc   pir1,sspstat,r_w
> >         bra     $-2

> I'm a little surprised that this works

And you'd be right. I did spot that it was not the same as
the original .asm. pir1,sspif is what it should be

I tried it just out of interest, and btfsc pir1,sspstat,r_w actually
compiles to btfsc  pir1,pspif. Which doesn't work

Anyway, apart from that little hiccup, look OK ?

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\06\25@092925 by hael Rigby-Jones

picon face
{Quote hidden}

You know, I hadn't even spotted that there were three operands!  The point I
was really trying to make was about the next section of code that waits for
sspif to be set: (my comments)

bcf     pir1,sspif      ; clear interrupt flag
mov     0x55,sspbuf     ; load SSPBUF with data to be sent
btfsc   pir1,sspif      ; wait for data to be sent
bra     $-2                     ; data not sent, keep checking

At this point the PIC has clocked the ACK bit in, RW will be clear and SSPIF
will be set

bcf     pir1,sspif      ; clear interrupt flag
btfss   pir1,sspif      ; is interrupt flag set?
bra     $-2                     ; not yet, keep trying

The last three instructions would seem (to me) to cause an endless loop.
The PIC has set the interrupt flag when the data has been clocked out and
the ACK bit clocked in.  You then clear the interrupt flag and wait for it
to be set again, but with nothing in SSPBUF that interrupt is not going to
happen.  I may be missing something...

Regards

Mike




=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to
postmasterspamspam_OUTbookham.com.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\06\25@094143 by Jinx

face picon face
>  I may be missing something...

I promise you it does work as advertised and did feel I had
a match between the instructions, analyser o/p and manual
timing diagrams

Over the w/e I'll be double-checking just to be sure. If there's
anything lurking in a dark corner I'd like to find it and not build
the actual app code on a wonky base

Thanks for taking a look

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\06\25@221854 by Jinx

face picon face
> The last three instructions would seem (to me) to cause an
> endless loop. The PIC has set the interrupt flag when the
> data has been clocked out and the ACK bit clocked in.  You
> then clear the interrupt flag and wait for it to be set again, but
> with nothing in SSPBUF that interrupt is not going to
> happen.  I may be missing something...

Think it happened to work because sspif had not been cleared
beforehand and was still set from a previous operation

I've had a go at cleaning it up, mainly removing superfluous and,
for this test, unnecessary usagage of sspif

http://home.clear.net.nz/pages/joecolquitt/mssp_i2c.html

It looks pretty succinct and the result is what I want. Hopefully
all the ducks are lined up now

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\06\26@002229 by Ken Pergola

flavicon
face
Hi Neil,

One thing that I think is a good idea (to try to make I2C code as robust as
possible) when testing master I2C code is to short the SDA and SCL line to
ground (in all 3 combinations) and see if your code accounts for situations
like this. In many cases you want to avoid the possibility of infinite loops
in your code, and therefore you want to implement timeouts in situations
where infinite loops might occur. Or you might have to use Fido the watchdog
timer at a minimum.

Some other ideas:

1) With the PIC MSSP module it's a good idea to check for MSSP idle state
before initiating any I2C event

2) Break down the I2C events into small functions (return some sort of
PASS/FAIL code -- you'll thank yourself in the future when you build
higher-level I2C applications). Yes, there will be function CALL/RETURN
overhead (slower than inline code), but you gain modularity and readability.

3) Don't forget about the write collision and bus collision flags

I realize you are writing in assembly language, but the logic in these
headerless C code snippets I wrote should give you an idea. There is no
reason why they can't be ported to raw assembly language. I'm not very good
(ignoramus) at posting PICLIST code without it getting mangled, so hopefully
the following does not look like a tornado hit it -- I promise you it looks
fine in my C source code editor.

Please note that this code I wrote could *definitely* be improved (all code
can be, right? :)). In the entire I2C routines I wrote, I'm not sure how
well my timeout values will handle clock stretching, multi-master etc.
Thanks to the MSSP module I feel it's easier to write I2C code than
bit-banging (I've done both), but whether bit-banging or using the module,
it's much harder to make it as *robust* as possible -- that's always the
trickiest part -- the devil's always in the details. Just remember that I2C
low-level routines are your "concrete" and foundation. The more time you
spend and the better the foundation is, you'll have a much more solid
higher-level application. Having function return codes that "bubble up" to
your top layers are very useful for robust code.

Anyway, have fun (the MSSP module is a blast), and hope some of these ideas
will be useful.






// FUNCTION: I2C_StopCondition
//           -----------------
//
// Attempts to generates an I2C STOP condition on the bus


unsigned char I2C_StopCondition(void)
{

       // Checks for MSSP engine idle state
       if ( I2C_EngineIdleCheck() == FAIL )
       {
               return FAIL;
       }

       SSPIF = 0;                              // Clear SSP event flag
       BCLIF = 0;                              // Clear Bus collision flag

       PEN = 1;                                // Initiate a STOP condition on SDA and SCL pins.
                                               // (automatically cleared by hardware)


       // If I2C event does not fire, exit with FAIL code

       if ( I2C_EngineInterruptConditionTimeoutCheck() == FAIL )
       {
               return FAIL;
       }


       // Exit with FAIL code if there is a bus collision OR a stop condition was
not detected last
       if ( ( BCLIF == 1 ) || ( STAT_P == 0 ) )
       {
               return FAIL;
       }

       return PASS;

}





// FUNCTION: I2C_EngineIdleCheck
//           -------------------
//
// Indicates whether the MSSP module is idle or not


unsigned char I2C_EngineIdleCheck(void)
{
       // Test R_W, ACKEN, RCEN, PEN, RSEN, and SEN
       // and exit with fail code if any of these bits are 1 (not idle)

       if ( ( STAT_RW == 1 ) || ( ACKEN == 1 ) || ( RCEN == 1 ) || ( PEN == 1 ) ||
( RSEN == 1 ) || ( SEN == 1 ) )
       {
               return FAIL;
       }
       else
       {
               return PASS;
       }

}



// FUNCTION: I2C_I2C_EngineInterruptConditionTimeoutCheck
//           --------------------------------------------
//
// Once an I2C event is initiated, this routine will
// indicate whether the event fired or not


unsigned char I2C_EngineInterruptConditionTimeoutCheck(void)
{
       unsigned char TimeoutCounter = 255;

       // Loop until I2C event fires else timeout will occur

       while ( SSPIF == 0 )
       {
               if ( TimeoutCounter-- == 0 )
               {
                       return FAIL;
               }
       }

       return PASS;
}







Best regards,

Ken Pergola

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

2004\06\26@002635 by Ken Pergola

flavicon
face
Hi Joe Colquitt,

I meant to respond to you. My apologies! For some reason I always get your
alias 'Jinx' mixed up with Neil's 'Picdude' alias. It must have been a sugar
low -- I just had a bowl of Honey Bunches of Oats with Almonds (and added my
own cinnamon) and bingo -- I noticed my mistake in the post in a split
second. :)

Regards,

Ken Pergola

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

2004\06\27@045702 by Jinx

face picon face
> Hi Joe Colquitt,
>
> I meant to respond to you. My apologies! For some reason I
> always get your alias 'Jinx' mixed up with Neil's 'Picdude' alias

Well, they are each both spelled quite differently to the other -
maybe it's that commonality that confuses you ;-)

You raise some good points. I've not used I2C for some time,
and particularly not on a PIC with an MSSP, so the first order
of business was to get it working at a basic level. Now that's
done (apparently, but I'll look out for any advice to the contrary),
it can be enhanced and beefed up and adapted for other I2C
devices

If it does prove to be correct I'll leave that page up as an MSSP
primer (a kind of LED-blink equivalent). I wish I'd found something
as straighforward at the start of the week, but everything I found
was just so over the top

> I noticed my mistake in the post in a split second. :)

Don't you just hate that ?

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

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