Implement embedded_hal_async::delay::DelayUs trait for SYSTIMER alarms
#812
Conversation
| pub fn set_period(&self, period: fugit::HertzU32) { | ||
| let time_period: MicrosDurationU32 = period.into_duration(); | ||
| let us = time_period.ticks(); | ||
| pub fn set_period(&self, period: MicrosDurationU32) { |
There was a problem hiding this comment.
I guess a duration better matches a time period but just want to make sure we all agree since it's a change in public API
There was a problem hiding this comment.
I would recommend changing the name otherwise, it was misleading before IMO. Don't really care which units we ultimately accept as arguments but for the given function name this made more sense to me.
bjoernQ
left a comment
bjoernQ
left a comment
There was a problem hiding this comment.
LGTM - I think changing set_period to duration makes sense - but maybe a second (or third) opinion would be good
MabezDev
left a comment
MabezDev
left a comment
There was a problem hiding this comment.
LGTM, but imo we should use <verb>_<noun> regarding interrupt clearing/setting etc.
|
(Sorry, forgot the search in VS Code has weird behavior in workspaces, will fix) |
jessebraham
force-pushed
the
feature/async-delay
branch
from
71639b4 to
58432d7
Compare
| } | ||
|
|
||
| #[interrupt] | ||
| fn SYSTIMER_TARGET0() { |
There was a problem hiding this comment.
@jessebraham This change broke embassy. The interrupt handlers may already be defined by
4 participants
This completes one task of #752. Changes should be pretty straight-forward, though I have renamed some things for consistency as well.
The async functionality requires the
Alarmto first be put inPeriodicmode, but I don't think is an issue.There isn't really an example of this, as I don't think it really makes sense, but I did test this locally by modifying the
embassy_hello_worldexample as needed.