Improve code processing time

[e d]

Posted on June 27, 2017 at 19:18

I am working with the STM32L486 and we aim to use as low clock speed as possible to conserve power. As a result, I need to improve the run time inside one high rate interrupt to meet the timing requirement. I was trying to place the routine in RAM using ramfunc but it didn't help much. I used to work with TI DSPs and this usually helped considerably. Any ideas why? Or general comments on how to speed things up, aside from running from RAM and turning on code optimization?

Thanks,

ED

Note: this post was migrated and contained many threaded conversations, some content may be missing.

[AvaTar]

Posted on June 28, 2017 at 07:55

What is it that you are doing in the interrupt?

As said, if your interrupt need to run continuously, and not only intermittent, you cannot really save power.

The common approach of low-power Cortex M is to run on high speed/high performance for a short time, and save power in sleep states for the rest of the time. This is more efficient than low-performance / low-power MCUs.

If your use case doesn't match to such a scenario, the L4 is not the right device for you.

[e d]

Posted on June 28, 2017 at 14:18

As I answered above the 'high performance' interrupt is only run at 100KHz for 1 second bursts every minute. I cannot shut down during 'off burst' due to having other procedures to take care of. We did consider processing data ahead and/or use pre-generated tables (requires 100KBx4) before feeding to DMA but this project is definitely going to ta cheaper part (could be outside of ST) that might not have gobs of memory or a DMA. Therefore a generic method using timer and processing data on the fly is needed. These stringent constraints are the challenges of the project that must be overcome.

[e d]

Posted on June 28, 2017 at 14:23

By the way, I did try to put the function in RAM at 0x100xxxxxx instead of 0x200xxxxxx and it seemed to help a tad (<10%), as stated byriggs.rob. Thanks!

[e d]

Posted on June 28, 2017 at 14:54

The answer is probably no but can I change the AHB prescaleron the fly?

RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV2;

If possible, I can go to a lower divider (higher speed) at burst time then go back to higher divider at off burst time.

[andy b]

Posted on June 28, 2017 at 21:11

Hi

Not sure if someone mentionned this already but If I were you I'd try to focus my use of certain peripheral and timers to use as less peripheral clocks as possible meaning you can shutdown  unused clocks so you will use less power.Lets say you dont use any timers in ''APB2 Timer clocks'' you can lower the frequency since you dont need it anyways.Dont know how optimised the projects are but I think its well worth to take a look and make sure you are not feeding power to things that you are not using.Good luck this seems like an interesting project.-Andy

[e d]

Posted on June 28, 2017 at 21:32

This is common knowledge but thanks anyway. I will definitely take some time to evaluate ALL the peripherals and turn off unnecessary modules, when the project is mature enough. Trust me, I will leave no rock unturned when it comes to this matter.

[Zt Liu]

Posted on June 29, 2017 at 00:37

Indeed, as I often forget to disable unused peripheral clocks, or lower the clock of less used peripheral.

Lower clk spped did help me, especially for those peripherals concerning outputs.

You may also set unused GPIO as analog.

This low power design is quite challenging, I usually first separate core power consumption and peripherals pw consumption. (Even a blinking led could kill my low power design. )

Good Luck!

[Jeroen3]

Posted on June 29, 2017 at 09:20

Ultra efficient is an understatement. You only have 192 clocks until the next event.

Of which you will lose about 24 to interrupt entry and return. 

Make it run faster!

[Andrei Chichak]

Posted on June 29, 2017 at 23:46

The other way to attack this problem is to crank up the processor clock as fast as you can, use DMA and all of the tricks in the book, to get your processing period down as short as possible. Then go to sleep as long as possible.

Sleeping will always be more power efficient than walking the processor.

Also, you'll probably find that the processor uses less power than all of the junk attached to it. Every aspect of the system has to be designed with power shutdown in mind.

Andrei

[AvaTar]

Posted on June 30, 2017 at 12:41

To decide about this issue, one needs to have more insight into the project requirements than published here.

At least some ideas to start with ...