-
Notifications
You must be signed in to change notification settings - Fork 238
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
Fix RealTimeClock & UsbBus ownership #725
Conversation
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.
Would it make sense to make RealTimeClock
only take a frequency here instead?
A benefit of expecting the RtcClock
is that at least it implicitly checks one's using the right clock source; but it doesn't tie them together either.
Nothing prevent that clock source to be reconfigured which would render anything the RealTimeClock
inconsistent.
So since the benefit provided by using &RtcClock
is pretty thin, is it worth keeping at all?
Thanks for your review, I quite agree with your comment, it would make the function's intentions clearer. But the more I look at the code, the more I wonder if my PR is really relevant... Let me explain, as you said in issue #724, it's interesting that ownership is taken in order to ensure that clocks are not subsequently modified. But there's still the problem of the ClockManager being partially moved. So in the end, even though it's a big change, wouldn't it be better to make the ClockManager fields rp-hal/rp2040-hal/src/clocks/macros.rs Line 22 in cfd6c12
with pub [<$name:snake>]: Option<$name> Because in this PR we've solved the RealTimeClock problem, but the Line 441 in cfd6c12
|
Would it make sense to rather than having fields public, adding a |
c7889cf
to
39d3c8d
Compare
I modified the PR by adding |
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.
LGTM
The RealTimeClock works great, but it takes ownership of the
rtc_clock
field in theClockManager
, which makes it invalid (partial move).Moreover, the
RealTimeClock
struct doesn't allow freeingrtc_clock
, thenew
function doesn't do anything about it, so the instance is destroyed.Following the model of other functions present in the HAL for clock configuration (such as
setup_pll_blocking
orconfigure_clock
from ClockManger), I modified the parameter so that it was a reference.#724
Thanks for this brilliant HAL!