Ensure us_ticker is initialized before it is used #5194
Conversation
| // 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(); |
There was a problem hiding this comment.
The current implementation of wait doesn't allow deep sleep, since the us ticker must be running. Two possible solutions to this are:
- Make distinction between busy wait and suspended wait (encourage use of
Thread::waitagain) - Use
Thread::waitfor ms part and busy wait for remainder (start time would need to be read afterThread::wait)
Anyone have a preference or other ideas on how to handle this?
There was a problem hiding this comment.
The current implementation of wait doesn't allow deep sleep, since the us ticker must be running.
tickers are always running (only initialize function present), are we getting API to stop/resume them?
Make distinction between busy wait and suspended wait (encourage use of Thread::wait again)
From a user perspective, what API would be preferable ?
If I consider the second one (ms part and busy), what about these:
wait_us() - Busy wait with higher accurancy (microseconds) always blocking, no Thread:wait involved. We are specifically requesting high precision and be blocking. Smaller periods (limits to 32bit microseconds).
wait_ms() + wait() (this would not allow us accuracy?) - lower accuracy (task switch allowed), plus tickless possible. Bigger periods.
There was a problem hiding this comment.
Largely agree with this proposal - see #5216.
Only caveat is that it is something of an API change - wait_ms will wait up to that number of milliseconds, being potentially low by up to a millisecond, rather than waiting at least that number of milliseconds.
cf confusion when RTX changed a similar function: http://www.keil.com/support/docs/3766.htm and linked threads.
Although in this case the change would be towards conventional/expected behaviour, rather than away from.
|
BLE and LWIP still use us_ticker_read directly. These are not used for delaying though, so for proper operation they would need to hold the sleep lock while powered up. This may be ok for lwip since the device likely won't be able to go into deep sleep when a network connection is in use. This may present a bigger power for BLE since they are typically very low power. @pan- what are your thoughts on this? Two possible solutions:
Let me know what you think of these solutions, or if you can think of another solution. |
|
|
/morph test |
|
This PR should fix the initialization problems so should be merged if everyone is happy with it and it passes testing. The issue regarding sleep should probably be fixed in a separate PR. |
Result: FAILUREYour command has finished executing! Here's what you wrote!
|
Initialize the ticker on the first call to ticker_read* if the ticker has not been initialized already.
Update platform code to use the ticker common layer rather than using HAL us ticker directly. This both ensures that the underlying ticker is properly initialized and that the value read is in microseconds with full 32-bit range.
👍 I rebased it to resolve conflict with clock() function. Restarting CI now /morph test |
Result: SUCCESSYour command has finished executing! Here's what you wrote!
OutputAll builds and test passed! |
Update platform code to use the ticker common layer rather than using HAL us ticker directly. This both ensures that the underlying ticker is properly initialized and that the value read is in microseconds with full 32-bit range.