low power support?

[JimTal001]

Others have mentioned that on wakeup the RTC clock must initialize (consuming extra power), so if the RTC continues running after stop() and standby() then why does it need to initialize on wakeup?

[JimTal001]

Some questions regarding setting the CPU speed:

1. I read from a post that following the RTC wakeup event the CPU is always returned to it default state of 168Mhz. Is this true?
2. Can the CPU speed be set in the main program or does it need to be done in the boot.py only?
3. Are there specific values of CPU frequency one is allowed to use, e.g. 168MHz, 80MHz, ... if so, is this information documented?
4. Are there any issues one should be aware of when reducing the CPU speed? Like: will it affect REPL, i2c, 1-wire, etc..
5. If point 1 (above) is True and CPU speed can be set in the main program would this be the correct way to set and maintain the 60Mhz CPU speed?

Code: Select all

# main program
import pyb
pyb.freq(60000000) # initial setting of CPU freq to 60MHz
# is a delay here is necessary?
rtc = pyb.RTC()
rtc.wakeup(30000) # wake every 30s
while True:
    pyb.freq(60000000) # set CPU freq to 60MHz
    sensor.read()
    pyb.stop() # sleep in low power mode, waiting for the next wakeup trigger

Edit: I ran some test and may have found a bug related to setting the pyb.freq() value. I am logging data to an SD card after reading a sensor. If the CPU runs at 168MHz it all works fine. If I reduce the freq (like: pyb.freq(60000000) ) the program continues to run but no data is written to the SD card.

[pythoncoder]

@JimTal001 I'm not sure what you mean by the RTC reinitialising. If you put the Pyboard into standby, and wake it with rtc.wakeup() the Pyboard re-initialises, consuming a certain amount of energy as occurs after a hard reset: this will involve loading, compiling and running your code. The RTC simply continues running. In recovering from stop mode the Pyboard will presumably use less energy because the Python environment and the bytecode remains loaded. There is a tradeoff between the level of power consumption in these modes and the energy required to return to normal operation: if a program is to be woken more frequently than a certain rate I'd expect stop to be more energy efficient than standby. But it's the Pyboard rather than the RTC that's using the power (as I understand it).

[JimTal001]

I'm not sure what you mean by the RTC reinitialising

Damien's comment referring to power consumption following a wakeup event:
Posts: 298

The main thing contributing to a long startup is waiting for the RTC to initialise

[pythoncoder]

Fair point, I'd missed that. Perhaps Damien can clarify.

[rcolistete]

Is Pyboard v1.1 the best MicroPython board for low power mode while waiting for a pulse ? It seems a lot better than ESP8266 and ESP32, but what about Teensy 3.2/3.5/3.6 ? Or BBC Micro:bit ?

I need to detect an external pulse on a pin, from less than 1 Hz to hundreds of Hz and count them, while minimizing power.

With Pyboard, reading this topic shows that I need to use "pyb.usb_mode(None)", "pyb.freq" (with lower frequency) and "pyb.stop()", to achieve 0,3-0,5 mA while waiting for the pulse.

What about "machine.sleep()" ? Is it equivalent of better than "pyb.stop()" ?

[pythoncoder]

You will find information about Pyboard low power modes here.

tl;dr Deep sleep mode reduces current to a few μA but waking it can only be achieved in a limited number of ways and it effectively reboots the board. The sleep mode (~500 μA) is much less restrictive.