Hi Sterling,
I'm sure it's in the planning, but there should definately be some sort
of callback at the BSP level before going into a lower sleep state (deep
sleep or halt), as well as after wakeup. This will allow you to
configure pins accordingly to disable external pullups, avoid as much
leakage current on the GPIOs as possible, perhaps switch to a lower
voltage if you're using a special dual voltage regulator to save power,
etc. And then when we wakeup the wake callback can be used to put the
pins back to their pre-sleep state.
I assume that's what you meant though by "application hook for each
system state", but we should probably be aware of both entering and
exiting a specific state since there is BSP specific work on both ends.
K.
On 08/09/16 19:13, Sterling Hughes wrote:
Howdy,
I’m finally getting to implementing the low power support in mynewt,
and I was hoping for comments from folks on the list before I get
started. I chatted with will, marko and paul about this a bit, and we
think this is a reasonable set of first features, although we all
wanted to mull it over.
We came down to the following set of goals for the OS:
- Provide standard definitions for drivers to provide the following
functionality:
- On
- Off
- Suspend
- Resume
Where On turns on the peripheral and initializes it, Off turns off the
peripheral such that it must be re-initialized, Suspend turns off the
peripheral, but without requiring it to be fully re-initialized, and
Resume takes the peripheral out of the suspend state.
- Provide a standard set of system states that users of Mynewt can
transition the kernel into, in order to provide low power operation.
This includes:
- Running
- Sleep
- Deep Sleep
- Halt
Where Running is normal operation, Sleep is WFI (processor off,
interrupts enabled), Deep Sleep represents a state where all drivers
are suspended, and Halt is the processor is essentially turned off.
- Allow user defined applications to set power policy based upon the
system states: i.e. an application hook for each system state where
additional behavior can be defined.
- (future) Provide a method to newt by which certain tasks memory can
be linked earlier in RAM, so that for systems where RAM suspension is
desired, a core set of system services can be located there, while
other services can be re-initialized in a second phase.
- This may cause some modification to the task structure to
provide these “re-init” functions.
- Misc:
- We already provide a tickless kernel, so today the system sets a
timer for the next kernel event and issues WFI in the idle task.
- We need to add the concept of power domains to the driver
interface. The goal here is to manage releasing system power domains
when all components that are using a specific power domain, release
that domain.
Some questions:
- General questions/comments are welcome.
- What are the common use cases people have seen in the past?
- Do these designs address those use cases?
- What parts of the low power designs that you’ve done in the past
have been particularly tricky? What were the most important
considerations that you made in those cases?
Best,
Sterling
