wait_us: why need lock deep sleep?

[woodsking2]

Question

I saw the wait_us() in mbed_wait_api_rtos.cpp

const ticker_data_t *const ticker = get_us_ticker_data();
uint32_t start = ticker_read(ticker);
// Use the RTOS to wait for millisecond delays if possible
int ms = us / 1000;
if ((ms > 0) && core_util_are_interrupts_enabled()) {
    sleep_manager_lock_deep_sleep();
    Thread::wait((uint32_t)ms);
    sleep_manager_unlock_deep_sleep();
}
// Use busy waiting for sub-millisecond delays, or for the whole
// interval if interrupts are not enabled
while ((ticker_read(ticker) - start) < (uint32_t)us);

Why need lock deep sleep?
@c1728p9

[c1728p9]

Hi @woodsking2, the us ticker may be stopped when entering deep sleep. If this happens the sub-millisecond delay will be too long, leading to a delay up to twice as long as it should be.

[woodsking2]

Hi @c1728p9
wait() and wait_ms() called wait_us()
so the code like

int main()
{
    while(true)
    {
        wait(60);
        printf("alive\r\n");
    }
    return 0;
}

will never enter deep sleep.
I think it's not good. How about let the wait() wait_ms() wait_us() use the different code？at least, let the wait() to enter deep sleep.
Is it possible let the deep sleep lock at the target port file do? Some mcu dont't need lock deep sleep, some mcu need.

[0xc0170]

Is it possible let the deep sleep lock at the target port file do? Some mcu dont't need lock deep sleep, some mcu need.

An application can unlock it if it wants to. The current implementation makes locking/unlocking in the generic layer to cover most cases. As you pointed, some targets might not need to lock it. We are aware of this and will think of providing solution to the problem.

To get more info - what is your use case - a target - what ticker is available for us ticker that could wake up from deep sleep?

[woodsking2]

@0xc0170
ATSAM4L.
The power save mode are sleep0-3, wait, retention, backup.
Even though at backup mode, the 32k oscillators is still work.
Ast based on 32k oscillators, it can use ast as tick source and wake up cpu at any power save mode.

Application can't unlock the lock. It doesn't knwon who locked the deep sleep, some peripherals need to lock deep sleep.

[amq]

@woodsking2 have you considered using Thread::wait()?

[c1728p9]

An application can unlock it if it wants to.

@0xc0170 the deep sleep lock is inside wait_us(), wait_ms() and wait() so it can't be unlocked by an application.

It is less than idea that the wait functions lock deep sleep. We should look into if this behavior can be improved. Some possible ideas below:

1. Encourage use of Thead::wait() for deep sleep and keep existing wait functions how they are
2. Update some existing functions such as wait() and wait_ms() to use rtos wait and only use microsecond timer in wait_us()
3. Use low power timer for wait functions so deep sleep mode can be entered
4. Use only rtos wait for long delays and use only microsecond ticker for short delays

CC: @kjbracey-arm, @pan-, @bulislaw, @sg-

[kjbracey]

One problem here is that (as I've discussed with others including @bulislaw in the past), wait and wait_ms call wait_us and are hence trying to be microsecond precise, which people generally don't want.

This just came up here, for example: #6565

I've generally tried to avoid wait_ms(), due to the knowledge that it will spin for up to a millisecond - I wasn't aware it also suffered this lock issue for the same microsecond precision reason.

I would personally like wait_ms() to use Thread::wait() in RTOS and LowPowerTicker in non-RTOS. Not sure what to do about wait(float). That would solve this issue.

Another fundamental problem that's also come up recently ( #5943 ) is that we have no generic target mechanism for knowing what sleep stops working (or kills), and hence what needs to be locked. Something along those lines would be relevant for the remaining problem of wait_us locking potentially unnecessarily.

[woodsking2]

@amq Thread::wait() works. Thanks

[woodsking2]

So the question is clear.
Close it.