Skip to content

Add tickless feature #4943

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 8 commits into from
Closed

Conversation

0xc0170
Copy link
Contributor

@0xc0170 0xc0170 commented Aug 21, 2017

Add tickless using low power ticker (if available, otherwise fallback to the current implementation using sleep). I created a simple test (to exercise idle loop for 5 seconds, with locked and unlocked deep sleep).

Not complete yet (this changes make some test to fail due to deepsleep - needs investigation - in need for fixes. It's based on the sleep manager work that is sent here #4912 .

What is important here are rtos commits (latest commits).

Feel free to contribute (push to my branch). This is sent against master branch.

@c1728p9 @bulislaw

Sleep manager provides API to lock/unlock deepsleep. This API allows a user to
control deep sleep.

This API should be done via atomic operations (to be IRQ/thread safe).

Add wake-up times for sleep and deep sleep. Sleep should wake up within 10 us,
deep sleep within 10 milliseconds (sufficient time to restore clock if required).
If a target do not support sleep (no DEVICE_SLEEP defined),
we provide empty deep sleep locking.
Any driver with attach or async API should be considered for deep sleep.

Add locking to those that require in most cases
high-frequency clocks:

- CAN
- I2C
- SPI
- Serial
- Ticker/Timeout/Timer
As attach provides API to change a callback, lock/unlock should
only happen if we are doing the first/last callback (start-stop).
attach/detach can be multiple invoked. Therefore lock/unlock deep sleep
only for the very first time it is invoked (when callbacks
are actually changed).
In most cases, Systick is the main ticker for RTOS,
deep sleep mode would break an application.
Default idle loop should block deepsleep (being
backward compatible with previous implementation).

Tickless support will come as the next step using
low power ticker.
@bulislaw
Copy link
Member

Shouldn't that go into a feature_branch? We can't change the HAL APIs before it's updated for partners and they'll need some time to do this and this PR can't go in before the HAL changes.

Add tickless support to the rtos idle loop. Using low
power ticker and RTOS suspend/resume functionality. We set
the next event according to the kernel, and wake-up within this period.

Note: us ticker is still running (if it was inited - any us ticker API invoked) as there is currently
no API to disable it.

Increase idle stack to 512, as it requires now more space.

If lowpower ticker is not available, we fallback to
the previous only sleep function (locked deep sleep mode).
Basic functionality, sleep and deepsleep test, using
sleep API and idle loop. To measure time, low power
ticker is used.
@0xc0170 0xc0170 force-pushed the dev_tickless_rtos branch from 4be1088 to b8e1067 Compare August 22, 2017 13:54
@0xc0170
Copy link
Contributor Author

0xc0170 commented Aug 22, 2017

Shouldn't that go into a feature_branch? We can't change the HAL APIs before it's updated for partners and they'll need some time to do this and this PR can't go in before the HAL changes.

That would be ideal, I can redirect anytime.

@bulislaw bulislaw requested a review from pan- August 22, 2017 15:37
@bulislaw
Copy link
Member

If it doesn't require HAL changes then it can target master.

@0xc0170
Copy link
Contributor Author

0xc0170 commented Aug 22, 2017

Based on the comments above and some internal discussion, I am going to split this. Sleep API is a separate patch, and going to send another patch for adding tickless support.

I am closing this, new PR will be created based on this work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants