Delay before all I2C_transfers

Blair Conner

Other Parts Discussed in Thread: MSP430F5528

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

over 10 years ago

0 Emmanuel Trinidad - Alicea over 10 years ago

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 Blair Conner over 10 years ago 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 Emmanuel Trinidad - Alicea over 10 years ago 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 Blair Conner over 10 years ago 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

Processors

Processors forum

Delay before all I2C_transfers