• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 80 subscribers
  • Views 1414 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.

USCI (SPI) Interrupt vs. Delay Loop Power

Doug Jorgesen
Intellectual 290 points

Other Parts Discussed in Thread: MSP430F2619

Hello everyone, I have a question about how to lower the power consumption of my system.  I'm using an MSP430F2619 to drive an LCD using SPI (the LCD has a built in ST7565R controller).  

My question is when I am using SPI, after I load the UCxTXBUF (transmit buffer) with a new character, is it more efficient to use a delay to burn the necessary clock cycles, use a while(interrupt flag not set) loop, or go into a low power state and create an interrupt routine that somehow returns me to where I was at in the program?

Since I am running at an 8 MHz clock for maximum power efficiency, and the settling time for the controller chip is 50 ns, I can run the transmission at the full MCLK rate, or I could probably use other clocks, I just need to send about  .5 KB of data to the LCD around 10-20 times a second.

Thanks for the help!

  • 0
    Guru 227245 points

    Doug Jorgesen said:
    is it more efficient to use a delay to burn the necessary clock cycles, use a while(interrupt flag not set) loop, or go into a low power state and create an interrupt routine that somehow returns me to where I was at in the program?


    It depends on the SPI clock speed.

    Waking up from LPM requires 6µs typical (there are some faster MSPs) plus several MCLK cycles for storing return address and saving the registers. So if SPICLK is near to MCLK it makes no sense.

    Waiting for the bit may take more clock cycles than necessary. It is, however, compatible with an unknown SPI clock and will always work.

    Wasting exact clock cycles is probably the best idea if you know the exact SPI clock (especially if it equals MCLK). It allows highest throughput. You cannot enter and leave LPM and start an ISR in 8 clock cycles :)

    Doug Jorgesen said:
    I just need to send about  .5 KB of data to the LCD around 10-20 times a second.

    Well, I don't think power efficiency is a major problem for you then :)
    And after the bursts (0.5ms each, best case), you can enter LMP for the other 90% (20Hz) or 95% (10Hz) of the time :)

     

  • 0 in reply to Jens-Michael Gross
    Guru 12160 points

    Hi Doug,

    You might also consider using the DMA controller for sending the data block.  It will give you optimum SPI performance and leave the CPU free to handle other interrupts (or to go to sleep if you so choose) without impacting SPI throughput.

    If you do choose to go to sleep while the DMA works, you won't save much energy if the SPI bit rate is fast.  But sometimes every little bit counts.

    Also the DMA can process the Tx side of an SPI link at 2x MCLK and still leave 2 of every 4 MCLK cycles for CPU use.  Consider using a 16Mbps SPI link (8MHz MCLK, 16MHz SMCLK) or maybe an 8Mbps SPI link with reduced MCLK (4MHz MCLK, 8MHz SMCLK) to save some energy.  The idea falls apart if you also need to consider the Rx side of the SPI link.

    Jeff

     

  • 0 in reply to Jens-Michael Gross
    Intellectual 290 points

    Thanks for the help Jens-Michael.

    Jens-Michael Gross said:

    Waking up from LPM requires 6µs typical (there are some faster MSPs) plus several MCLK cycles for storing return address and saving the registers. So if SPICLK is near to MCLK it makes no sense.

    I'm not tied to using MCLK for SPICLK, I just read somewhere that 8 MHz was the optimal clock speed for power efficiency, i.e. it minimized the power per clock cycle.  I can run the SPI slower or faster if it would be better for power.  The reason I'm so concerned about power is that I want my device to last for as long as possible on a watch battery.

  • 0 in reply to Jeff Tenney
    Intellectual 290 points

    Thanks Jeff, I didn't know about the DMA before.  It sounds like it will do just what I want to do.  I don't need the RX at all, just the TX.  I just hope that I can get the clock phase/polarity set right...

  • 0 in reply to Doug Jorgesen
    Guru 227245 points

    Doug Jorgesen said:
     I just hope that I can get the clock phase/polarity set right...

    There are only 4 combinations :)

    About the DMA and transfer speed: the DMA requires MCLK, so if using DMA and put the CPU into sleep, MCLK still has to be reactivated for each DMA transfer - with the wakeup time of typically 6µs.

    Since you have to transfer 20*0.5k = 10k transfers per second, this means a wakeup every 100µs if you distribute the transfers evenly. However, if your transfer clock takes less than 6µs for one byte transfer, LPM is no option.

    It's better to complete the transfer as fast as possible and then go to sleep, than to permanently wake up and sleep for every byte.
    And if you have nothing else to do during the transfer, using DMA or wasting CPU cycles makes no difference in power consumption and transfer speed.
    DMA, however, can have a slight advantage if you cannot manage to align the data load/store operation so it exactly matches 8 bit clock cycles. It depends on where the data is stored and how you need/want to access it. If you write our funciton too modular, you perhaps cannot do a load/store, increment and check for transfer end withind 8 cycles.

  • 0 in reply to Doug Jorgesen
    Guru 12160 points

    You might already know, but TI inverted the meaning of the CPHA bit from the Motorola standard. TI calls it CKPH, and it is the opposite of CPHA.  Just something to watch out for.  The other bit (CPOL, which TI calls CKPL) is the same as Motorola.  Where you can get burned is when a peripheral says its a "Mode 0,0" or "Mode 0,1" peripheral etc.  For TI, you must invert the second bit to make it CKPH.

    Also, as JMG noted, if you decide to sleep during the DMA transfer, use LPM0 but not any deeper sleep.  You don't want the DCO stopping on you during the transfer.  One nice thing about the 5xx is the clock request feature that lets the USCI keep the DCO going even if you try to use LPM3 for example.  The 2xx doesn't have that feature, so be careful which LPM you request.

    Since you like the DMA approach, and since you need only the Tx side, I like MCLK=4MHz and SMCLK=8MHz.  It can really save you some energy during the transfer.  And MCLK=4MHz is great for everything else too.

    Jeff

**Attention** This is a public forum