Porting guide: Add Sleep API pg page #209
Conversation
| 1. Wake-up sources - RTC, low power ticker or GPIO should be able to wake-up the MCU | ||
| 1. Latency - should wake-up within 5 ms | ||
|
|
||
| The deep sleep latency (5 ms) was chosen as the higher limit of the vendors we support. Most of targets have wake-up latency for deep sleep within few microseconds. This wake-up time does not include reinitializing clocks or other related configuration to return to previous state after the deep sleep. |
There was a problem hiding this comment.
I'm not sure I like that. We should either give a strict limit to go back to previous state or explicitly mark it as undefined.
There was a problem hiding this comment.
I believe our intention was to have those 10ms (we increased it from 5) as a strict limit. Most of MCU can wake up within few microseconds, the part that takes are clocks related config reinit, up to few milliseconds. Shall we update this accordingly ?
| 1. Wake-up sources - RTC, low power ticker or GPIO should be able to wake-up the MCU | ||
| 1. Latency - should wake-up within 5 ms | ||
|
|
||
| The deep sleep latency (5 ms) was chosen as the higher limit of the vendors we support. Most of targets have wake-up latency for deep sleep within few microseconds. This wake-up time does not include reinitializing clocks or other related configuration to return to previous state after the deep sleep. |
There was a problem hiding this comment.
I believe our intention was to have those 10ms (we increased it from 5) as a strict limit. Most of MCU can wake up within few microseconds, the part that takes are clocks related config reinit, up to few milliseconds. Shall we update this accordingly ?
| The core system clock is disabled. The low precision clocks are enabled, RAM is retained. | ||
|
|
||
| 1. Wake-up sources - RTC, low power ticker or GPIO should be able to wake-up the MCU | ||
| 1. Latency - should wake-up within 5 ms |
|
|
||
| ## Implementing the Sleep API | ||
|
|
||
| There are two functions that target needs to implement to support sleep, their prototypes are located in [hal/sleep_api.h](): |
There was a problem hiding this comment.
We'll embed the header here instead of copying and linking, when the changes are committed.
Copy edit for active voice, branding, consistent tense and other minor grammar issues.
|
@bulislaw I've added some minor copy edits. Please review, and make sure I didn't accidentally change the content. |
|
Thanks, looks good :) |
|
@bulislaw Is this ready to merge, or is is still waiting on any engineering review/changes? |
|
I think I've addressed all the points raised by @0xc0170 so we should be ready to merge. |
Update link.
|
|
||
| ### Testing | ||
|
|
||
| The [sleep HAL API test suite]() validates: |
There was a problem hiding this comment.
Query: Where should this link?
There was a problem hiding this comment.
@0xc0170 Do you know where this should link?
There was a problem hiding this comment.
@c1728p9 Do you know where this should link?
There was a problem hiding this comment.
Lets remove the testing for now and add it in a seperate PR once there is a link.
Delete section. Please add its content in a new PR once it's ready for the docs.
Status: Work in progress
It's basically Martin's proposal.
@c1728p9 @0xc0170