digital::InputPin API

[japaric]

This trait became available in release v0.1.1 behind the "unproven" Cargo feature.

[therealprof]

Implemented in nrf51-hal = "0.4.1" and used in microbit = "0.4.1".

[Nemo157]

Would this be the correct trait to include some sort of simple edge detection API (e.g. for buttons hooked up to GPIO)?

[caemor]

Does this api still needs more drivers?

It seems to be quite stable since it's introduction half a year ago.

[caemor]

The only problem I found with this api since using it is that errors can't get propagated any further and need to be converted to a default value.

E.g. the linux sys_fs can receive an file error while trying to read the value (https://github.com/rust-embedded/rust-sysfs-gpio/blob/master/src/lib.rs#L337) and this can't be handled by a simple bool.

[eldruin]

I also stumbled upon the same problem as @caemor with both InputPin and OutputPin traits. In an I2C I/O expander driver I am writing I want to provide access to the individual pins as a bunch of Px structs implementing OutputPin and InputPin. At the moment I have seen no other choice but to panic if there was a problem for either reading or writing.

Should we discuss this in a separate issue?

[ryankurte]

Interesting problems! I think as this spans all operations (not just Digital::InputPin) another issue would be great ^_^

[nils-van-zuijlen]

If this API does not need driver nor implementation, when will it be proven ?

[therealprof]

The problem is: There's no process to mark something as proven. There's a new RFC open #163 in attempt to completely revamp the way we get things added/changed.

Since there're enough implementations already we could simply accept a PR to mark it proven.

[rubberduck203]

I think this issue can be closed.

[therealprof]

Fair enough.