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.

MSP430FR2532: The difference between BULK_I2C and REGISTER_I2C

Part Number: MSP430FR2532

Hi,

I would like to know what is the difference between BULK_I2C and REGISTER_I2C.
Especially I can't understand REGISTER_I2C...

Best regards,
Keigo Ishii

  • Hi Keigo,

    Bulk_I2C is similar to UART method in that both can communicate with the Captivate Design Center by providing all necessary sensor information in a complete packet. REGISTER_I2C provides a register-file interface to a host processor, similar to a sensor or an EEPROM, which is beneficial for single parameter reads and as such does not require as much time to accomplish.

    Regards,
    Ryan
  • Hello Keigo,

    CapTIvate communications module supports UART and I2C operation in three modes: UART, BULKI2C, and REGISTERI2C. The UART and BULKI2C modes are both meant for connecting a target to the CapTIvate Design Center during development using either the UART or I2C interface, respectively. The REGISTERI2C mode is for easily connecting a CapTIvate MCU to a host processor or host MCU via an asynchronous I2C connection, where the host may query the status of a sensor whenever it would like to.

    Regards,

    Yiding Luo

  • Hi Ryan-san and Yiding-san,

    Thank you for your replies.

    I understood the overview of REGISTER_I2C, however I don't understand the communication process of REGISTER_I2C.
    Does the I2C master need to write register address or command ID before reading? Or, does the I2C master just read? How many is the data to read?

    Best regards,
    Keigo Ishii

  • Hello Keigo,

    Yes. For the REGISTER_I2C, the I2C master need to write the command ID before reading from the slave (CapTIvatae) device. 

    For example, if we want to read the sensor packet for sensor 0X00.

    1. The master (host) requested a sensor packet by writing the first two bytes of the sensor packet it wanted. The first two bytes indicate to the slave device what data to fetch for the host. Sensor packets are fixed length packets (always 6 bytes) that indicate the general status of a sensor. For button sensors, this includes information such as the dominant button that is being touched. For slider and wheel sensors, this includes the calculated slider/wheel position. Review the CapTIvate Protocol Sensor Packet description for details on the packet structure. The basic format is shown below:

          

    The first two bytes (shaded darker) include the CMD byte and the Sensor ID byte. The CMD byte tells the slave to fetch a sensor packet. The command ID for a sensor packet is 0x00. The Sensor ID byte tells the slave which sensor to fetch the packet for. In this case, we asked for Sensor ID 0x00, which corresponds to the button group sensor. These are the two items that are needed for reading a sensor packet.

    2.  Following the host requesting the packet, the host performs a read of the data to retrieve the entire packet that was generated by the slave (CapTIvate) device. This means that all 6 bytes of the sensor packet are read out of the device. 

    You can find more information about packet types from our CapTIvate Technology Guide Packet Types Section 

    Please let me know if you have any questions.

    Regards,

    Yiding

  • Hello Yiding-san,

    Thank you for your answer, and I'm sorry for my late response.

    I understood the communication process of REGISTER_I2C a lot.
    As long as I read the template program of CapTIvate, it seemed necessary to restart and read after writing the first two bytes.
    Thanks to your explanation that I was able to read the program.

    Best regards,
    Keigo Ishii

**Attention** This is a public forum