-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
drivers: counter: add support for top value configuration on native_posix #63897
drivers: counter: add support for top value configuration on native_posix #63897
Conversation
5d01a08
to
4a9c003
Compare
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.
Thanks @jpwright
I have a few fix requests.
(Note that @nordic-krch is the maintainer for the counter driver itself)
0d87024
to
56683cc
Compare
} | ||
|
||
top = *cfg; | ||
is_top_set = true; |
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.
I'm not sure how native_posix timer works but what if newly set value is TOP_VALUE without callback? Shouldn't it be reset to false
and interrupt disabled?
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.
I initially didn't add that because it's not mentioned in Counter API docs and the set_alarm
function has no such behavior. But, I agree it's a good idea (without it there's no way of setting an alarm after setting a top value without re-init), so I've added it in. Not sure if there is a good place to document that behavior or if it's already mentioned on some other page though.
f0c190b
to
cfc167e
Compare
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.
Thanks again @jpwright
A few more comments from me.
Please note that my knowledge about the counter API is just based on its documentation, so please be critical about my feedback.
pending_alarm = *alarm_cfg; | ||
pending_alarm.ticks = ticks; | ||
is_alarm_pending = true; | ||
|
||
hw_counter_set_target(pending_alarm.ticks); |
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.
This would seem incorrect, as alarm.ticks may be after a wrap (due to either top.ticks or TOP_VALUE) (see the expression in the other comment about finding the next hit)
(Sidetangent) @nordic-krch Note that it seems the documentation in the API of counter_set_guard_period() is self contradictory. |
8d9c3ee
to
1cd4adf
Compare
1cd4adf
to
7a666e0
Compare
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.
thanks @aescolar for the help and additional feature! I grabbed your commit and had two questions on it, happy to address on my fork or pull an update from yours either way.
is_alarm_pending = true; | ||
uint32_t ticks = alarm_cfg->ticks; | ||
|
||
if (ticks > top.ticks) { |
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.
Should this check not happen after handling COUNTER_ALARM_CFG_ABSOLUTE
? If ticks
is relative to current_value
, the alarm will never be reached.
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.
Should this check not happen after handling COUNTER_ALARM_CFG_ABSOLUTE?
I think not. The API description is not clear about this, but from how the test behaves here:
https://github.com/zephyrproject-rtos/zephyr/blob/main/tests/drivers/counter/counter_basic_api/src/test_counter.c#L396-L400
the test expects the driver to reject a relative alarm with a tick offset > top.ticks
pending_alarm[chan_id].ticks = ticks; | ||
is_alarm_pending[chan_id] = true; | ||
|
||
schedule_next_isr(); |
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.
Do we also need to call hw_counter_set_wrap_value
here? Previous top configuration may have set it less than the alarm ticks.
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.
I'm not sure I follow. The wrap is configured at init, or every time ctr_set_top_value() is called successfully.
And the hw wrap remains in effect after that for ever.
Apart from that, we are checking in 189 and 199 that the alarm target does not go beyond the top.tick / wrap_value.
Adding DNM to avoid accidental merge before we get the native simulator changes in |
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.
I'm ok with the PR as it stands
@nordic-krch are you ok with it too?
@jpwright Note I just pushed to your branch updating the PR with an update to the native simulator to match the native_posix hw counter addons. I hope you don't mind, it should just save a bit of time to everybody. (those changes are now in main)
7a666e0
to
2a7db9d
Compare
Looks good, thank you! |
The counter_native_posix driver currently does not support top value configuration, i.e. `ctr_set_top_value` returns `-ENOTSUP`. This commit adds support for top value configuration, and with the counter API now fully implemented, adds `counter` to `supported` peripherals for native_posix target. It also resolves an existing bug in which the counter ISR did not reset upon reaching `TOP_VALUE`. And adds support for multiple channels Signed-off-by: Jason Wright <[email protected]> Signed-off-by: Alberto Escolar Piedras <[email protected]>
2a7db9d
to
39fd121
Compare
The commit with the native simulator changes is not anymore in this branch, and it got in main together with other native simulator updates. The branch now is just rebased on the latest main. |
The counter_native_posix driver currently does not support top value configuration, i.e.
ctr_set_top_value
returns-ENOTSUP
. This commit adds support for top value configuration, and with the counter API now fully implemented, addscounter
tosupported
peripherals for native_posix target.