-
Notifications
You must be signed in to change notification settings - Fork 229
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
Support 3-wire-SPI #2919
base: main
Are you sure you want to change the base?
Support 3-wire-SPI #2919
Conversation
|| (address != Address::None && address.mode() != DataMode::SingleThreeWire) | ||
|| data_mode != DataMode::SingleThreeWire) | ||
{ | ||
return Err(Error::ArgumentsInvalid); |
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.
Should we use Unsupported instead?
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.
I was considering that (and actually I used it first) but the description suggests something else (well I could change the description ofc) - but on the other hand looking at how it's currently used it might be fine - I don't have a preference - happy to change it
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.
I don't think we want to have two different error variants that mean the same thing. Why something isn't supported is, in my opinion, not that important.
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.
really no preference on my side - maybe there are more opinions on that - if not I will remove ArgumentsInvalid
(maybe rename Unsupported
to OperationUnsupported
?)
/// Enables both input and output functionality for the pin, and connects it | ||
/// to the MOSI signal and SIO0 input signal. | ||
pub fn with_mosi<MOSI: PeripheralOutput>(self, mosi: impl Peripheral<P = MOSI> + 'd) -> Self { | ||
pub fn with_sio0<MOSI: PeripheralOutput>(self, mosi: impl Peripheral<P = MOSI> + 'd) -> Self { |
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.
I think we need some more comments in both functions to tell the user when they need MOSI or SIO0 for what they're trying to achieve
Thank you for your contribution!
We appreciate the time and effort you've put into this pull request.
To help us review it efficiently, please ensure you've gone through the following checklist:
Submission Checklist 📝
cargo xtask fmt-packages
command to ensure that all changed code is formatted correctly.CHANGELOG.md
in the proper section.Extra:
Pull Request Details 📖
Description
Implement 3-wire half-duplex SPI.
Closes #2687
Closes #1826
Testing
While there is an adapted hil-test I used a C3 to simulate a slave-device and checked the implementation works for me