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.

MSP430FR2475: Questions about I2C example code

Part Number: MSP430FR2475

Hello, 

I have a few questions about the I2C driver code in the resource explorer for MSP430FRxxx.

1. In the MSP430 example code for the I2C driver, I found a function called 'CopyArray'

```

void CopyArray(uint8_t *source, uint8_t *dest, uint8_t count)

{

    uint8_t copyIndex = 0;

    for ( copyIndex = 0; copyIndex < count; copyIndex++ ) {

        dest[copyIndex] = source[copyIndex];

    }

}

```

there doesn't seem to be anything special about the source or destination buffer here. Is there any reason to use CopyArray over memcpy, which allows one to directly copy source buffer to destination buffer without use of a loop?

2. In the I2C ISR, there are some global variables used to keep track of Rx and Tx count, namely, `RXByteCtr`  and `TXByteCtr`. These globals are modified both in the ISR and outside of the ISR.

In the `I2C_Master_ReadReg`  function, both of these variables are modified (RxByteCtr set to count, TxByteCtr set to 0) before disabling Rx interrupt: 

```

    RXByteCtr = count;

    TXByteCtr = 0;

    ReceiveIndex = 0;

    TransmitIndex = 0;

    /* Initialize slave address and interrupts */

    UCB1I2CSA = dev_addr;

    UCB1IFG &= ~(UCTXIFG + UCRXIFG);      // Clear any pending interrupts

    UCB1IE &= ~UCRXIE;                    // Disable RX interrupt

```

and similarly in `I2C_Master_WriteReg`. Won't this cause problems where the Rx/TxByteCtr might get modified after being set, since the interrupt isn't disabled before modifying/reading the value? Also, should the variables not be declared as volatile and static to this I2C driver file? 

Warm regards,

Samyukta

  • Hi Samyukta,

    You could replace copy array with memcpy, the implementation just provided transparency into the operation, but you would need to include <string.h> so this adds some slight memory overhead.

    With regards to the example flow you are correct, there is a possibility that the count could get modified before the interrupts are disabled. But this is the controller side, so the device dictates when the target will send data, that being said you could get some stray signal that can cause the Byte Counters to have their values changed. If you wanted to prevent the possibility then disabling the interrupt then setting the Byte Counters would be the best way.

    For this implementation the volatile and static wouldn't change the program. Since the variables are declared globally they maintain scope through the whole program so the static variable isn't necessary. I don't believe the compiler is touching those variables in any way so volatile isn't necessary but it wouldn't cause any issues if you added it for consistency purposes or to prevent the possibility.

    Regards,

    Luke

**Attention** This is a public forum