Open jonathanpallant opened 9 months ago
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:
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.
If you are writing a basic
fn main() -> !
in Rust, there are two pitfalls using the rp-hal as it is:fn set_high()
) return aResult<(), Self::Error>
even though on RP2040 setting a pin high cannot fail. We settype Error = core::convert:Infallible
but this still has to be handled with.unwrap()
orlet _ =
, otherwise you get a warning.We should implement inherent methods on the type called
set_high()
andset_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.