• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 79 subscribers
  • Views 283 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP430FR5964: Handling Interrupts for SPI RX and TX

Colin Morris
Prodigy 10 points
Part Number: MSP430FR5964

Hello, 

I'm running into a bit of an issue with SPI communication, and I'm trying to figure out what the best practice would be. I am attempting to handle the TX and RX using an ISR, however the eUSCI has only one interrupt vector that is shared for transmission and for reception. I have tried writing a single ISR to handle both interrupts, but it seems to sometimes miss, and I'm wondering if it's bad practice to do this, or if I should be able to get it to work. What would be the appropriate method for implementing SPI on this device, if I can only use one ISR for SPI? I have also tried polling using while(!(UCA0IFG&UCTXIFG))  and while(!(UCA0IFG&UCRXIFG)), but having trouble getting this to work for a packet size larger than 2. Also, as a side question, the UCTXIFG flag doesn't seem to clear when I write to the UCA0TXBUF, isn't it supposed to? 

I can post code if requested, but I am really looking for a general best practice for the hardware I have. 

Thank you 


  • 0
    Guru 88520 points

    Without more specifics, it's difficult to give a recommendation, but in general:

    1) For a master with a fast (SPI) clock, don't use interrupts at all; they'll just slow you down and complicate things.

    2) For a slave, you may not have a choice not to use interrupts. If you can't keep up you'll just have to slow down the master. Tx and Rx interrupts (mostly) occur simultaneously.

    3) Use DMA if you can (master or slave).

    To your side question: TXIFG does go low after writing TXBUF, but maybe not long enough to see.

**Attention** This is a public forum