Implement InputPin regardless of mode

[jonas-schievink]

This should resolve #339

I think this is fine, since you can always read any pin regardless of configuration (even for disconnected pins, their value will just be floating).

[jonas-schievink]

Ah, it seems like this doesn't work without also setting cnf.input().connected() for all output modes. Apparently we already do this for push-pull outputs for some reason:

nrf-hal/nrf-hal-common/src/gpio.rs

Line 205 in 19df163

w.input().connect(); // AJM - hack for SPI

Not sure why though? And what are the consequences of doing this anyways? Higher power usage?

[Dirbaio]

Not sure why though? And what are the consequences of doing this anyways? Higher power usage?

gpios have an "input buffer" you can connect/disconnect. If you don't connect it, you read garbage. You can enable output and input at the same time. For PushPull outputs you just read what you write. For OpenDrain you can drive the line low or you can listen whether the other device drives it down.

Enabling input when not needed wastes power. The Product Specification doesn't say how much though :( . Probably very little.

I think always implementing InputPin is a bit of a footgun though. Too easy to configure a PushPull output and accidentally pass it to a driver that requires InputPin. IMO it should be something the user explicitly opts in. Embassy has a FlexPin for this, which allows using input+output at the same time.

[oddstr13]

Is IoPin rust-embedded/embedded-hal#269 relevant?

https://github.com/rust-embedded/embedded-hal/releases/tag/v1.0.0-alpha.5

[eflukx]

Is IoPin rust-embedded/embedded-hal#269 relevant?

Seems reasonable if that's the path the embedded-wg goes, nrf-hal follows along?

Currently I'm in need of this kind of pin handling (in my case tri-stating GPIO pins, not using them as inputs per se), for handling charlieplexed LEDs and a device with a bit too much leakage on its IO-pins (i.e. floating the pins lowers idle/quiescent current draw) .

[Finomnis]

Here is my attempt to implement this: #401

[Finomnis]

@jonas-schievink Can probably be closed; was superseded by #401