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.

Sign up for GitHub

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

Jump to bottom

Move reading functions from OutputPin trait to StatefulOutputPin #72

Merged
merged 4 commits into from
May 12, 2018
Merged

Move reading functions from OutputPin trait to StatefulOutputPin #72

Changes from 2 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
97fac76
Remove reading functions from OutputPin trait
astro Apr 7, 2018
3f61ef2
Add StatefulOutputPin to read and toggle the state of OutputPin
astro Apr 7, 2018
ac965a3
separate OutputPin.toggle() into ToggleableOutputPin, provide default…
astro Apr 12, 2018
6549d73
move ToggleableOutputPin default impl to opt-in trait + doc
astro Apr 12, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 19 additions & 6 deletions src/digital.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,19 +2,32 @@

/// Single digital output pin
pub trait OutputPin {
/// Is the output pin high?
fn is_high(&self) -> bool;

/// Is the output pin low?
fn is_low(&self) -> bool;

/// Sets the pin low
fn set_low(&mut self);

/// Sets the pin high
fn set_high(&mut self);
}

/// Output pin that can read its output state
Copy link
Contributor

Choose a reason for hiding this comment

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

As I've mentioned before there's a distinction between a logical state and an electrical state. It should be made clear that this is meant to represent the logical (or register) state of a pin and not the electrical state.

#[cfg(feature = "unproven")]
trait StatefulOutputPin: OutputPin {
/// Is the pin set to high?
Copy link
Contributor

Choose a reason for hiding this comment

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

A pin could also be logically floating so either it needs to be made clear that a tri-stated pin may not implement this trait or that the implicit assumption p.is_set_high() == !p.is_set_low() does not necessarily hold and should not be assumed.

fn is_set_high(&self) -> bool;

/// Is the pin set to low?
fn is_set_low(&self) -> bool;

/// Toggle pin output
Copy link
Contributor

Choose a reason for hiding this comment

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

Sorry if I am late to the party. Can you override a method in a trait? On some cores toggle is exposed as a separate register / no read state is required.

I'd propose having the toggle as a separate trait that you can implement on StatefulOutputPin if toggle function is not available.

Copy link
Contributor

Choose a reason for hiding this comment

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

As discussed in #31 (et al) I also think that different capabilities should be modelled in different composable (and mode dependent) traits instead of being munged together into a few traits that do a lot of things at once. Something like is_set_low() on a StatefulOutputPin is not clear what it actually means, i.e. is that supposed to be the electrical or the logical state of the pin? For toggle() it has to be the latter, not the former, in other cases you might want to have the electrical state, though and cannot have this. Also (as you said) there are implementations allowing an efficient toggle without reading the logical state from a pin. There might even be implementations which do not allow you to read back the logical state, although I don't recall any from the top of my head.

I only agreed to moving it out of OutputPin because it belongs there even less and this change turns into into an unproven functionality so if it doesn't provide the hoped for benefit (as I suspect it will not) then we can replace it by something better.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sounds reasonable. I'll remove it in favour of adding ToggleableOutputPin later.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Can you override a method in a trait?

@ryankurte Yes, you can.

fn toggle(&mut self) {
if self.is_set_low() {
self.set_high();
} else {
self.set_low();
}
}
}

/// Single digital input pin
#[cfg(feature = "unproven")]
pub trait InputPin {
Expand Down