Low-Power Operation

Part 1, wherein we measure low power

June 5th 2017 by Amit

Easy to write low power applications is one of the main design goals of Tock. While we’ve basically built an architecture that should support it, we haven’t focused much yet on actually getting our development boards in to low power modes. That changed this week!

The screenshot above is from oscilloscope measuring power consumption on the imix development board running this basic blink application, which toggles the LED once every second:

int main() {
  for (;;) {
    led_toggle(0);
    delay_ms(1000);
  }
}

If you’d like to do the math yourself, the scope is measuring voltage across a 30kOhm resistor (yes, that’s way to strong to measure current when the CPU is active or LED on). If you’d rather we do the math for you, the average current draw when the LED is off is ~7uA¹.

This works without any coordination from the application because the kernel keeps track of which peripherals are being used and can go into very deep sleep states accordingly. In this example, when the LED is off, only the SAM4L’s asynchronous timer (AST) is being used, allowing the SAM4L to go into the WAIT or BACKUP sleep state, which should consume under 4uA (so we’re stilling missing about 2x efficiency there, probably due to leakage current on some of the GPIO pins).

Caveats

OK, to be totally honest, the kernel isn’t actually able to do this accounting properly just yet, and this example was hacked together to first make sure the board could go that low. But we’re getting there!

We measured this in pretty ideal conditions, including bypassing most of the passives and power indicator LEDs on the board and disabling hardware power domains that weren’t in use. Next step is to try to get similar results from the board under more realistic conditions.

Next steps

There are three next steps for low-power operation in the pipeline.

1. Measure power under more realistic conditions, e.g. with sensors and radios put to sleep rather than completely power-gated.

2. Implement support for the currently missing peripheral accounting in the kernel.

3. Build and measure end-to-end some realistic applications, such as an environment sensor that advertises data over BLE or 802.15.4. I did some back-of-the-envelope calculations and we should be able to run such an application at around 200uA with a low-enough (but still useful) duty cycle.

1. As a rough benchmark for how low that is, 7uA is low enough to run on a coin cell battery for about 4 years, or two AA batteries for fourty. ↩