Add digital::IoPin to resolve issue 29 #269

MorganR · 2021-04-25T15:49:34Z

Closes #29.

This implementation is inspired by chrismoos's comment in #29.

I've demonstrated using this trait for a no-std DHT11 driver, and verified this on a Raspberry Pi 3B+ using an implementation in linux-embedded-hal (PR to follow).

I'll also be sending a PR to implement this in at least one additional HAL implementation library (recommendations welcome).

One question I have is how copyright/authorship is tracked in this repo? I believe the copyright owner for my code would technically be Google LLC. When patching repos, I'm meant to add that to the appropriate copyright/authors list.

rust-highfive · 2021-04-25T15:49:37Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @therealprof (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

MorganR · 2021-04-25T15:59:35Z

PR on linux-embedded-hal: rust-embedded/linux-embedded-hal#60

eldruin

Thanks for this proposal!
Could you add some examples on how to use this to the docs?
I do not know about copyright / authorship attribution matters. The current crate author list is missing many people.

CHANGELOG.md

src/digital.rs

eldruin · 2021-04-26T07:30:53Z

src/digital.rs

+    /// 
+    /// If the pin is already in the requested state, this method should
+    /// succeed.
+    fn try_switch_to_output_pin(self, state: PinState) -> Result<TOutput, Self::Error>;


Would not setting an initial state also make sense?

If the user didn't specify the state, then the result would be a pin in output mode that's either high or low, but the user doesn't know which it is. I think it's better to make the user specify which state they want rather than to leave it ambiguous.

That being, said I'm no expert in the embedded space. Do you see a valid use case?

I was just wondering. From a software perspective it makes sense to always change to a defined state. However, from a hardware perspective, it may not always make sense to set a pin, since it has electrical implications.
Does anybody else here have an use case for changing the pin type to output but leaving it unset?

IIUC, an example use-case might be an output pin in open drain mode (I could be wrong; like I said, I'm not an embedded expert). However, the current digital traits don't seem to provide any support around these states either. Maybe it makes sense to look at that separately, eg. as an addition to PinState? Definitely interested in what other folks think here, as @eldruin said.

MorganR · 2021-04-26T19:56:22Z

I've added an example to the IoPin docs.

I am not a lawyer, but I expect that if there isn't a formal process for tracking copyright at the moment, then the PR/commit history will be fine.

eldruin

Looks good to me, although I do not have the whole discussion about this in #29 in mind at the moment.

src/digital.rs

therealprof · 2021-04-27T08:43:35Z

@MorganR This is looking great.

I'm wondering if we can make the type stuff a little bit easier on the eyes and the mind but other than that I like it.

MorganR · 2021-04-27T17:37:18Z

Thanks @therealprof! I agree the type system becomes a bit verbose when using the abstract trait. However, it's actually fairly clean when implementing the trait, and in user code that gives a concrete implementation to something using the abstraction.

To simplify things a little more, I've removed the TIoPin parameter from the example function. This is superfluous because the function can instead accept a pin that's already in either TInputPin or TOutputPin format.

therealprof · 2021-04-27T17:48:25Z

If you could squash the commits and maybe add a "Closes #29" to your initial post, that would be great.

MorganR · 2021-04-27T17:56:04Z

If you could squash the commits and maybe add a "Closes #29" to your initial post, that would be great.

Done

therealprof

Thanks a lot for your efforts!

bors r+

269: Add digital::IoPin to resolve issue 29 r=therealprof a=MorganR Closes #29. This implementation is inspired by [chrismoos's comment](#29 (comment)) in #29. I've demonstrated using this trait for a [no-std DHT11 driver](https://github.com/MorganR/rust-simple-sensors/blob/main/src/dht11.rs), and verified this on a Raspberry Pi 3B+ using an implementation in linux-embedded-hal (PR to follow). I'll also be sending a PR to implement this in at least one additional HAL implementation library (recommendations welcome). One question I have is how copyright/authorship is tracked in this repo? I believe the copyright owner for my code would technically be Google LLC. When patching repos, I'm meant to add that to the appropriate copyright/authors list. Co-authored-by: Morgan Roff <mroff@google.com>

bors · 2021-04-27T17:59:19Z

Build failed:

fmt

MorganR · 2021-04-27T18:03:19Z

Sorry, fixed that remaining fmt error. Should be good now.

therealprof · 2021-04-27T18:03:45Z

@MorganR I guess rustfmt doesn't like your formatting. 😅 It's a pity the new GH protection mechanisms seem to silently prevent actions from running...

therealprof

Let's try this again.

bors r+

bors · 2021-04-27T18:10:43Z

Build succeeded:

burrbull · 2021-04-29T08:59:22Z

Which combinations of output and input modes this should be implemented?
PushPull, OpenDrain
PullUp, PullDown, Floating
Alternate

60: Implementation of embedded_hal::digital::IoPin r=eldruin a=MorganR This is just a draft, and is pending the PR merge of an [IoPin implementation](rust-embedded/embedded-hal#269) into embedded_hal. I've verified it with a [no-std DHT11 driver based on the IoPin PR](https://github.com/MorganR/rust-simple-sensors/blob/main/src/dht11.rs). Co-authored-by: Morgan Roff <mroff@google.com>

MorganR requested review from ilya-epifanov and a team as code owners April 25, 2021 15:49

rust-highfive assigned therealprof Apr 25, 2021

rust-highfive added S-waiting-on-review Review is incomplete T-hal labels Apr 25, 2021

MorganR mentioned this pull request Apr 25, 2021

Implementation of embedded_hal::digital::IoPin rust-embedded/linux-embedded-hal#60

Merged

MorganR mentioned this pull request Apr 25, 2021

[RFC] digital::IoPin, pins that can switch between input and output modes at runtime #29

Closed

eldruin reviewed Apr 26, 2021

View reviewed changes

MorganR force-pushed the master branch from 90bfb2b to 9705369 Compare April 26, 2021 20:14

eldruin reviewed Apr 27, 2021

View reviewed changes

src/digital.rs Outdated Show resolved Hide resolved

src/digital.rs Outdated Show resolved Hide resolved

MorganR force-pushed the master branch from acdce90 to 4306114 Compare April 27, 2021 17:55

therealprof previously approved these changes Apr 27, 2021

View reviewed changes

Add digital::IoPin trait (closes rust-embedded#29)

b37282e

MorganR dismissed therealprof’s stale review via b37282e April 27, 2021 18:02

MorganR force-pushed the master branch from 4306114 to b37282e Compare April 27, 2021 18:02

therealprof approved these changes Apr 27, 2021

View reviewed changes

bors bot merged commit 1d22385 into rust-embedded:master Apr 27, 2021

eldruin mentioned this pull request Apr 27, 2021

Input/Output pin trait proposal #151

Closed

ryankurte mentioned this pull request Apr 28, 2021

TriStatePin proposal #157

Open

oddstr13 mentioned this pull request Nov 23, 2021

Implement InputPin regardless of mode nrf-rs/nrf-hal#340

Closed

eldruin mentioned this pull request Aug 9, 2022

Tracking issue for input/output pin traits #397

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add digital::IoPin to resolve issue 29 #269

Add digital::IoPin to resolve issue 29 #269

MorganR commented Apr 25, 2021 •

edited

rust-highfive commented Apr 25, 2021

MorganR commented Apr 25, 2021

eldruin left a comment •

edited

eldruin Apr 26, 2021

MorganR Apr 26, 2021

eldruin Apr 27, 2021

MorganR Apr 27, 2021

MorganR commented Apr 26, 2021

eldruin left a comment

therealprof commented Apr 27, 2021

MorganR commented Apr 27, 2021

therealprof commented Apr 27, 2021

MorganR commented Apr 27, 2021

therealprof left a comment

bors bot commented Apr 27, 2021

MorganR commented Apr 27, 2021

therealprof commented Apr 27, 2021

therealprof left a comment

bors bot commented Apr 27, 2021

burrbull commented Apr 29, 2021

Add digital::IoPin to resolve issue 29 #269

Add digital::IoPin to resolve issue 29 #269

Conversation

MorganR commented Apr 25, 2021 • edited

rust-highfive commented Apr 25, 2021

MorganR commented Apr 25, 2021

eldruin left a comment • edited

Choose a reason for hiding this comment

eldruin Apr 26, 2021

Choose a reason for hiding this comment

MorganR Apr 26, 2021

Choose a reason for hiding this comment

eldruin Apr 27, 2021

Choose a reason for hiding this comment

MorganR Apr 27, 2021

Choose a reason for hiding this comment

MorganR commented Apr 26, 2021

eldruin left a comment

Choose a reason for hiding this comment

therealprof commented Apr 27, 2021

MorganR commented Apr 27, 2021

therealprof commented Apr 27, 2021

MorganR commented Apr 27, 2021

therealprof left a comment

Choose a reason for hiding this comment

bors bot commented Apr 27, 2021

MorganR commented Apr 27, 2021

therealprof commented Apr 27, 2021

therealprof left a comment

Choose a reason for hiding this comment

bors bot commented Apr 27, 2021

burrbull commented Apr 29, 2021

MorganR commented Apr 25, 2021 •

edited

eldruin left a comment •

edited