Provide a way to construct a DynPin (for C interop)

[9names]

cr1901 asked on #rust_embedded if there was a way to construct a pin for use with C code.
As in: existing C project. new code written in Rust, assuming it's called through an extern "C" fn

We're almost able to construct a DynPin from scratch now, but the DynRegisters struct is private.

Here's an example of the almost working syntax we currently have:

use embedded_hal::digital::v2::ToggleableOutputPin;
use hal::gpio::*;
use hal::gpio::DynGroup::Bank0;
use hal::gpio::DynOutput::PushPull;

extern "C" fn do_work(pin_id: u8) {
    let pin = DynPinId {
        group: Bank0,
        num: pin_id,
    };
    let mode = DynPinMode::Output(PushPull);
    // This doesn't work because DynPin::new() is private
    let mut dynpin1 = unsafe { DynPin::new(pin, mode) };
    // Panic if the pin wasn't in the right mode
    dynpin1.toggle().unwrap();
}

If we were to provide such a facility (and I think we should) how should we enable this?
Should we add an (unsafe) function that allows you to conjure a DynPin based solely on pin number and mode, along with documentation on how it will explode if you get these wrong?
Would appreciate any thoughts on whether we should do this, and how.

See the below draft PR for a simple impl

[cr1901]

For more context: the idea is that the C code provides a header that defines the pin layout. I will parse this on the Rust side to create structs for appropriately initializing the used hardware on the Rust side (and provide a context pointer back to the C side after init is done).

Since there's no real way to enforce this on the C side, it's up to the C side to not call hw init functions that Rust is using.

[jannic]

Without commenting on the implementation details, as I didn't have time to read the code yet: l think this is a valid use case and should be supported somehow. If it's only possible with some (unsafe) function which crates the DynPin out of thin air, so be it.

Are there alternatives? What about some container storing the real DynPins on the rust side, and handling the pin id as some kind of handle? That way C code could refer to the pin by its id, but could still only access pins which were previously registered in that structure. But that's probably just overcomplicating the issue.