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.

MSP430Ware I2C USCI use, seek clarification

Other Parts Discussed in Thread: MSP430WARE

I'm putting together a serialization wrapper for I2C bus access for my SYS/BIOS-based application, and while most of the documentation is clear the sequence of operation looks a bit off:

The user must first initialize the USCI_B_I2C module and configure it as a master with a call to USCI_B_I2C_masterInit().
That function will set the clock and data rates. This is followed by a call to set the slave address with which the master
intends to communicate with using USCI_B_I2C_setSlaveAddress. Then the mode of operation (transmit or receive) is
chosen using USCI_B_I2C_setMode. The USCI_B_I2C module may now be enabled using USCI_B_I2C_enable. It is
recommended to enable the USCI_B_I2C module before enabling the interrupts. Any transmission or reception of data
may be initiated at this point after interrupts are enabled (if any).
The transaction can then be initiated on the bus by calling the transmit or receive related APIs as listed below. APIs that
include a time-out can be used to avoid being stuck in an infinite loop if the device is stuck waiting for an IFG flag to be set.

I need to communicate with multiple slaves on the bus, so while the text indicates that I should set the slave address BEFORE the bus is enabled, is it permissible to do that with the I2C enabled?  Also, I will be transacting on the bus, so I'm assuming I can switch transmit/receive modes wthout having to disable/enable the bus...

All info appreciated! 

Ed Averill

 

  • Moving this thread over to the MSP forum so that the MSP430Ware experts there can answer...

  • The description is a bit confusing indeed. I’m no MSP430Ware expert. However, the sequence of events for USCI I2C operation is as follows:

    1) Initialize port pins, reset the USCI and set it up for I2C operation (probably USCI_B_I2C_masterInit())
    2) setup the clock source and baudrate divider (apparently USCI_B_I2C_masterInit() too)
    3) enable the USCI module  (USCI_B_I2C_enable)
    4) enable the interrupts
    5a) set the slave address (USCI_B_I2C_setSlaveAddress)
    5b) set the mode of operation (USCI_B_I2C_setMode)
    6) start the transfer
    7) wait for end of transfer
    8) return to 5.

    I wonder why it is necessary in the API to set the operating mode, when there are separate calls for read and write anyway (which implies the mode)

    Well, as I said, I’m not an MSP430Ware expert. I don’t like mid-level libraries. Either you go low-level yourself or you have a lib that is ‘fire-and-forget’ (“send data to slave x on USCIBy with n baud”) and returns success or failure. The first is more efficient and the second is more convenient. Mid-level libs are neither convenient enough nor efficient enough. But that’s just my private opinion. And in case of MSP430Ware, this API is all you have.

  • Ah, that makes sense.  I'll give that a shot once our hardware guy soldrs something up for me.

    Thanks for the help!

    Ed Averill

  • Hi Ed,

    USCI_B_I2C_setMode and USCI_B_I2C_setSlaveAddress are provided so that you can modify the mode and/or slave address during the course of I2C operation. These values can be changed without holding the module in reset with UCSWRST.

    The 2 APIs are provided to make it more flexible for the user to change slave address and/or change between transmit/receive modes during the course of I2C operation.

    Thanks,
    Kasthuri

  • WHERE IS THE SOURCE CODE FOR THE FUNCTION:  USCI_B_I2C_masterInit  ?

**Attention** This is a public forum