-
Notifications
You must be signed in to change notification settings - Fork 3k
Nuvoton: Rework us_ticker and lp_ticker #6048
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
Conversation
The rework includes the following: 1. Remove ticker overflow handling because upper layer (mbed_ticker_api.c) has done with it. This makes us_ticker/lp_ticker implementation more succinct and avoids potential error. 2. Refine timer register access with low-power clock source
Can you share test results for tickers ? |
Target: NUMAKER_PFM_NUC472Toolchain: ARM
Toolchain: GCC_ARM
Toolchain: IAR
|
Target: NUMAKER_PFM_M453Toolchain: ARM
Toolchain: GCC_ARM
Toolchain: IAR
|
Target: NUMAKER_PFM_M487Toolchain: ARM
Toolchain: GCC_ARM
Toolchain: IAR
|
Target: NUMAKER_PFM_NANO130Toolchain: ARM
Toolchain: GCC_ARM
Toolchain: IAR
|
* |-------------------alarm_intvl1_clk-------------------| | ||
* |-alarm_intvl2_clk-| | ||
* | ||
* Unfortunately, `tick_last_read` is not passed along the xx_ticker_set_interrupt() call. To solve it, we |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldnt this work without storing the last read? There should not be any event in the past when set_interrupt is called (processed via different branch in the upper layer) ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@0xc0170 Assume at t1
, upper layer calls us_ticker_read
and has handled all past events; at t2
, upper layer calls us_ticker_set_interrupt
to schedule future event (timestamp
) relative to t1
. There is very low possibility that future event (timestamp
) relative to t1
becomes past event (timestamp
) relative to t2
. But for robustness, I need the last read (t1
) as a reference point to distinguish the order of t1
, t2
, and timestamp
in timeline and then to distinguish timestamp
is a future or past event.
/morph build |
Build : SUCCESSBuild number : 1156 Triggering tests/morph test |
Exporter Build : SUCCESSBuild number : 830 |
Test : SUCCESSBuild number : 961 |
Description
This PR includes rework on us_ticker/lp_ticker. Because upper layer (hal/mbed_ticker_api.c) has addressed ticker frequency/bit size/some wrap-around issues, us_ticker/lp_ticker are reworked to make code more concise and reasonable.
It update the following Nuvoton targets:
Related PRs
#6028