• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 895 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

I2C Operation

Jay Bu1
Intellectual 280 points
Other Parts Discussed in Thread: TMS320F28035

Hi,

I am planning to use I2C to access an external EEPROM. In the library, there is an example for I2C. However, it is for softI2C. It seems different from the standard I2C described in the Tiva manual. Can anybody shed more lights on softI2C?

 

Thanks.

 

 

  • 0
    Guru 117855 points

    Jay Bu1 said:
    shed more lights on softI2C

    Illumination hereby attempted...

    SoftI2C.c usually is employed when the, "normal" MCU I2C module pins are unavailable - for some reason.  StellarisWare & its spin-off both include well designed, tested I2C functions which ease, speed & enhance I2C usage.  SoftI2C.c is not so extensive - thus imho should be used for lower priority tasks or when the "normal" I2C MCU pins are otherwise, "in play" or diverted.

    The extra "lighting" you request can best be achieved by, "side by side" review of the code w/in SoftI2C.c and I2C.c w/in the driverlib... 

    In the past - fairly basic MCUs did not always include I2C modules - and we were forced to, "bit-bang" to manage our I2C accessories.  If you can exploit the "normal" I2C functions and MCU's I2C pins - your job should be simplified & speeded.  In either case - external pull-up Rs (SDA & SCL) prove worthwhile...

  • 0 in reply to cb1_mobile
    Intellectual 280 points

    This really helps. I definitely will use the standard I2C. I am planning to polling the I2C status for the I2C operation. How soon should I poll the I2C status? For example, I need to write/read several parameters to the EE. After I write the first one, if I send the next command with delay, will the sequence be stopped? I can also consider the interrupt based I2C. However, it has the same delay issue as my system cannot put the I2C interrupt to the higher priority.

     

    Several years ago, I used TMS320F28035 in a project. For some reason, I had some trouble to make multi read/write work (it is not reliable). Then finally, I convert the multi read/write to multi single read/write. And it never fails. For this Tiva project, I'd try to make the multi read/write work.

     

    Thanks.

  • 0 in reply to cb1_mobile
    Intellectual 280 points

    Also to let you know. I previously posted the processor failure issue. After many tries, we figured out it is from the flash based EEPROM. During the power down, the flash based EEPROM operation was interrupted as the operation may take several seconds. That's why we are seeking an external EEPROM solution now.

     

    Thank you.

     

    Jay

  • 0 in reply to Jay Bu1
    Guru 117855 points

    Jay Bu1 said:
    How soon should I poll the I2C status? 

    Illustrated below is rather basic (non-interrupt) code which works well for our use w/this vendor's small, I2C based ADC chip.  (required more ADC than 64 pin MCU could provide)

    That, "ROM_I2CMasterBusy()" function - employed twice - works nicely in our application.  (and is more efficient than an attempt to "guess/predict" a fixed delay loop) 

    Note: this code resides after the I2C port/pins were chosen & properly clocked/set-up/configured.

    As always - SW-DRL-UGxxxx provides the fine detail & necessary function descriptions...

    void     
    ads79xx_setup(void)
    {

            ROM_I2CMasterInitExpClk(I2C1_MASTER_BASE, ROM_SysCtlClockGet(), false);  // false = 100KHz
            ROM_SysCtlDelay(1000);         //   may not be needed - here for sureness
           
            ROM_I2CMasterSlaveAddrSet(I2C1_MASTER_BASE, 0x48, false); // Slave Adr Wr
            ROM_I2CMasterDataPut(I2C1_MASTER_BASE, 0x0); // Mode Cntl:

            ROM_I2CMasterControl(I2C1_MASTER_BASE, I2C_MASTER_CMD_BURST_SEND_START);
                  // bytes 0x48 & 0x00 sent w/o Stop...
           
            while(ROM_I2CMasterBusy(I2C1_MASTER_BASE)) {}   // Delay till xmsn completes

            ROM_I2CMasterDataPut(I2C1_MASTER_BASE, 0xC8);  //  Manual, Single Scan
            ROM_I2CMasterControl(I2C1_MASTER_BASE, I2C_MASTER_CMD_BURST_SEND_FINISH);
                  // byte 0xC8 sent along w/Stop...
           
            while(ROM_I2CMasterBusy(I2C1_MASTER_BASE)) {}   // Delay till xmsn completes

    }

  • 0 in reply to cb1_mobile
    Intellectual 280 points

    cb1_mobile:

    Thank you very much for the sample code. I'll use a state machine for the I2C operation as the real time system doesn't allow a while loop. Please see the colored comment below. Will a potential 100us delay work for the I2C operation?

    Thanks.

    ads79xx_setup(void) {

            ROM_I2CMasterInitExpClk(I2C1_MASTER_BASE, ROM_SysCtlClockGet(), false);  // false = 100KHz    

             ROM_SysCtlDelay(1000);         //   may not be needed - here for sureness      

             ROM_I2CMasterSlaveAddrSet(I2C1_MASTER_BASE, 0x48, false); // Slave Adr Wr        

             ROM_I2CMasterDataPut(I2C1_MASTER_BASE, 0x0); // Mode Cntl:

            ROM_I2CMasterControl(I2C1_MASTER_BASE, I2C_MASTER_CMD_BURST_SEND_START);               // bytes 0x48 & 0x00 sent w/o Stop...                

            // while(ROM_I2CMasterBusy(I2C1_MASTER_BASE)) {}   // Delay till xmsn completes

           Exit for 100 us to execute other critical tasks.  When returns, check ROM_I2CMasterBusy(I2C1_MASTER_BASE). If Master is busy, exit again for 100us. If not busy, execute the following code.

            ROM_I2CMasterDataPut(I2C1_MASTER_BASE, 0xC8);  //  Manual, Single Scan         ROM_I2CMasterControl(I2C1_MASTER_BASE, I2C_MASTER_CMD_BURST_SEND_FINISH);               // byte 0xC8 sent along w/Stop...                

    // while(ROM_I2CMasterBusy(I2C1_MASTER_BASE)) {}   // Delay till xmsn completes

    }

     

  • 0 in reply to Jay Bu1
    Guru 117855 points

    As stated - any fixed delay may cause issues - we do not recommend.

    A superior method may be to "transact" w/your I2C Slave device - only when you can tolerate - the time required for the while loop to unwind.  By placing an incrementing variable w/in each while loop ((recall that there are two)) (i.e. w/in {   }) you can observe the "normal" time the MCU spends w/in each loop.

    In addition - would not a properly configured interrupt scheme enable your higher priority code activity to, "escape" from the "while loop" - service that high priority item - and then return to test the "while loop" for completion?  Experimentation may serve you very well in this regard...