• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 101 subscribers
  • Views 612 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Delay before all I2C_transfers

Blair Conner
Expert 4720 points
Other Parts Discussed in Thread: MSP430F5528, MSPWARE

Hello,

I'm using the TI-RTOS v2.12 on an MSP430F5528 and am trying to optimize the I2C functionality. If I don't use the TI-RTOS I can create transactions on the I2C peripheral with practically no delay between transactions. However, when I use the TI-RTOS there is about a 250us delay before every I2C transaction. 

I've tried using both blocking and callback modes with the driver, but the delay is always present. I set the TI-RTOS to non-instrumented mode, which helped as the delay with instrumentation was almost 500us.

Any idea's how to remove this delay?

Best regards,

Blair

  • 0
    TI__Genius 10260 points
    Hi Blair,

    How are you measuring the delay? When do you start measuring (when you call I2C_transfer())?

    Regards,
    -- Emmanuel
  • 0 in reply to Emmanuel Trinidad - Alicea
    TI__Expert 4720 points
    Hi Emmanuel,

    I have a scope and am measuring SCL and SDA. The I2C_transfer is in a loop so it runs continuously and I am observing the delay on the scope between a finished transaction and the start of a new one.

    Regards,
    Blair
  • 0 in reply to Blair Conner
    TI__Genius 10260 points

    Hi Blair,

    Thanks for the explanation.

    Unlike MSPware, TI-RTOS drivers are written to be used in an RTOS environment, OS objects are used to ensure thread-safety (usually semaphores & locks).  The delay you are seeing is due to the "thread-aware" code executed before and after data is transferred through I2C.  

    If you look at the driver source (<tirtos install directory>/packages/ti/drivers/i2c/I2CUSCIB.c) you can see when transfer is called, semaphores are used to gain exclusive access to the peripheral & to block the task (if necessary).  Once all the data is transferred, the same semaphores are released.  

    The MSP430F5528 is a 25 MHz device so a 250 us delay is 625 clock cycles.  If you add the cycles for each operation (kernel benchmarks) you can see where the cycles are going (the price we pay for thread-safety).

    Hope this helps,

    -- Emmanuel

  • 0 in reply to Emmanuel Trinidad - Alicea
    TI__Expert 4720 points

    Hi Emmanuel,

    Thank you  for the clear explanation!  Glad to know about the  thread safety of the peripheral which is valuable.

    Regards,

    Blair