• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 46 subscribers
  • Views 568 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

ADS1158 <-> MSP430 SPI communication

Sergey Tarassenko
Prodigy 205 points
Other Parts Discussed in Thread: ADS1158

Hello all

I had recently to implement SPI communication between MSP430 and ADS1158. That's my almost first experience with SPI therefore I'm not sure if my method is correct (Though it gives me correct results.). Could you please confirm If I'm using correct procedure?

SPI configuration I'm using is:

 UCB0CTL0 = UCCKPH+UCMST+UCSYNC+UCMSB;
 UCB0CTL1 = UCSSEL_2;
 UCB0BR0 = 0x02;  /*Bit rate divider, LB = divide clock by 2 = 4MHz*/
 UCB0BR1 = 0;

MCLK is 8 MHz from DCO using calibrated values, ADS1158 uses 32kHz crystal. CS is tied to low .

In order to send/receive bytes via SPI I'm using following procedure:

while(!(IFG2 & UCB0TXIFG));
UCB0TXBUF = ucValue; // Either value to send or dummy byte
while(!(IFG2 & UCB0RXIFG));
ucResult = UCB0RXBUF; // or just IFG2 &= ~(UCB0RXIFG) to reset RX flag if getting don't care data

Then I just repeat 4 operations above until I get all data I want.

Is it correct to wait for UCB0RXIFG always after I have transmitted command byte or dummy byte (to receive data)? I've seen SPI implementation waiting only for UCB0TXIFG, but such version didn't work for ADS1158 well.

The procedure above gives me always correct results, but I noticed that it takes around 35us to get channel data in register format whereby it should take around 6us theoretically (at 4 MHz SPI). I tried to investigate this, but oscilloscope I was using wasn't good enough to represent 2 channels simultaneously. Though I noticed that there is a pause in UCLK after each transmitted byte. Any idea what could cause such behavior?

 

  • 0
    TI__Guru**** 180741 points

    Hi Sergey,

    Waiting for the RX flag is correct - that is actually what is causing the extra delay.  If you get your scope configured properly to look at the SCLK in detail, you'll notice the delta in time from 6us to 35us is caused by a delay between bursts of eight clock cycles.  Not sure which MSP430 variant you are using but those with the USART usually only support an 8-bit transfer.  You could possibly speed things up a little by adding NOPs instead of waiting for the RX flag.  This has a draw back though should you happen to change the baud rate settings, you'd have to adjust the delay timing as well.