Skip to content
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

Closed
teburd opened this issue Mar 3, 2020 · 3 comments
Closed

Configure/Release #20

teburd opened this issue Mar 3, 2020 · 3 comments
Labels
enhancement New feature or request help wanted Extra attention is needed imxrt-hal HAL related issue

Comments

@teburd
Copy link
Member

teburd commented Mar 3, 2020

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.

@teburd teburd added help wanted Extra attention is needed imxrt-hal HAL related issue enhancement New feature or request labels Mar 3, 2020
@teburd
Copy link
Member Author

teburd commented May 18, 2020

Really we are doing clock, so perhaps unclock is the right term to use here anyways

@teburd
Copy link
Member Author

teburd commented Oct 7, 2020

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

@mciantyre
Copy link
Member

mciantyre commented Jan 5, 2023

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 release() method to take back ownership of the imxrt-ral instance and other components. Almost all of these methods are documented as "this simply releases the registers / resources as-is." If users want to take back ownership of registers in known, good states, they can do that by first calling reset(), a separate method implemented on drivers.

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 reset() call may be taking a risk. If this approach doesn't work out, we could combine reset and release into one method.

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, ().

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed imxrt-hal HAL related issue
Projects
None yet
Development

No branches or pull requests

2 participants