Strategies for managing power consumption

[Jesper Ronnholm]

When we've moved from the development board to our own, custom hardware, we've started to look at the power consumption of our system as a whole. Obviously, the rendering process makes up a considerable part of our power budget.

When we've performed some rudimentary benchmarks on power consumption, it looks like the touchgfx application draws power even though we're not rendering any new stuff on the screen (which, by the way, is not using any touch controller HW or SW).

Moreover, when touchgfx is running, the power consumption seems constant - regardless of what's being updated on the screen. The only significant variable to power consumption seems to be the framerate.

(When blocking the touchgfx application from executing altogether, we save about 50mA on our STM32F769 MCU.)

Now, I know touchgfx is only supposed to update the parts of the framebuffer that have changed from frame to frame. But how is the touchgfx backend oriented for power efficiency?

Are there any useful rules of thumb in terms of power consumption?

[Martin KJELDSEN]

Hi @Jesper Rönnholm​,

This is an interesting topic, thanks for your in depth analysis.

We're not doing anything in terms of power consumption but to be as effecient at rendering as possible and doing as little as possible when nothing is required of us (e.g. Idle task is scheduled in). It's not quite clear to me how this relates to your tests, but if your application is not doing anything your power consumption reading should be coming from the idle task in my mind.

/Martin

[Jesper Ronnholm]

That's an interesting fact, since it would mean that the idle task consumes as much power as the rendering routine.

In terms of computational load, do you have an idea what part of managing and rendering a widget is the most costly?

[Martin KJELDSEN]

Forgot about this, sorry. That wholely depends on the widget. The most costly part is if the widget overrides ::draw() and takes a framebuffer lock to manipulate the data itself (usually just using CPU).

[Jesper Ronnholm]

Ok, so if the widget has a special behavior in how it updates the canvas, this is generally more costly?

Is there any clear example of for what kind of widget this is especially true?

[Martin KJELDSEN]

The Lens Example UI template from the designer. It has no elements in its root container - It simply overwrites ::draw() and goes to town on transforming pixels int he framebuffer to create a lens effect.