• AVR Freaks

Hot!I2C issues with Pic-processors

Author
jhn4
New Member
  • Total Posts : 4
  • Reward points : 0
  • Joined: 2020/08/02 23:32:06
  • Location: 0
  • Status: offline
2020/08/24 02:27:52 (permalink)
0

I2C issues with Pic-processors

Hello! I have tried this summer to make a PIC16F690 communicate with another microprocessor, a Pycom, "Wipy".
I wanted to use the PIC for one application and once every hour or so, an interrupt would come from the Wipy, and ask for the measured values. 
I got to borrow a PICKit 2 from a friend and with that a PIC16F690 came. 
 
To set up I2C-communication, and make the PIC16F690 act as slave should not be much code according to the data sheet.
 

void main(void) {
    ANSEL = 0; // Sets pins to digital I/O
    ANSELH = 0; // Sets pins to digital I/O
    INTCONbits.GIE = 1; // Enables global interrupts
    INTCONbits.PEIE = 1; // Enables i2c interrupts
    PIE1bits.SSPIE = 1; // Enables i2c interrupts
    TRISB = 0b01010000; // RB4 and RB6 are now inputs
    SSPCON = 0b00110110; // Enables I2C, sets clock polarity bit, and sets the PIC to a slave unit with a 7 bit adress.
    TRISC = 0b11110000; // For lamps
    PORTC = 0b11110000; // For lamps
    SSPADD = 0x43;

    for(;;){
        __delay_ms(1000);
        PORTCbits.RC3 = 0;
        PORTCbits.RC0 = 1;
        __delay_ms(1000);
        PORTCbits.RC0 = 0;
        PORTCbits.RC1 = 1;
        __delay_ms(1000);
        PORTCbits.RC1 = 0;
        PORTCbits.RC2 = 1;
        __delay_ms(1000);
        PORTCbits.RC2 = 0;
        PORTCbits.RC3 = 1;
    }
}

 
 
This program is the main code and it triggers an interrupt routine if there is an interrupt which makes the lamps blink insted of loop.
I never got it to work, i tried both in the simulator and on the hardware. In the simulator i put both SDA and SCL to high and then pulled SDA low to trigger the interrupt but the status register don't change, i don't really know if it is suppose to work. On the hardware i had two 4.7k ohm resistors from 5V to RB4 and RB6 and then i did a scan but i get no response on the bus, i also tried to connect with the direct with the adress but i get "i2c communication error" when i try this.
 
I then bought another PIC, a PIC16F1705, and with that one i could generate code with MCC, but it wont compile since it tries to import files that don't exist and i've read some on the forum that this is common but i dont really understand how to fix it.
 
This is the line that is causing the problem
 
#include ".././i2c_master.h"
 
What i've read, i have to change this somehow to include my path to i2c_master.h, like;
#include"drivers/i2c_master.h"
The issue with that is the MCC did not generate a file called i2c.master.h, there is files online that are called "i2c_master.h" but it feels strange to download a file from git.
 
My questions are really, what is wrong with my code to init my PIC16F690 as slave and what should it say insted of
".././i2c_master.h"
 
 
 
 
 
 
 
 
 
 
#1

7 Replies Related Threads

    ric
    Super Member
    • Total Posts : 28731
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: I2C issues with Pic-processors 2020/08/24 13:53:09 (permalink)
    +1 (1)
    jhn4
        SSPADD = 0x43;

    This needs to be in 8 bit format, so shift the value left one bit
        SSPADD = 0x86;
     

    I never got it to work, i tried both in the simulator and on the hardware. In the simulator i put both SDA and SCL to high and then pulled SDA low to trigger the interrupt but the status register don't change, i don't really know if it is suppose to work.

    That just simulates a START cycle.
    The I2C peripheral in this PIC doesn't generate an interrupt on START, although the "S" bit in the SSPSTAT register should go high after this.
    You don't get an interrupt until you get an address match.
     
     
    post edited by ric - 2020/08/24 13:54:56

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #2
    ric
    Super Member
    • Total Posts : 28731
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: I2C issues with Pic-processors 2020/08/24 13:55:05 (permalink)
    +1 (1)

    I then bought another PIC, a PIC16F1705, and with that one i could generate code with MCC, but it wont compile since it tries to import files that don't exist and i've read some on the forum that this is common but i dont really understand how to fix it.
     
    This is the line that is causing the problem
     
    #include ".././i2c_master.h"

    Sorry, I don't use MCC, so can't help you much with that, but I suspect you've skipped  step in generating the code.
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #3
    jhn4
    New Member
    • Total Posts : 4
    • Reward points : 0
    • Joined: 2020/08/02 23:32:06
    • Location: 0
    • Status: offline
    Re: I2C issues with Pic-processors 2020/08/25 00:45:11 (permalink)
    0
    Thanks for your reply!
     
    I was bit unclear, sorry!
     
    Yes, you're right, that would be the start cycle. For the PIC16F690, i was observing the the SSPSTAT but i had no change.
    Thanks for the comment on the adress, what do you mean with that it needs to be in 8-bit format?
    0x43 = 0100 0011 and if i shift them left one step i get 1000 0110 = 0x86 just as you wrote, but both of them are in 8 bit format? I'm clearly missing something here...
     
    Aside from that, the address  would not really affect the SSPSTAT bit, i have read a lot of forum threads and people are saying
    "Don't trust the simulator"
     
    That's why i tried it on hardware, when i scanned the bus with the other microcontroller it should have returned the adress i had set in the program right? As i understood it, no bit-banging is needed on the PIC?
    #4
    ric
    Super Member
    • Total Posts : 28731
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: I2C issues with Pic-processors 2020/08/25 01:42:28 (permalink)
    0 (2)

    Thanks for the comment on the adress, what do you mean with that it needs to be in 8-bit format?
    0x43 = 0100 0011 and if i shift them left one step i get 1000 0110 = 0x86 just as you wrote, but both of them are in 8 bit format? I'm clearly missing something here...

    0x43 is in seven bit format 0b100 0011, which is shifted left and has the R/W bit appended to form an 8 bit address.
    So 1000 0110 for 0x86 to write, and 1000111 = 0x87 for read.
     
     

    Aside from that, the address  would not really affect the SSPSTAT bit, i have read a lot of forum threads and people are saying
    "Don't trust the simulator"

    Indeed, the simulator often differs from real hardware when you get down to specifics.
     
    Just one question. Is that ALL your code?
    You are enabling interrupts, but don't show an Interrupt Service Routine.
    That would cause your code to restart as soon as an interupt triggered, which would stop everything working!
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #5
    jhn4
    New Member
    • Total Posts : 4
    • Reward points : 0
    • Joined: 2020/08/02 23:32:06
    • Location: 0
    • Status: offline
    Re: I2C issues with Pic-processors 2020/08/25 02:25:59 (permalink)
    0
    Thanks!
     
    As i wrote in my first comment
    "This program is the main code and it triggers an interrupt routine if there is an interrupt which makes the lamps blink insted of loop."
     
    So there is an interrupt routine that should trigger if i get an interrupt. Now i have removed the programs that did't work so i only got an early vesion of the interrupt routine but i check the SSPIF flag for interrupts on the serial communications port.
     
    void __interrupt () blink_lamps (void) {

        if (PIR1bits.SSPIF == 1)
        {
            PIR1bits.SSPIF = 0;
            int read = PORTA;
            PORTC = 0b11111111;
            __delay_ms(200);
            PORTC = 0b11110000;
            __delay_ms(200);
            PORTC = 0b11111111;
            __delay_ms(200);
            PORTC = 0b11110000;
            __delay_ms(200);
            PORTC = 0b11111111;
            __delay_ms(200);
            PORTC = 0b11110000;
            __delay_ms(200);
            PORTC = 0b11111111;
            __delay_ms(200);
            PORTC = 0b11110000;
        }
    }

    #6
    Aussie Susan
    Super Member
    • Total Posts : 3772
    • Reward points : 0
    • Joined: 2008/08/18 22:20:40
    • Location: Melbourne, Australia
    • Status: offline
    Re: I2C issues with Pic-processors 2020/08/25 19:48:01 (permalink)
    +1 (1)
    I hope that ISR is ONLY used to see if you get an interrupt.
    The rule is that you NEVER put delays into an ISR. In that ISR you need to check the I2C status and act accordingly. However I *think* the MCC code does this for you (never used MCC) or at least provides a link to a callback function.
    A much better way to debug your code is to use the debugger in the MPLABx IDE - you can set a breakpoint in the ISR  and see if that gets called.
    Susan
    #7
    jhn4
    New Member
    • Total Posts : 4
    • Reward points : 0
    • Joined: 2020/08/02 23:32:06
    • Location: 0
    • Status: offline
    Re: I2C issues with Pic-processors 2020/08/25 22:26:52 (permalink)
    0
    This is not by any means the final code. As i wrote higher up, i have debugged it with MPLABX by setting SDA and SCL to high and then pull SDA low, since the SSPSTAT flag does not set the ISR can't be called...
     
    I then wrote a routine to test it on hardware in case the simulator did work poorly for my PIC.
     
     
    #8
    Jump to:
    © 2020 APG vNext Commercial Version 4.5