CCS/EK-TM4C123GXL: TMP007 I2C connection with TM4C123GXL

Hello Jeff,

Let me know if Markel's idea works regarding the I2C address.

Also regarding this query:

Jeff Chris said:

Also , is there and API for other sensors such as Inertial Sensor

The only inertial sensor we have example code for is the MPU9150 which is a 9-axis accelerometer/gyro.

Hi Ralph,

Would not that (Least Significant BIT) toggle (Markel's 0X41 vs. 0X40) be required for I2C's 'Read vs. Write?'

If that proves so - addresses of 'different I2C devices' - placed (just) one lsb apart - CANNOT possibly succeed!

Hello cb1,

The TMP006 info is hard to find, but the device address in the DS is stated to be "1000XXX", which is 7 bits and would fall inline with both 0x40 and 0x41 being valid addresses. Therefore I presume the API would shift the address by 1 to indicate read vs write (though I can't say I had the time to cross check this). In any case, both 0x40 and 0x41 are valid addresses, and I presume Markel has some info that I am lacking due to TI having removed the BOOSTXL-SENSORS datasheet entirely from the web, leaving me blind to it's secrets.

Hi,

I only suggested the 0x40 Address because that is what is defined at the TMP007 example program for my CC2640R2F Launchpad. I will check later in much detail how to make the TMP007 at BOOSTXL-SENSORS work for TM4C Launchpad.

-kel

Thank you, Ralph.    It may be that I'm not alone in (often) being 'ill at ease' w/the (timing) of the 'SHIFTED I2C' Address.    (i.e. is the address referenced (always) 'PRE' the shift - and that 'holds' - for ALL I2C vendors?)

As an example - using Markel's (earlier) first address value:  

• 0X40 - when shifted left (once) yields 0x80.    (that's an I2C device Write)
• when the MCU wants to 'Read' that device - it issues 0x81.

and Markel's 2nd address:

• 0x41- when shifted left (once) yields 0x82.    (that's again - an I2C device Write - and differs from the address, above (0x80)... thus proves 'legal.')
• and  when the MCU wants to 'Read'  that device - it issues 0x83.   (again avoiding conflict)

Getting the I2C Slave Device's Address 'right' - which requires knowledge of the Slave (as well of) the MCU's 'handling of that address' - is a question that most always lands here - when I2C commo fails...

Hello cb1,

I don't want to comment for sure if that is the standard across I2C Vendors, but I went ahead and found the API which uses the Slave Address from TivaWare:

void
I2CMasterSlaveAddrSet(uint32_t ui32Base, uint8_t ui8SlaveAddr,
                      bool bReceive)
{
    //
    // Check the arguments.
    //
    ASSERT(_I2CBaseValid(ui32Base));
    ASSERT(!(ui8SlaveAddr & 0x80));

    //
    // Set the address of the slave with which the master will communicate.
    //
    HWREG(ui32Base + I2C_O_MSA) = (ui8SlaveAddr << 1) | bReceive;
}

So changing the 7-bit address declaration would not indicate a change of read vs write (which is what I'd expect as you wouldn't usually only do JUST reads or JUST writes).

Hi,

The temperature_tmp006 example program is for the EK-TM4C123GXL + BOOSTXL-SENSHUB. If you are going to use this as base program to communicate with the BOOSTXL-SENSORS you need to change the I2C pins and TMP_INT used at the temperature_tmp006 example program. Use the Booster Pack Checker tool to check difference between pinout of BOOSTXL-SENSHUB and BOOSTXL-SENSORS.

dev.ti.com/.../

Also, I suggest you use the tmp007 code library from the MSP432 SDK which you can find at C:\ti\simplelink_msp432p4_sdk_1_60_00_12\examples\nortos\MSP_EXP432P401R\demos\boostxl_sensors_sensorgui_msp432p401r\src

-kel

Hello Ralph,

The API code you've just provided 'I2CMasterSlaveAddrSet()' reveals the following:

• the 7 bit I2CSlave Address is 'Left Shifted once'
• and that shift 'frees' the lsb of  'ui8SlaveAddr' to receive 'bReceive'   (which is a '1' for a read, a '0' for a write)

My earlier writing - describing that process:

As an example - using Markel's (earlier) first address value:  

• 0X40 - when shifted left (once) yields 0x80.    (that's an I2C device Write)
• when the MCU wants to 'Read' that device - it issues 0x81.

complies 'exactly' w/the API!    (both in the single, 'left shift' and the Or'ing in of '1' for an I2C Read, a '0' for an I2C write.)

I've checked the I2C management of (2 of the 3 other ARM MCU vendors) our firm employs - that (shift prior to OR) is (indeed) duplicated...