Sympatron GmbH

I think the API is currently not stable enough. I suppose we want to update all modules to use gpio v2 eventually and I would personally not go 1.0 until...

> My only concern is that any examples involving pins would have to use some arbitrary pin mapping. Thus, instead of being use anywhere, they would in fact be use...

I think option 3 is the best at the moment. Should be fairly simple and that way you either access USB methods from different context safely or get maximum performance...

I would wait until RTIC's `Monotonic` rework is done. See https://github.com/rtic-rs/rtic-monotonic/pull/3.

Maybe we could review the `unproven` feature. Last time I looked a lot of basic stuff was "unproven" (I think because the traits were unproven in `embedded-hal`).

> Here's another proposed change. I would like to change `target_device` to `pac`. At the very least, maybe we could support both. Thoughts? Seems like this is already part of...

Thinking about the `unproven` thing more, I came to the conclusion that we probably should not mark whole modules as "unproven" just because they implement some unproven trait. Everything else...

I'm not that familiar with SAMD20. But I think it's mostly SAMD21 without USB. So it's probably useful to have a common feature for them (`samd2x`?) to simplify the `#[cfg]`s.

> Unsoundness if default state does not match the one expected after reset (BL jumping to APP case; both setup clocks) - proper solution? Is it possible to reset all...

Do you intent to put this (or something similar) in the HAL?