This question has been solved in Ti website and the following is the solution which he added:
From looking at the USCI Operation, I2C mode section in the MSP430x2xx >Family User's Guide SLAU144I I think the UCTXSTT bit will be cleared after >the slave has ACKed its receive address, and before the data has been read >from the slave. Therefore, the following in the Receive function could read >the UCB0RXBUF before the data has been received:
while (UCB0CTL1 & UCTXSTT); // Start condition sent? RXBuffer full?
receivedByte = UCB0RXBUF;
Try changing to:
while((IFG2 & UCB0RXIFG) == 0); // Wait until data read
receivedByte = UCB0RXBUF;
Chester Gillon's post
I fixed my problem by changing some parts in the Receive function. Thanks >to Chester Gillon's post, it made me realise that STT interrupt occurs >right after the slave ACK the master. After checking the user guide >carefully, i found this:
If a master wants to receive a single byte only, the UCTXSTP bit must be >set while the byte is being
received. For this case, the UCTXSTT may be polled to determine when it is >cleared:
So this STOP condition must occur after the ACK but before the second data >ACK. So i changed my receive function into this and it solved all my >problems:
uint8_t Receive(char registerAddr){
uint8_t receivedByte = 0;
while (UCB0CTL1 & UCTXSTP); // Ensure stop condition got sent
UCB0CTL1 |= UCTR + UCTXSTT; // I2C start condition with UCTR flag for > transmit
while((IFG2 & UCB0TXIFG) == 0); //UCB0TXIFG is set immidiately
UCB0TXBUF = registerAddr; //write registerAddr in TX buffer
while((IFG2 & UCB0TXIFG) == 0); // wait until TX buffer is empty and > transmitted
UCB0CTL1 &= ~UCTR ; // Clear I2C TX flag for receive
UCB0CTL1 |= UCTXSTT; // I2C start condition with NACK for single byte > reading
while (UCB0CTL1 & UCTXSTT); // Start condition sent? RXBuffer full?
UCB0CTL1 |= UCTXSTP;
while((IFG2 & UCB0RXIFG) == 0); // wait until TX buffer is empty and > transmitted
receivedByte = UCB0RXBUF; // I2C stop condition
return receivedByte;
}
Barışcan Kayaoğlu's post
Best Answer
Just to add a bit more explanation to the why's of using a gyro vs accelerometer for orientation: A gyro gives rotation rate, so to get orientation, we have to integrate:
orientation = Integrate(gyro_data, dt) + C
The C tells us we never get absolute orientation, only relative orientation. With the accelerometer, at least we get an absolute orientation with respect to gravity.
The integration tells us that our noise will accumulate over time, and our value for orientation will become worse as time goes on. We do not need to integrate to get orientation from accelerometer. Even if our gyro has less noise than our accelerometer, it might still make sense to use the accelerometer. It depends on the relative noise levels and how long you plan to sample.
Where the gyro shines is during dynamic motion of the device. We can use the combination of the gyro and accelerometer to better distinguish linear motion from change in orientation.