-
Notifications
You must be signed in to change notification settings - Fork 34
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
Configure/Release #20
Comments
Really we are doing clock, so perhaps unclock is the right term to use here anyways |
There's really a few possible States a peripheral may be in beyond clocked, but the goal is the same, a reversal of the peripheral states from Unclocked -> Clocked -> Configured and back |
The 0.5 imxrt-hal release drops the (un)clocked states from imxrt-hal type system, and it separates CCM configurations from driver initialization. I think there's room to re-explore these (un)clocked typestate ideas, and I figured this could come later. Nearly all 0.5 drivers have a let mut lpuart = Lpuart::new(inst, pins);
// Use the driver...
lpuart.reset(); // Puts inst into a known reset state.
let (inst, pins) = lpuart.release(); I figured the "release as-is" semantics might be useful for some advanced use-cases. But, beyond driver initialization, there's no explicit guarantees of how the driver manipulates the peripherals, so user who chooses to skip the I think this should be enough to say we have configure / release APIs. Re-open if I'm misunderstanding / didn't hit the mark. As a separate, somewhat related note: I added APIs to construct / use drivers without imxrt-iomuxc pad objects. This precedent means we don't necessarily need imxrt-iomuxc support to develop new drivers / chips. A driver constructed without pins releases the unit object, |
Configuring a peripheral should be undoable in some way to return it back to its default state.
The C SDK does this using _init/_deinit pairs for peripherals, we can probably do this using type states and similar calls, instead perhaps using configure/release as the call pair.
The text was updated successfully, but these errors were encountered: