• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 79 subscribers
  • Views 444 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.

Purpose of delay following LPM for I2C Protocol?

Matthew Wasko
Intellectual 1670 points

Other Parts Discussed in Thread: MSP430F2012

Hi all,

If anyone has looked at TI's example code for I2C protocol (MSP430F2012 to be specific), they have seen this helper function below:

void Master_Receive(void){
volatile unsigned int i;
Setup_USI_Master_RX();
USICTL1 |= USIIFG; // Set flag and start communication
LPM0; // CPU off, await USI interrupt
 for (i = 0; i < 5000; i++); // Delay between comm cycles
}

After entering LPM0, multiple interrupts are created, and a case statement in the ISR controls sending data, receving ACK/NACK and all that good stuff. However, I was wondering what the highlighted line is needed for in the function. In particularly, it is really slowing my writes and reads down, and it seems like my writes and reads work properly when I take it out entirely. Can anyone explain what the for loop is needed for in this case? And if my code appears to be working right now without it, is there a chance that it will not work later on? Does it depend on how many bytes I transfer in a single read/write? For example, the most I currently have to transfer over I2C at any one time is 4 bytes. Any help or insight would be greatly appreciated!

Thanks,

Matt 

  • 0
    Guru 227245 points

    To exit LPM, this must be done form within an ISR. Howeve,r when the ISR for the I2C is called the last time, it initiates the end of the transfer. But the transfer hasn't ended at this point. So the ISR must end LPM now (no more interrupts will follow where it could be done) but main cannot immediately start the next transfer. Of course one could check the USI for the end of the transfer, but the code would have to wait a bit anyway (one I2C clock cycle) before starting the next transfer.

  • 0 in reply to Jens-Michael Gross
    TI__Intellectual 1670 points

    so it only has to wait one clock cycle? If so, then why does the loop go through 5000 iterations?

  • 0 in reply to Matthew Wasko
    Guru 227245 points

    Matthew Wasko said:
    so it only has to wait one clock cycle? If so, then why does the loop go through 5000 iterations?

    One I2C clock cycle after the stop. But LPM is probably ended one full byte and the stop itself before this point. So (worst case), teh delay has to span 11 I2C clock cycles.
    But you're right, 5000 cycles seems to be a bit much. Unless the slave may need an additional delay for some reason. On the other side, you don't know how long an empty for loop takes. The compiler may optimze it in an unexpected way (including removing it completely,a s it serves no visible purpose - consuming time is no purpose from the compiler view). __delay_cycles or using a timer is the proper way for predictable delays.

**Attention** This is a public forum