TM4C1294NCPDT: TM4C129x I2C FIFO Operation

Hello Mohamed,

To add to cb1's advice, we do have a burst example coming with the new TivaWare but not using FIFO mode, you can see how we handle it here though:

//*****************************************************************************
//
// This function will read three 8-bit data from the I2C slave. The first
// two 8-bit data forms the humidity data while the last 8-bit data is the
// checksum.  This function illustrates three different I2C burst mode
// commands to read the I2C slave device.
//
//*****************************************************************************
void
I2CReadCommand(uint32_t * pui32DataRx)
{
    //
    // Modify the data direction to true, so that seeing the address will
    // indicate that the I2C Master is initiating a read from the slave.
    //
    MAP_I2CMasterSlaveAddrSet(I2C7_BASE, SHT21_I2C_ADDRESS, true);

    //
    // Setup for first read.  Use I2C_MASTER_CMD_BURST_RECEIVE_START
    // to start a burst mode read.  The I2C master continues to own
    // the bus at the end of this transaction.
    //
    MAP_I2CMasterControl(I2C7_BASE, I2C_MASTER_CMD_BURST_RECEIVE_START);

    //
    // Wait until master module is done transferring.
    // The I2C module has a delay in setting the Busy flag in the register so
    // there needs to be a delay before checking the Busy bit.  The below loops
    // wait until the Busy flag is set, and then wait until it is cleared to
    // indicate that the transaction is complete.  This can take up to 633 CPU
    // cycles @ 100 kbit I2C Baud Rate and 120 MHz System Clock.  Therefore, a
    // while loop is used instead of SysCtlDelay.
    //
    while(!MAP_I2CMasterBusy(I2C7_BASE))
    {
    }
    while(MAP_I2CMasterBusy(I2C7_BASE))
    {
    }

    //
    // Read the first byte data from the slave.
    //
    pui32DataRx[0] = MAP_I2CMasterDataGet(I2C7_BASE);

    //
    // Setup for the second read.  Use I2C_MASTER_CMD_BURST_RECEIVE_CONT
    // to continue the burst mode read.  The I2C master continues to own
    // the bus at the end of this transaction.
    //
    MAP_I2CMasterControl(I2C7_BASE, I2C_MASTER_CMD_BURST_RECEIVE_CONT);

    //
    // Wait until master module is done transferring.
    //
    while(!MAP_I2CMasterBusy(I2C7_BASE))
    {
    }
    while(MAP_I2CMasterBusy(I2C7_BASE))
    {
    }

    //
    // Read the second byte data from the slave.
    //
    pui32DataRx[1] = MAP_I2CMasterDataGet(I2C7_BASE);

    //
    // Setup for the third read.  Use I2C_MASTER_CMD_BURST_RECEIVE_FINISH
    // to terminate the I2C transaction.  At the end of this transaction,
    // the STOP bit will be issued and the I2C bus is returned to the
    // Idle state.
    //
    MAP_I2CMasterControl(I2C7_BASE, I2C_MASTER_CMD_BURST_RECEIVE_FINISH);

    //
    // Wait until master module is done transferring.
    //
    while(!MAP_I2CMasterBusy(I2C7_BASE))
    {
    }
    while(MAP_I2CMasterBusy(I2C7_BASE))
    {
    }
    
    //
    // Note the third 8-bit data is the checksum byte.  It will be
    // left to the users as an exercise if they want to verify if the
    // checksum is correct.
    pui32DataRx[2] = MAP_I2CMasterDataGet(I2C7_BASE);
}

Hello Ralph,

Good to see this - poster & my crüe thank you.

Do you believe that poster's desire to, "Read 3 I2C bytes" is sufficient justification to add the complexity of the "BURST_FIFO" style Commands?"

Perhaps even of greater interest/value - might you outline,

"When the transition from (the simpler) "I2C_MASTER_CMD_BURST  functions TO (the more complex) I2C_MASTER_CMD_BURST_FIFO" function group appears indicated?"     Also - what (measurable benefits) may result from such 'added complexity?'

Such detail likely makes this "CMD_BURST_FIFO" function far more compelling.   Without this detail (nowhere explained that we can tell) more questions than answers arise...    Thank you...

Hello cb1,

That is a good question to raise, especially given right now we are talking 3 bytes which appears to be a small amount.

One thing I found in a past post from Amit is a comment that "I2CFIFODataGet will get only one byte at a time. The true value of the FIFO comes when the uDMA is used."

Another consideration here is that the FIFO buffers are only 8 bytes deep.

The FIFO's can be configured with specific threshold points to trigger the FIFO service interrupt.

For how uDMA ties into this, there are the following details from the D/S for Master Module µDMA Functionality:

When the Master Control/Status (I2CMCS) register is set to enable BURST and the master I2C µDMA channel is enabled in the DMA Channel Map Select n (DMACHMAPn) registers in the µDMA, the master control module will assert either the internal single µDMA request signal (dma_sreq) or multiple µDMA request signal (dma_req) to the µDMA

A single µDMA request (dma_sreq) will be asserted by the Master module when the Rx FIFO has at least one data byte present in the FIFO and/or when the Tx FIFO has at least one space available to fill. The dma_req (or Burst) signal will be asserted when Rx FIFO fill level is higher than trigger level and/or the Tx FIFO burst length remaining is less than 4 bytes and the FIFO fill level is less than trigger level.

If a single transfer or BURST operation has completed, the µDMA sends a dma_done signal to the master module represented by the DMATX/DMARX interrupts in theI2CMIMR/I2CMRIS/I2CMMIS/I2CMICR registers.

My personal view based on the information presented above is that 3 bytes would not justify the use of FIFO w/ uDMA, and I would just use a standard three byte burst. The one case I could see otherwise is to be hands off with the RX process via uDMA and just fetch the data with an interrupt, but I feel you would have to be in some very timing critical applications to make those added hurdles worthwhile just for a few bytes.

Thank you, Ralph.    That's great past detail - yet users (especially my group) remain in the dark as to:

• when to employ "I2C_MASTER_CMD_BURST" vs."I2C_MASTER_CMD_BURST_FIFO."
• and what benefits are to be expected (if any) through the use of the (more complex) "I2C_MASTER_CMD_BURST_FIFO."

Unless I am (especially) dense - far more detail (especially 'well commented' code examples) is required before users can benefit (at all) from these, "8 FIFO_BURST" (pardon) "mystery parameters!"

The µDMA adds to the complexity mix - yet the (almost) "TOTAL LACK of CLEAR "BURST_FIFO" USAGE EXPLANATION" is likely to produce, "An endless loop of frustrated users - yearning to effectively, "Exploit & Benefit from that Parameter SWELLING!"

Thanks for your kind.