GPIO pins should have inherent infallible methods

[jonathanpallant]

If you are writing a basic fn main() -> ! in Rust, there are two pitfalls using the rp-hal as it is:

1. You don't get any useful methods on your GPIO pins unless you import the right embedded-hal traits
2. The embedded-hal traits insist the methods (like fn set_high()) return a Result<(), Self::Error> even though on RP2040 setting a pin high cannot fail. We set type Error = core::convert:Infallible but this still has to be handled with .unwrap() or let _ = , otherwise you get a warning.

We should implement inherent methods on the type called set_high() and set_low() which return nothing. We can defer to these methods in the implementation of the embedded-hal methods, and then only people using the traits (i.e. driver authors) have to worry about the return type.

[jannic]

This is partly a design decision: Do we want to make it as easy as possible to write some one-off firmware using rp2040-hal? Then we should obviously provide those methods.

Or do we intentionally point to the more difficult to use embedded-hal methods? While it might seem strange at first, it has several advantages:

• It makes code more portable. If you later decide to change the MCU you use, you can keep more of your application logic
• It keeps the ecosystem more consistent. Ideally, if you find some HOWTO describing how to perform some task using MCU A, you can apply the same knowledge when using MCU B, if both use the embedded-hal traits
• It reduces cognitive load if you switch between different HALs, eg. if your design contains multiple MCUs or you work on several projects at the same time

Of course, there are use cases where you really only need to toggle a few GPIO pins and don't care about portability. So it's not an easy decision, IMHO.