Improve code processing time

e d · ‎2017-06-27

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.

e d · ‎2017-06-30

Posted on June 30, 2017 at 14:15

For now cranking up the clock when needed is sufficient as discussed earlier. We cannot go to sleep completely but we can certainly go as low as possible on the clock elsewhere to service low priority stuff. DMA, if available later on when we change to another chipset, might not help much since we need to process the data on the fly. Can you elaborate on the other 'tricks' that haven't been considered here? Unfortunately this is the extent I can talk about the project, which is a highly classified and proprietary assignment.

AvaTar · ‎2017-06-30

Posted on June 30, 2017 at 17:24

We cannot go to sleep completely but we can certainly go as low as possible on the clock elsewhere to service low priority stuff.

The deeper the sleep mode, the longer the recovery/reaction times.

You might want to compare the current consumption and performance of different MCu variants according to your performance and reaction time requirements.

Unfortunately this is the extent I can talk about the project, which is a highly classified and proprietary assignment.

The less information you share (can share), the more vague the answers.

Allowing myself a personal comment, this sounds like project from an field I use to despise...

Andrei Chichak · ‎2017-06-30

Posted on June 30, 2017 at 22:29

What? If this is an ITAR kind of discussion:

1) you can't be having this discussion

2) I don't want any part of this discussion

Andrei, a foreign national

e d · ‎2017-06-30

Posted on June 30, 2017 at 22:31

I think I got all the answers I needed, vague or not. Thanks!

This project is quite intriguing to say the least. It is for the 'Houston we have a problem' agency if you know what I mean.

e d · ‎2017-07-01

Posted on July 02, 2017 at 01:16

No worries! Everything that was said here is in public domain. You can find all this stuff on a well documented source online. Plus, these numbers here are not exact, just good enough for a discussion. Relax...

AvaTar · ‎2017-07-03

Posted on July 03, 2017 at 07:49

It is for the 'Houston we have a problem' agency if you know what I mean.

Not that this would change my mind. There is more than meets the eye, there as well.

You could have asked Stanley Kubrick - a few years earlier ...

Oliver Sedlacek · ‎2017-07-06

Posted on July 06, 2017 at 09:55

Cranking the clock speed up when the core needs to do some processing is definitely the modern approach. The 'energy per instruction' doesn't change much, so the average power to perform a computation at a certain bandwidth doesn't change much. You can get something of a net gain though if you can disable more stuff for more time as you can sometimes get a reduction in quiescent current. If that doesn't work, you may have to go back to the hardware team