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

Add support for external clocks on gpin GPIO pins #884

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

PietPtr
Copy link

@PietPtr PietPtr commented Dec 27, 2024

Fixes #879 by adding a GpIn0 and GpIn1 struct, which implement ClockSource, such that a user can call configure_clocks for these clock inputs and use the safe clock switching logic already built in.

I tried keeping the gpin.rs style kind of similar to other pin related interfaces (e.g. I2C), let me know if this aligns to your code style :)

I've renamed the type from GPin to GpIn, I believe it's a "General Purpose (clock) INput", hence the gpin name in the datasheet (similarly, there's also a gpout).

I've also provided an example which I ran on an RPi Pico, on an oscilloscope I could see that the pulses the example code drives are in sync with the provided clock 🎉

@thejpster
Copy link
Member

Looks good to me. But perhaps GpInX::new(pin) should also take the input frequency as an argument, so we don't have to default it to 0 Hz?

@PietPtr
Copy link
Author

PietPtr commented Dec 27, 2024

Good point, 0 Hz is an annoying default to have anyway as it causes issues in calculating clock dividers. I've updated it.

@thejpster
Copy link
Member

Thank you for the PR! Looks good to me. I guess we should do another PR adding support for RP2350 as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Calling configure_clock runs a todo!() if gpin0 or gpin1 is supplied as clock source
2 participants