Jump to content
 
  • 0
Orunmila

I need help with I2C on a PIC16F1 device

Question

3 answers to this question

Recommended Posts

  • 0

I think the easiest way to learn how to use I2C on those boards is to use MCC to generate the I2C code for you. I have created a project using the MCC "I2CSIMPLE" driver which is part of the "Foundation Services" package in MCC.

The easiest way to generate an example using this library is probably to use a MikroElektronika Click board. I happened to have a TouchPad click board (this one https://www.mikroe.com/touchpad-click)

The TouchPad Click is a I2C Slave device. It contains a MTCH6102 from Microchip which presents itself on I2C address 0x25

Control is performed using a number of registers on the device, so e.g. if I want to read the state of touch of the board I need to read the register at address 0x10. So this means in terms of I2C what I need to do is do an I2C ADDR write (write 0x25 as address) and then write the register address (which is 0x10) and then do an I2C read to read the data from this location.

I can do all of this using the MCC generated function as follows

touch_state = i2c_read1ByteRegister(0x25, 0x10);

I attach the project here for you to look at to get you going. The project includes the MC3 file containing the MCC configuration, so if you have MCC v3.66 or later you should be able to open MCC and look at the configuration.

The example code checks for a touch state, and if there is one it clears the 4 LED's on the HPC board and then turns on the LED corresponding to the touch position. The MTCH6102 provides 32 locations on the X-axis, so we divide this range in 4, the first 8 pixels will turn on D2, next are turns on D3 up to D5.

TouchpadExample.zip

RightLED.png.c98cb8ac7bcee2a21e063603b8dd96a3.pngLeftLED.png.e0357a79306589eb38c58ea0f7787071.png


At masters 2018 Microchip had a class with a LAB Manual to step you through this process step by step. The class also contained a couple of other labs such as using the TIMER driver in MCC and the BLE Click board from Mikro Elektronika.

LAB 3 in this manual has screenshots and explains step by step how to reproduce the above example

I uploaded this lab manual here :

 

 

 

 

Share this post


Link to post
Share on other sites
  • 0

Some advanced information about Interrupts.

That I2C driver from MCC can opererate either in "Interrup Driven" mode or a blocking "Polled Mode". You will notice that I2C operations are executed by the function masterOperation(), which looks as follows in this project:

i2c_error_t i2c_masterOperation(bool read)
{
    i2c_error_t ret = I2C_BUSY;
    if(!i2c_status.busy)
    {
        i2c_status.busy = true;
        ret = I2C_NOERR;
        
        if(read)
        {
            i2c_status.state = I2C_SEND_ADR_READ;
        }
        else
        {
            i2c_status.state = I2C_SEND_ADR_WRITE;
        }
        i2c1_driver_start();
        
        if(! mssp1_IRQisEnabled())
            i2c_poller();
    }
    return ret;
}

Notice the last part is checking if the mssp1_IRQisEnabled(). If the interrupt is enabled the function returns immediately with the value I2C_Busy, but if the interrupt is NOT enabled it will call i2c_poller(). This function looks like this :

inline void i2c_poller(void)
{
    while(i2c_status.busy)
    {
        mssp1_waitForEvent(NULL);
        i2c_ISR();
    }
}

So as you can see this will keep on calling waitForEvent as long as the i2c_status is busy. This means the function will only return after the I2C operation is completed.

Using this method this driver can be switched between interrupt driven and polled even at runtime by simply enabling or disabling the I2C interrupt.

The exact bit is revealed by the implementation of  the function mssp1_IRQisEnabled()

inline __bit mssp1_IRQisEnabled(void)
{
    return PIE3bits.SSP1IE;
}

 

 

  • I Agree 1

Share this post


Link to post
Share on other sites
  • 0

Your pro-tip for the day.  If you use this code from MCC on a PICmicrocontroller, the function i2c_ISR must be duplicated due to the way the C stack is implemented on a PICmcu.  If you want to save code space, simply decide how you want your code to run (interrupt or polled) and remove the call to i2c_isr from the master interrupt code or remove the test in master_operation.  Either one will remove the duplication because the function i2c_ISR will not exist in both contexts. (interrupt and "main")

  • I Agree 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


 


  • Popular Contributors

    Nobody has received reputation this week.

  • Similar Content

    • By KM1
      Hello,
      I have run into a strange (for me) issue with the rtcounter module as provided by MCC and shown by the example program in the blog area of this site. I am using MPLabX and XC8, both up-to-date versions and I am trying the example on a pic18F47k40 xpress board. The issue is I set an output (RA4) in main after initializing the pic and then enter the while(1) loop where the rtcount_callNextCallback(); is called. The output now is turning on and off. The off duration is typically ~60u seconds, and on time can be varied with changes to the timer interrupt settings (I use a 1mS timer0 in 16 bit mode) and the number sent to the callback. Approximately every 3mS, the off time increases such that that cycle (only) is approx 50% duty cycle.
      Turning the output on or off in the callback routine has no effect - I initially wanted to toggle on and off at a speed visible to the eye. Commenting out the callback in the main loop stops the output from going low.
      I have checked errata and used the data sheet to confirm register settings, I tried moving the current-limited LED from RA4 to RA2, and I have studied the example program looking for obvious differences that may cause this behaviour.
      I would appreciate thoughts and/or suggestions.
      Keith
         
    • By burkart
      Hello All,
      I am working on a project (in MPLAB v5.10) with a PIC18F27K40 (PIC18 library v1.77.0) and I'm using the MCC (v3.85.1) generated I2C drivers, I2CSIMPLE from the Foundation Services. I can read from and write successfully to devices on the I2C bus. The problem comes when I try to communicate with a device that's not on the bus, the micro goes into an endless loop waiting for i2c_status to not be busy. My knowledge of programming in C is about 6 on a scale of 10, and for programming for embedded purposes, about 5 out of 10. I would like to have it so that I can check if a specific device is present on the I2C bus, and also be able to recover from errors on the bus without it going into a loop indefinitely.

      This I2C driver is pretty complex, and I am having difficulties wrapping my head around it. How would I make it so that the driver just returns an error or something I can check for status, rather than loop endlessly until the operation completes, which it never will?

      I have not edited any of the MCC generated code. This includes leaving the IRQ enable line commented in the i2c_master.c file, so instead it polls instead of using an interrupt to check if the i2c operation has completed.
      // uncomment the IRQ enable for an interrupt driven driver. // mssp1_enableIRQ(); Following is an example of how I am calling the i2c driver.
      i2c_write1ByteRegister(address, 0x0D, 0x07); // GPPUB pull-ups on pins 0-2 I am attempting to initialize a port extender, MCP23018, specifically enabling some pull-up resistors. I would like to issue this command, and if the extender is not present, then the micro will perform some tasks differently. With the port extender present the write operation works as expected and everything is fine. Of course the problem is when the extender is NOT on the bus to acknowledge.
      I have another question as well. This driver seems to operate a little slow. When watching the bus with a logic analyzer I noticed a rather long pause between bytes. I went looking through the i2c driver and in i2c1_driver.c I found the following code which I suspect is the cause.
      inline void mssp1_waitForEvent(uint16_t *timeout) { // uint16_t to = (timeout!=NULL)?*timeout:100; // to <<= 8; if(PIR3bits.SSP1IF == 0) { while(1)// to--) { if(PIR3bits.SSP1IF) break; __delay_us(100); } } } What is the purpose of the 100 us delay in the while loop? Reducing or eliminating the delay results in reducing or removing the pause between byte transactions, but I don't know enough to know how else this edit will effect the driver. Also, what is the commented out code at the top of the function used for? Is this part of the infinite loop problem I mentioned above?

       
      --
      James Burkart
    • By Orunmila
      error: variable has incomplete type 'void'
      If you are getting this error message trying to compile code that used to work or from some example code you found somewhere it is very likely because of the changes in the XC8 interrupt syntax introduced with V2.0 of XC8.
      Specifically I am getting this today for my interrupt service routine definition. I used to use the age-old way of doing this in XC8 as follows:
      // Old way to do this void interrupt myISR(void) { // Old way Interrupt code here } After the changes to the XC8 compiler which were mostly motivated to get better C standard compliance, particularly with C99, the syntax for that function should now use the commonly adopted concept of function declaration-specifier attributes, which traditionally start with 2 underscores and contains either a list of parameters in brackets or have empty brackets if no parameters are present. 
      // New and improved and C99 compliant way to specify an interrupt service routine in XC8 void __interrupt() myISR(void) { // New and improved interrupt code here } This syntax is now also consistent between XC8, XC16 and XC32
      Please see this post for more information on how to either work around this or change to the new syntax.
      https://www.microforum.cc/topic/5-i-used-to-use-to-locate-variables-but-since-xc8-20-this-is-no-longer-working/
    • By Orunmila
      I just downloaded XC32 V2.15, I was using V2.10 before. I find that some of my projects no longer compile. On my first check I noticed that the problems seem to occur when inline functions are used and the same header where the inline implementation is done is included in more than one compilation unit?
      Has any of you seen similar issues?
      I will investigate further and post here if I arrive at an answer.
       
      UPDATE: Ok, I managed to make a small test project to replicate the problem. I am attaching it here. 
      TestInlineXC32_2.15.zip
       
      Next I am going to test this on some other compilers to see what the deal is. I have confirmed that with that project when you switch it to V2.10 or older it all compiles just fine, but if you use V2.15 it failes to link with the following error:
      "/Applications/microchip/xc32/v2.15/bin/xc32-gcc"   -mprocessor=32MZ2048EFM100  -o dist/default/production/TestInlineXC32_2.15.X.production.elf build/default/production/main.o build/default/production/otherFile.o          -DXPRJ_default=default  -legacy-libc    -Wl,--defsym=__MPLAB_BUILD=1,--no-code-in-dinit,--no-dinit-in-serial-mem,-Map="dist/default/production/TestInlineXC32_2.15.X.production.map",--memorysummary,dist/default/production/memoryfile.xml
      nbproject/Makefile-default.mk:151: recipe for target 'dist/default/production/TestInlineXC32_2.15.X.production.hex' failed
      make[2]: Leaving directory '/Users/ejacobus/MPLABXProjects/TestInlineXC32_2.15.X'
      nbproject/Makefile-default.mk:90: recipe for target '.build-conf' failed
      make[1]: Leaving directory '/Users/ejacobus/MPLABXProjects/TestInlineXC32_2.15.X'
      nbproject/Makefile-impl.mk:39: recipe for target '.build-impl' failed
      build/default/production/otherFile.o: In function `myInlineFunction':
      /Users/ejacobus/MPLABXProjects/TestInlineXC32_2.15.X/inlinedheader.h:6: multiple definition of `myInlineFunction'
      build/default/production/main.o:/Users/ejacobus/MPLABXProjects/TestInlineXC32_2.15.X/inlinedheader.h:6: first defined here
      /Applications/microchip/xc32/v2.15/bin/bin/gcc/pic32mx/4.8.3/../../../../bin/pic32m-ld: Link terminated due to previous error(s).
      collect2: error: ld returned 255 exit status
      make[2]: *** [dist/default/production/TestInlineXC32_2.15.X.production.hex] Error 255
      make[1]: *** [.build-conf] Error 2
      make: *** [.build-impl] Error 2
      BUILD FAILED (exit value 2, total time: 680ms)
       
       
       
    • By Orunmila
      If you have purchased a "MPLAB(R) Xpress PIC18F47K40 Evaluation Board" from Microchip (part number DM182027) and you are running into difficulty because the board is behaving strangely it is most likely caused by a silicon errata on this device!
      The errata can be downloaded here: http://ww1.microchip.com/downloads/en/DeviceDoc/PIC18F27-47K40-Silicon-Errata-and-Data-Sheet-Clarification-80000713E.pdf
      The relevant section of the Errata is shown at the end.
      What is happening is that the compiler is using a TBLRD instruction somewhere and this instruction is not behaving as expected due to a silicon bug in REV A2 of the PIC18F47K40, causing the read to fail and the program to malfunction. Typically this happens as part of the C initialization code generated by the XC8 compiler, and since the compiler is optimizing, changing the code may cause the problem to temporarily disappear because you have few enough global variables that a table read is no longer the fastest way to initialize the memory segment for variables with static linkage.
      The XC8 compiler can avoid generating the sequence which will cause the failure if you tell it in the linker settings to implement the workaround for this Errata. This is done by adding +NVMREG to the setting as follows. Note that this is under the section "XC8 Linker" and the Option Category "Additional Options".
       

       
      This is the relevant section of the Errata.

       
       
    • By Orunmila
      I have a bunch of old projects using the @ method to hard locate variables at a specific location in data memory, but since I upgraded to XC8 2.0 none of these are working any more!
      How do I do this with the latest compiler? I am using XC8 v2.xx.
      I also saw this error at my interrupt service routine and I suspect that this is the same problem.
      My interrupt code looks like this 
      void interrupt my_isr(void) { ... my code here } error: variable has incomplete type 'void'
×
×
  • Create New...