[WIP/RFC] Improve GPIO API

[TheZoq2]

The current GPIO API does not really allow interraction with devices that
require inputs to change type at runtime. For example, ultrasonic sensors where
you send a short pulse to them, then read their reply on the same pin, or dht22
sensors which have a similar interface. This was discussed, for example, in #114

I aim to add two ways of working around this. Right now, I have implemented a
closure based approach, where the pins have a function to temporarily change
the pin mode and use that changed pin in a closure. (Currently called
as_<mode>, bikeshedding welcome)

I think this will work well in sequential applications, but might become
annoying or slow in interrupt heavy applications as it requires a mutable
reference to the control register. However, it should be very fast and does not
require any falible runtime checks for pin modes

The second mode I think would be useful would be fully dynamic. It would keep
track of the state of the pin at runtime, it would implement both OutputPin
and InputPin with a Result<_, DynamicPinError> to notify the programmer of
incorrect modes. I think it might make sense to only implement this for the
Generic pin since you already have to sacrifice some performance to use it.

Standing issues:

• Document the new modes. Specifically, which ones to use when and where

[TheZoq2]

And now I have added dynamic pins as well. Docs are still on my todo list

[TheZoq2]

And now docs have been added 🎉

[TheZoq2]

@therealprof Would you mind having a look at this?

[burrbull]

const fn where it is possible, #inline other

[TheZoq2]

I made all of these const, but I'm not sure how often we should use inline. My general feeling is that compilers are usually better at deciding when to inline things than we are, but maybe that's wrong. Would you like any more consts added?

[therealprof]

#[inline] is just an indication that this might be useful to inline, it just shifts the bias a bit and will be ignored in dev mode altogether.

[therealprof]

Spending 10 minutes with it it looks okay to me. The blank lines are a bit off and I'm not a big fan of the macro_rules! blocks bang in the middle of it.

[TheZoq2]

I'll take care of the blank lines and the const fn/inline stuff.

I also don't really like the macro_rules! in the middle of things. My reasoning for it is that I want to access a bunch of variables defined in the scope where the macros are defined.

[TheZoq2]

I have now added a bunch of #[inline] declarations to most one-liner functions. Would you mind having another look? @therealprof @burrbull

[burrbull]

@TheZoq2 have you seen rust-embedded/embedded-hal#29 ?

[TheZoq2]

I had not, I'll have a look through it

[therealprof]

Looks good to me. I don't care to deeply about this functionality so I don't really want to test the usability and functionality aspects myself but I trust you've done due dilligence. ;)

[TheZoq2]

:D I don't think I did any more testing apart from writing and running the examples, but I'm hoping that will be enough