I have to decide on a way to measure the efficiency of an algorithm running on a microcontroller/microprocessor.

My thought is that I can use the runtime of the algorithm to complete a certain task as an indirect measure of how the power consumption of that algorithm compares to another algorithm's power consumption. This would only make sense though, if the time spent in operation of the microcontroller was directly related to its power consumption. Is this assumption true?

The microcontroller runs under the exact same conditions with each algorithm, same peripherals etc.

  • \$\begingroup\$ I would think: obviously not. Say the algoritm takes 2 ms in clock cycles, and a peripheral raises an interrupt every 5 ms. Then, one moment the algoritm is not interrupted and finishes in 2 ms, an other moment the algoritm is interrupted by the peripheral and finishes in 3 ms. \$\endgroup\$ – Huisman Apr 28 '20 at 9:52
  • 1
    \$\begingroup\$ I fully agree with you @Huisma But imagine we are only concerned about the execution time of the algorithm in a controlled test environment, without any external interrupts or uncontrolled variables acting on the microcontroller. Would the assumption of operation time being proportional to power consumption/efficiency then be a viable option? \$\endgroup\$ – Steve Melons Apr 28 '20 at 10:05

There are many things that alter the power consumption of the device, but assuming your just computing an algorithm with all unused peripherals switching off, e.g. ADC (pulsing current each sample), GPIO (changing state consumes a small amount of current), watchdog circuit disabled (runs a clock and triggers an interrupt),

Then yes, the longer something takes to compute, the more power it has consumed, there is a trade off between clock speed and total power consumption (for most devices running at the highest clock speed for the shortest time uses less energy than a slower clock for a longer time) however again assuming that all stays the same, longer time = more power

If you want to start including other peripherals, towards the bottom of the datasheet for your device you will find chart after chart after chart outlining what the power consumption is for your particular use case, and various other relations, e.g. if you have the pin pullup left on, how long your switching that pin low increases consumption, if your driving something else in the signal, it will consume something in both high and low states, if your using ADC's, then the input buffers will have a non linear current draw depending on the input voltage. (usually you would disable them)

  • \$\begingroup\$ Would the type of instructions matter? Eg. if multiplication uses more power than addition, it may beneficial to three additions instead of a multiplication by 3, the first increasing the operation time \$\endgroup\$ – Huisman Apr 28 '20 at 10:21
  • \$\begingroup\$ Usually the power consumption of the ALU is consistent per clock, as multiply and add a re usually single cycle hardware functions, there probably is not much to save there, scaling your divisions so they are multiply by some constant then divide by power of 2 can save a lot of clock cycles if divide is not implemented in hardware, equally using the correct data sizes and types will probably save you clock cycles, e.g. a 16 bit micro takes 2 cycles to shift in or out a 32 bit value. \$\endgroup\$ – Reroute Apr 28 '20 at 10:42
  • \$\begingroup\$ Other things can be to look at the underlying assembly, the math libraries and compiler may not be giving you the best implementation for a specialised task, \$\endgroup\$ – Reroute Apr 28 '20 at 10:43
  • \$\begingroup\$ Other things if your keen is most micro controllers have some spare hardware registers that it can access and perform operations on with shorter instructions than if placed into ram (8 bit address vs a 16 bit address once past the first 256 bytes in the memory map), as each 2 bytes read from the program code in a 16 bit micro is also a clock cycle. combine this with knowledge of reverse polish notation (setting up math so values never need to leave the ALU) and you can shave off some extra cycles \$\endgroup\$ – Reroute Apr 28 '20 at 10:54
  • \$\begingroup\$ The optimizations you speak of here should be done by the compiler though, assuming that a higher level language like C is used. \$\endgroup\$ – Lundin Apr 28 '20 at 10:59

Is microcontroller power consumption directly related to its operation time?

Kind of. What draws most current is the CPU clock and any active hardware peripherals such as GPIO. Hardware peripherals being a story of their own since each one has unique power consumption characteristics.

There is of course a direct relation between CPU clock cycles needed and the length of the machine code executed, so there is also a relation between CPU clock cycles and current consumption.

This given that you utilize sleep modes when you aren't running any code, or otherwise it is pointless to speak of algorithm current consumption.

The efficiency of the algorithm, the "code efficiency" of the CPU and the hardware current consumption per tick all play part. Code efficiency in this case means how many CPU ticks it takes to execute a certain piece of higher layer program code (C code etc).

For example, some people argue that 8 bit MCUs should still be used because they draw less current than 32 bit ones. This tends to be true if you look at peak current consumption, but not necessarily so if you look at current consumption over time.

Take something like the C code my_uint32 = u32a + u32b;. The average 32 bit CPU will execute that line in a few assembler instructions, which perhaps means somewhere around 10-20 CPU ticks. An 8 bit MCU however, will need hundreds of assembler instructions in the form of software libs to execute the same code. Maybe 500-1000 CPU ticks, very roughly counted. So it could take the 8 bitter as much as around 100 times more execution speed/current consumption to run the very same code. And then it is suddenly irrelevant that the MCU draws less current per tick compared to the 32 bitter.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.