Reducing Power Consumption

[chipaudette]

With my Teensy Hearing Aid project (based on a Teensy 3.6), I was curious how much power I was consuming...so I measured it. I was surprised to see that it took 90 mA to run my system. So, I looked for ways to reduce the power. One very easy and successful technique was to add a WFI command asm(" WFI"); to my loop() function. It puts the processor to sleep instead of looping pointlessly. I found that it cut my power consumption by a third, which means that my battery life increased 50%. Not bad!



What's really nice is how well it works with the Audio Library. The WFI command only works if the system has been configured with an Interrupt. I don't (yet) know how to do this. But, since I'm using the Audio Library, it already fires a bunch of interrupts in the background. I didn't have to add anything! Just add the single WFI command and you're done. The easiest power that you'll ever save.

If you're interested, more detail is here: http://openaudio.blogspot.com/2016/11/reducing-current-draw.html

What other techniques can I use to save power?

Chip

 

[defragster]

What speed are you compiled at? if something over 120 MHz you could try to see what works or not when you drop to 120? Paul made this to get T_3.6 EEPROM to work - I wonder what this does for you?::

    kinetis_hsrun_disable();
    asm(" wfi");
    kinetis_hsrun_enable();

It moves even lower down the power draw table toward 44 mA- but may affect some things when it wakes depending on what active devices are onboard.

 

[chipaudette]

What speed are you compiled at? if something over 120 MHz you could try to see what works or not when you drop to 120? Paul made this to get T_3.6 EEPROM to work - I wonder what this does for you?::

		kinetis_hsrun_disable();
		__ASM volatile ("wfi");
		kinetis_hsrun_enable();

It moves even lower down the power draw table toward 44 mA- but may affect some things when it wakes depending on what active devices are onboard.

I don't understand your question. As shown in my figure in my first post, I measured the current draw (with and without WFI) across a range of clock speeds...everything from 24 MHz up to 240 MHz. WFI is effective at all speeds, though (obviously) it has less impact at the slower speeds.

Are you suggesting that there is another way to call WFI that might be even more effective? If so, that'd be great!

Chip

 

[defragster]

The question is what speed you compile/run at? If over 120 MHz the code above ( edited ) should drop CPU speed to 120 MHz before the WFI, and further reduce the power during the WFI period.

 

[chipaudette]

The question is what speed you compile/run at? If over 120 MHz the code above ( edited ) should drop CPU speed to 120 MHz before the WFI, and further reduce the power during the WFI period.

I compiled and ran at the range of speeds shown in my graph. So, I did speeds below 120MHz and speeds above 120MHz.

But I think that I might understand your suggestion now. I think that you are suggesting that, even if I compile for 180 MHz, that I should use your code to slow the processor down to 120 MHz prior to issuing the WFI command. That's a very interesting suggestion.

Will dynamically changing the run speed in this way negatively affect the background processes such as the Audio library's DMA activities? Will it affect how the millis() timer counts?

Thanks,

Chip

 

[defragster]

Yes, that is why I was wondering your current speed selected when you compiled - assuming your intended application use. And as noted - it will have side effects - you'll have to determine if they affect the things in use.

 

[defragster]

I did a sketch that goes from 95 mA to 33 mA with above on T_3.6. But hsrun_disable change in processor 240 to 120 MHz slows time 2::1 as the wake interrupt is the systimer.

WFI alone drops current to 48 mA when staying at 240 MHz - so that part matches your results.