[Core] Use polled waiting on ChibiOS platforms that support it #17607
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
KarlK90
force-pushed
the
feature/busy-wait-us
branch
from
56a4f8f to
a34bb8a
Compare
zvecr
reviewed
Jul 9, 2022
14 tasks
KarlK90
force-pushed
the
feature/busy-wait-us
branch
from
a34bb8a to
4c6f706
Compare
KarlK90
force-pushed
the
feature/busy-wait-us
branch
from
4c6f706 to
868d80c
Compare
zvecr
reviewed
Jul 11, 2022
KarlK90
force-pushed
the
feature/busy-wait-us
branch
from
868d80c to
e215c93
Compare
Due to context switching overhead waiting a very short amount of time on a sleeping thread is often not accurate and in fact not usable for timing critical usage i.e. in a driver. Thus we use polled waiting for ranges in the us range on platforms that support it instead. The fallback is the thread sleeping mechanism. This includes: * ARM platforms with CYCCNT register (ARMv7, ARMv8) this is incremented at CPU clock frequency * GD32VF103 RISC-V port with CSR_MCYCLE register this is incremented at CPU clock frequency * RP2040 ARMv6 port which uses the integrated timer peripheral which is incremented with a fixed 1MHz frequency
...as it is powered by busy waiting now.
KarlK90
force-pushed
the
feature/busy-wait-us
branch
from
e215c93 to
101cff2
Compare
zvecr
approved these changes
Jul 11, 2022
mtei
added a commit
to mtei/qmk_firmware
that referenced
this pull request
Nov 10, 2022
Since qmk's standard wait_us() is now accurate due to the changes in qmk#17607, the workaround is no longer necessary.
nolanseaton
pushed a commit
to nolanseaton/qmk_firmware
that referenced
this pull request
Jan 23, 2023
…7607) * Use polled waiting on platforms that support it Due to context switching overhead waiting a very short amount of time on a sleeping thread is often not accurate and in fact not usable for timing critical usage i.e. in a driver. Thus we use polled waiting for ranges in the us range on platforms that support it instead. The fallback is the thread sleeping mechanism. This includes: * ARM platforms with CYCCNT register (ARMv7, ARMv8) this is incremented at CPU clock frequency * GD32VF103 RISC-V port with CSR_MCYCLE register this is incremented at CPU clock frequency * RP2040 ARMv6 port which uses the integrated timer peripheral which is incremented with a fixed 1MHz frequency * Use wait_us() instead of chSysPolledDelayX ...as it is powered by busy waiting now. * Add chibios waiting methods test bench
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Due to context switching overhead waiting a very short amount of time on a sleeping thread is often not accurate and in fact not usable for timing critical usage i.e. in a driver. Thus we use polled waiting for ranges in the us range on platforms that support it instead. The fallback is the thread sleeping mechanism.
This includes:
Comparison busy waiting vs sleeping
Waiting values are 0, 1, 5, 10, 25, 50, 100, 150, 200, 500 and 1000 microseconds with 10us spacing. Pink is busy waiting, green is sleeping by yielding the thread.
STM32F411
busy waiting
RP2040
GD32VF103
Matrix scanning frequency on DZZY keypad with 5x6 matrix:
Types of Changes
Issues Fixed or Closed by This PR
Checklist