• Locked Locked
  • Replies 7 replies
  • Subscribers 79 subscribers
  • Views 2031 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.

SPI example Demo MSP430

Juergen Rieger
Intellectual 495 points

Hello ....

I have used an example SPI example MSP-FET430P140 Demo - USART0, SPI 3-Wire Master. This example does not work for me. In this example the UTXIFG0-flag (TXBUF0, Register IFG1) is teste in an Interrupt. If I do that a hungup is the result.

I have found a better way, when I test the UTXIFG0-flag outside the Interrupt and I disable the UTXIFG0-Interrupt  in an Interrupt. When the buffer is empty, the UTXIFG0-flag goes high and the UTXIFG0 interrupt can be enabled.

Regards Jürgen Rieger

  • Guru 227245 points

    Indeed, the example code isn’t the best. It only works for exactly the demonstrated usage case (just like the UART loopback examples).

    However, your solution sounds like being similarly limited (for your specific usage case).

    Usually, you shouldn’t test IFG bits outside an ISR (unless you don’t have an ISR at all and want to do polling). And inside an ISR, they only need to be tested to check which IFG bit triggered the interrupt, but they shouldn’t be waited for. In general, an ISR shouldn’t do any waiting loops, whether for an IFG bit or for making a delay.

    In my own UART code, I have a ring buffer. As soon as the buffer is empty (when the ISR has taken the last byte from it and wrote it to TXBUF), the ISR will clear the TXIE bit. When teh code writes something in the buffer, it sets the TXIE bit (which in case of an idle UART willl immediately call the ISR). This allows seamless operation without checking the transmission state in main.

  • in reply to Jens-Michael Gross
    Intellectual 495 points

    Hello Jens-Michael,

    thank you for your answer. I have seen the post only now today. I will test your proposal.

    Best regards

    Jürgen Rieger

  • in reply to Jens-Michael Gross
    Intellectual 495 points

    Hello Jens-Michael,

    I have dealt with your proposal. With the TXIE bit you mean probably UTXIEx. This bit can disable or enable the interrupt. To test whether the transfer is done can not be used this bit.

    Best Regards Jürgen

  • in reply to Juergen Rieger
    Guru 227245 points

    Well, the fact that the ISR has cleared the IE bit indicates that the ISR has written the last byte to TXBUF. However, the task was to stop further interrupts when there is nothing more to send. Not to detect that sending is complete.

    So simply disable itnerrupts (but leave TXIFG set, if it is set) when the buffer is empty (so the ISR isn’t called) and enable them always (even if already enabled) when something is written to the buffer (which will instantly call the ISR, if TX was idle, but when there is already an ongoning transfer, it won’t change anyhting and leave things as normal).
    Believe me, it works perfectly for 4 independent full-duplex UART streams with 115KBd on a 5438. :)


    In neither case you can detect the end of the physical transfer, as TXIFG gets set when the last byte written to TXBUF starts sending, not when sending is complete.
    Using UCBUSY won't help too, as it may indicate incoming activity and not get clard when sending is done.
    If you want to detect when the last byt has been finished sending, you should set a timeout timer inside the ISR that is reset when the last byte is written to TXBUF and has a duration of 20 bits. (the ISR doesn't know whether the byte before is stills ending, so 2 bytes have to be set for timeout - or a more complex algorithm)

  • in reply to Juergen Rieger
    Intellectual 720 points

    Hello Juergen,

    Jens methods works perfectly. I had implemented the same. Think about enabling UTXIE as enabling transmitter, transmitter transmits all your data and disables itself.. IRQ tests if it has data to transmit, if not disables UTXIE.

    But, as Jens also mentioned this is not a "Transmit Completed" event. Are you trying to transmit single byte, or transmit series of data and find out the exact time the transmission ended? It would be nice if TI added more IRQ's, however in serial programming you usually do not need that precision..

  • in reply to Jens-Michael Gross
    Intellectual 720 points

    "Believe me, it works perfectly for 4 independent full-duplex UART streams with 115KBd on a 5438"

    46080 IRQ's/s.. You just stall the MCU.. With respect to other discussion between us on this, I think we both need to implement DMA.. :)

  • in reply to Deniz Can Cigsar
    Guru 227245 points

    Well, on 16MHzs CPU speed, this is 350 clock cycles per interrupt (175 on full duplex), way more than needed. Of course it will no leave too much processing power to the CPU. But still more than a 4MHz MSP without any interrupt :)
    Also, there are not always transfers in both directions and on all four interfaces. So most of the time the CPU has nothing to do. But worst case, it is still not more than the CPU could handle.

**Attention** This is a public forum