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

read and write in send #2

Merged
merged 2 commits into from
May 14, 2019
Merged

read and write in send #2

merged 2 commits into from
May 14, 2019

Conversation

sajattack
Copy link
Owner

@sajattack sajattack commented May 12, 2019

Fixes #1
@austinglaser Please review. Is this a correct implementation now?

@sajattack sajattack changed the title read and write in send (fixes #1) read and write in send May 12, 2019
Copy link

@austinglaser austinglaser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, I haven't tested these changes on hardware

src/spi.rs Outdated
@@ -22,6 +22,7 @@ where
mosi: Mosi,
sck: Sck,
timer: Timer,
read_val: u8,

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems to me that read_val should be Option<u8>, so that read() can return an error if it's called when no data is available. Then read() can be

fn read(&mut self) -> nb::Result<u8, Error> {
    if let Some(byte) = self.read_val.take() {
        Ok(byte)
    } else {
        Err(Something)
    }
}

But I also don't think this is strictly required by the embedded-hal trait, it's just a way to help catch invalid uses of your interface.

src/spi.rs Outdated
self.read_val = (self.read_val << 1) | 1
} else {
self.read_val = self.read_val << 1
}
Copy link

@austinglaser austinglaser May 13, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure this code is correct in the case where self.mode.phase == CaptureOnSecondTransition. In that case in the original implementation, you have a clock transition before reading the first bit. Here, you immediately read the pin on entry, which may be in an indeterminate state depending on the peripheral to which you're interfacing.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I may be wrong about something here -- I'll try to prove/disprove this problem, and get back to you

Copy link

@austinglaser austinglaser May 13, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope, my comment is correct. Sorry for the confusion

@sajattack
Copy link
Owner Author

@austinglaser Try now.

@austinglaser
Copy link

LGTM, at least as far as I can tell without actually testing on hardware

@sajattack sajattack merged commit cb2f913 into master May 14, 2019
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.

SPI doesn't match the paradigm defined in embedded HAL
2 participants