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 27, 2017 at 19:51

The Flash interface is, as far as I remember, accessed 128 bit wide, i.e. four words are fetched at once into a prefetch buffer.

The RAM has no such interface.

RAM functions are useful on STM32 (and many other Cortex M) merely when the Flash is unaccessible (erase/program).

... we aim to use as low clock speed as possible to conserve power.

... I need to improve the run time inside one high rate interrupt to meet the timing requirement.

Both requirements are in contradiction to each other.

If your high-rate-interrupt is required to run all the time, you can hardly save any power.

If not, go into one of the sleep modes as often as possible.

[e d]

Posted on June 27, 2017 at 20:32

The external clock we will use is 19.2MHz and the high rate interrupt is 100KHz, which gives me 10uS to process things in there. The interrupt is run in 1 second bursts every minute or so. For a slow clock like with the 19.2MHz I would have to be ultra efficient and/or find a way to speed up, hence the question. Going into sleep modes is not an option since we need to run other low speed stuff during 'off burst' time. The hardware guys think we could save battery power by going as slow as possible. I personally want to run at least 40MHz or faster.

[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!

[Rob.Riggs]

Posted on June 27, 2017 at 19:53

What address in SRAM is your code?  This makes a difference.  Code in SRAM2 will run much faster at it's 0x10000000 address base than at it's remapped 0x200xxxxx address.

At slow clock speeds, where Flash wait states are low, the performance difference is negligible especially if ART is enabled.

[Tesla DeLorean]

Posted on June 27, 2017 at 20:35

In the ART case the prefetch pipe effectively gets the data in the current cycle, ie sub 1-cycle the RAM would take. Only the FLASH is cached, and the flash line is wide, 128-bit in the F4 case as I recall.

[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.

[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 ...