Skip to content
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

Relax us ticker frequency requirement + test update #11157

Merged
merged 2 commits into from Aug 13, 2019

Conversation

@mprse
Copy link
Member

commented Aug 2, 2019

Description

This change is required by the Samsung S111(S5JS100). On this board timer clock used for us ticker operates at 26MHz.
According to current requirements, 8 MHz is the top limit for us ticker timer.

This change relaxes top limit to 100 MHz, but only for 32-bit timers.

Ticker common layer schedules one interrupt per timer rollover to trace elapsed time. We need to ensure that this operation is not performed too frequently. I.e. in case of 16-bit timer at 32 MHz, the timer rollover will happen after ~2 ms. This may cause that there will be no time for other tasks. That is why we increase the top limit, but only for 32-bit timers.

Pull request type

[X] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

@bulislaw @jamesbeyond @fkjagodzinski @maciejbocianski

mprse added 2 commits Aug 2, 2019
Relax us ticker frequency requirement.
This change is required by the Samsung S111(S5JS100). On this board timer clock used for us ticker operates at 26MHz.
According to current requirements, 8 MHz is the top limit for us ticker timer.

This change relaxes top limit to 100 MHz, but only for 32-bit timers.

Ticker common layer schedules one interrupt per timer rollover to trace elapsed time. We need to ensure that this operation is not performed too frequently. I.e. in case of 16-bit timer at 32 MHz, the timer rollover will happen after ~2 ms. This may cause that there will be no time for other tasks. That is why we increase the top limit, but only for 32-bit timers.
@mprse

This comment has been minimized.

Copy link
Member Author

commented Aug 5, 2019

Updated documentation: PR ARMmbed/mbed-os-5-docs#1123.

@0xc0170
0xc0170 approved these changes Aug 9, 2019

@0xc0170 0xc0170 added the needs: CI label Aug 9, 2019

@0xc0170

This comment has been minimized.

Copy link
Member

commented Aug 9, 2019

CI started

@mbed-ci

This comment has been minimized.

Copy link

commented Aug 9, 2019

Test run: FAILED

Summary: 1 of 4 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

  • jenkins-ci/mbed-os-ci_unittests
@mprse

This comment has been minimized.

Copy link
Member Author

commented Aug 12, 2019

Test run: FAILED

@0xc0170 Looks not related.

@kjbracey-arm
Copy link
Contributor

left a comment

Recent optimisations in #10609 were relying on the current limits.

But as long as this limit is only lifted for wide timers, I believe it doesn't break that. Maybe you could double-check - see _us_is_small_enough macro in mbed_wait_api.h.

(I can imagine this being relaxed a bit more in future - maybe it isn't specific to 32-bit, maybe it could be a combined check of width+speed to ensure wrap time is greater than 8ms.)

@0xc0170

This comment has been minimized.

Copy link
Member

commented Aug 12, 2019

Will restart tests once we have 5.13.3 RC tested

@0xc0170

This comment has been minimized.

Copy link
Member

commented Aug 12, 2019

CI restarted

@mbed-ci

This comment has been minimized.

Copy link

commented Aug 12, 2019

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 2
Build artifacts

@mprse

This comment has been minimized.

Copy link
Member Author

commented Aug 13, 2019

Recent optimisations in #10609 were relying on the current limits.

But as long as this limit is only lifted for wide timers, I believe it doesn't break that. Maybe you could double-check - see _us_is_small_enough macro in mbed_wait_api.h.

(I can imagine this being relaxed a bit more in future - maybe it isn't specific to 32-bit, maybe it could be a combined check of width+speed to ensure wrap time is greater than 8ms.)

@kjbracey-arm Thanks for the review.

Previously the worst case was for 16 bit counter @ 8 MHz. In this case, we have a rollover after ~ 8ms.
Now we relaxed max freq only for 32-bit counters, so the worst case is for 32 bit counter @ 100 MHz which gives rollover after ~42 949 ms. Should be okay.

@0xc0170 0xc0170 merged commit 69bfc34 into ARMmbed:master Aug 13, 2019

27 checks passed

continuous-integration/jenkins/pr-head This commit looks good
Details
continuous-integration/jenkins/pr-merge Manually fixed status
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
jenkins-ci/build-ARM Success
Details
jenkins-ci/build-GCC_ARM Success
Details
jenkins-ci/build-IAR Success
Details
jenkins-ci/cloud-client-test Success
Details
jenkins-ci/dynamic-memory-usage RTOS ROM(+0 bytes) RAM(+0 bytes)
Details
jenkins-ci/exporter Success
Details
jenkins-ci/greentea-test Success
Details
jenkins-ci/mbed2-build-ARM Success
Details
jenkins-ci/mbed2-build-GCC_ARM Success
Details
jenkins-ci/mbed2-build-IAR Success
Details
jenkins-ci/unittests Success
Details
travis-ci/astyle Success!
Details
travis-ci/docs Success!
Details
travis-ci/doxy-spellcheck Success!
Details
travis-ci/events Success! Runtime is 8643 cycles.
Details
travis-ci/gitattributestest Success!
Details
travis-ci/include_check Success!
Details
travis-ci/licence_check Success!
Details
travis-ci/littlefs Success! Code size is 8448B.
Details
travis-ci/psa-autogen Success!
Details
travis-ci/tools-py2.7 Success!
Details
travis-ci/tools-py3.5 Success!
Details
travis-ci/tools-py3.6 Success!
Details
travis-ci/tools-py3.7 Success!
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.