5 docs tagged with "power-management"

Two habits do most of the work in a low-power design that never touches Sleep, Stop, or Standby at all the energy cost of a fixed piece of work is not simply proportional to clock speed.

Every battery-powered product answers one question before any other design decision matters a firmware team that only measures active current and ignores what the part draws asleep will overestimate lifetime by orders of magnitude, and a team that only reads the nameplate mAh off a battery datasheet without reading the discharge curves will do the same in the opposite direction.

Every figure in this folder so far has come from a datasheet table or from arithmetic built on one. Neither tells you what your board actually draws. A datasheet's Stop-mode current is measured on ST's own characterisation board, with nothing attached to the GPIOs, a specific silicon revision, and every peripheral in the state ST chose to test it in; your board has a pull-up ST did not model, a status LED that never got gated, and firmware that may or may not be entering the mode it claims to. Energy Budgets's entire arithmetic is only as good as the I_avg fed into it, and the only way to know that number is real is to measure it on the actual hardware running the actual release firmware — the warning on that page about a demo build with logging left on exists precisely because nobody measured until it was too late.

A low-power mode is not one switch, it is a set of trade-offs arranged along a slider first the CPU clock, then every clock and the main regulator, then the regulator's own supply to everything but a small backup island.

Every page so far in this folder has been about what happens once the core decides to sleep. This one is about the decision that matters more than any of them 90 ms of idle Run mode cost roughly two orders of magnitude more than the same 90 ms in Stop.