• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 80 subscribers
  • Views 1946 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.

Interrupts in I2C driverlib

Andreas Zoellner
Prodigy 90 points
Other Parts Discussed in Thread: MSP430F2618, MSP430WARE

Hello,

I am currently trying to port the I2C part of the driverlib for my MSP430F2618 project and am also looking at the i2c_master_tx_multi_int example. There is one part I don't understand:

After initializing I2C, the example enables the transmit Interrupt, loads the TX byte counter and initiates the transmission

//Enable transmit Interrupt
I2C_enableInterrupt(__MSP430_BASEADDRESS_USCI_B0__,
I2C_TRANSMIT_INTERRUPT
);

//Delay between each transaction
__delay_cycles(50);

//Load TX byte counter
transmitCounter = 1;

//Initiate start and send first character
I2C_masterMultiByteSendStart(__MSP430_BASEADDRESS_USCI_B0__,
transmitData[0]
);

The I2C_masterMultiByteSendStart function in the driverlib then disables the transmit interrupt again and starts polling on the transmit interrupt flag:

//Disable transmit interrupt enable
HWREGB(baseAddress + OFS_UCBxIE) &= ~(UCTXIE);

//Send start condition.
HWREGB(baseAddress + OFS_UCBxCTL1) |= UCTR + UCTXSTT;

//Poll for transmit interrupt flag.
while (!(HWREGB(baseAddress + OFS_UCBxIFG) & UCTXIFG)) ;

//Send single byte data.
HWREGB(baseAddress + OFS_UCBxTXBUF) = txData;

What is the purpose of the interrupt here if it is disabled and the flag is polled instead? Who is supposed to set the flag when data is put in the buffer after the polling?

Thank you

Andreas

  • 0
    Guru 25210 points

    You didn't specify which version of Driverlib you are using. They are different between 1.30 and 1.40 (looks like you copied from 1.40).

    In this case it looks like they poll on sending the start condition before it transmits the data. Otherwise you would have to handle this in your ISR that the start was sent and to call the correct send data function.

    The flag is set automatically by the USCI when the start condition has been sent.

    Notice in the ISR that the rest of the data bytes are pumped out from the ISR, and it sends the stop condition when done.

  • 0 in reply to Brian Boorman
    Prodigy 90 points

    Thank you for the explanation. 

    The code is based on msp430ware 1.40, but nothing has changed compared to 1.25 when condensed to the version posted.

  • 0
    Guru 227245 points

    I agree that the code doesn't make much sense here.

    When UCTXSTT is set, UCTXIFG instantly comes up by hardware. No need to poll for it. it is set. That's how it is defined and described in teh users guide module description. Since the instruction for pollign the bit has already been fetched when thr UCTXSTT bit is set, even no ISR can have cleared it in the meantime (even if the IE bit hadn't been cleared right before). So the poll is 100% superfluous.

    Setting the IE bit before calling this function is superfluous too.

    I don'T use the driver lib, nor do I know the complete demo code. But I seems to me that in an attempt to make the driverlib as flexible as possible, apparently much 'noise' has been put into it.

    And I guess, the demo code was originally wwritten for an interrupt-based I2C demonstration, while the MultyByteSendStart function and its brothers are for a polling transfer. When re-using the ISR-based demo code, some things were not removed which are superfluous now.

**Attention** This is a public forum