Sleep and wake up

[bobricius]

Hi, I am sorry for opening similar issue, now without RTC feature.

I missing only one feature, It can very help for battery operated devices.
Sleep and wait for button for wakeup, I thing that it can be great advantage to expand cpython to wearables. This guys make something for sleeping but wake not working https://github.com/edgecollective/circuitpython. Can anybody make this feature?

[ladyada]

hiya - this would be same as #119 - we'd need #544 first, because you cannot sleep with USB connected :)

[tannewt]

This is definitely on my radar. I think one of our major releases should focus on battery-operated datalogging. Saving battery life isn't simple because of peripheral and clock management too. I'd also like to tackle flash wear leveling to coincide with that.

I'm happy to advise anyone trying to do this earlier but its not a focus for us yet.

[bobricius]

my God, and I thought that it would be only one instruction. It is really complicated thing.

[crowecawcaw]

I am interested in implementing some version of low power sleep for the nrf52840. From looking through the code it bit, it seems like there are timers and loops that need to be run continuously for CircuitPython to function as expected which complicate the issue.

My first goal would be to implement a new module to sleep on command. A secondary goal would be to merge the low power code in with the time.sleep function.

Could someone give me some pointers on where to start, what things to keep in mind, and what traps you'd foresee?

[dhalbert]

We currently use the SysTick timer in all our ports for general timekeeping (msec ticks and smaller): see ports/nrf/tick.c. SysTick is available on all M0/M4 processors: it is not manufacturer-specific. SysTick is based on the processor clock; when the processor sleeps, its clock is turned off, so SysTick will stop working.

So tick.c et al would need to be changed to use the RTC instead. The RTC can be set up to run all the time, even during sleep. There are similar RTC peripherals on the other chips we support.

This is a substantial change in the timekeeping logic. it's possible, and makes sense, but it requires some thought.

[tannewt]

@crowecawcaw I'd recommend starting without usb and just loading code over a debugger. USB is timing critical and will be unhappy if the background task isn't called. Once you get it going off of usb then I'd start by just disabling sleep when on usb. Later, if needed, we can make it work with usb.

[crowecawcaw]

This may be a silly question but is there a good way to develop and debug the CircuitPython source? Does anyone have suggestions for a free IDE that could make things easier? Right now, I'm editing code, compiling, and refreshing every change but it's difficult to tell what's going on without breakpoints or the like.

[sommersoft]

@crowecawcaw, when I was dev'ing primarily on Win10, I used Atmel Studio 7. Breakpoints and I/O registers were a bit of breeze. The [major] downside though was being forced to compile in a VM. It may be possible to overcome that, but I never figured out a way.

I did try to get Segger Embedded Studio working as an IDE on Linux and Win10, but never got anywhere with it.

On Linux, using GDB became just as fast as AS7 in most cases. Especially after I started using a breakpoints file. That reduced some iteration time by only requiring source <filename> whenever I had to set common breakpoints.

[crowecawcaw]

After spending some time looking through the code base, my plan is to make a module that has a function low_power_sleep() that will put the processor in a low power state until the time elapses. From what I can tell, there are 3 types of timers in play:

• RTC: This is constantly running and is used for time.time(). It runs even if the processor is in low power modes.
• SysTick: Based on the processor clock cycles (very precise) and is used for general timing including time.sleep() and time.monotonic() and for controlling timeouts in various functions (e.g. waiting for characters from the UART)
• Timers: The general timers are configurable for different frequencies. They are used for PulseOut, PWMOut, and internally for Bluetooth. The nrf52840 has several of these. The processor can go into some low power modes but not others while the timers are running.

My thought is to use a general purpose timer for tracking time while sleeping because there are unused timers that can be configured and run without interacting with any other code. The side effects will be that the usb background task will not run and that time.monotonic() and SysTick will not increment while sleeping.

Does all of this seem correct? Does my approach seem reasonable?

[deshipu]

I wonder if we should have separate issues for tracking this on different ports?

Personally, I would be more interested in being able to wake up on a gpio change than on a timer, so that we can get rid of those power switches from our hardware designs.