Daniel Egger

> hmm, I have a potential thought for this. Would it be preferable to just have a single definition of all the pins for each micro variant? It will result...

@david-sawatzke > I personally prefer the approach with an universal Unused pin implementing all the AF traits, but both approaches are (mostly) equivalent. Uhm, that's not what your implementation does....

@HarkonenBade PDF parsing is indeed tricky. Most likely you'll only find all the fancy tipos and minor changes in typography in all the different data sheets.

> I used PhantomData because I wasn't sure if we maybe need to extend it in the future 😲 > and without it it's constructable by user code (afaik). In...

@HarkonenBade Cool stuff, potentially even more accurate than the SVD files or datasheets/documentation.

@david-sawatzke > Doesn't seem very compatible. What do you mean by that? Using the result should be no problem. Redistributing parts of CubeMX is of course a bad idea but...

> Yes, but i personally like the way stm32-rs does it, generating final files as needed and using original files as the source of truth. But we can't do it...

The problem I have with having a `Cargo.lock` is that it automatically turns a crate into high maintainance mode with lots of churn to keep the dependencies bumped and frequent...

While that is true, you might have noticed that the few dependencies we have (serde, quick-protobuf, clap and anyhow) are used even in the library part. It might be possible...

You need to specify the paths of what you'd like to `Get` after the command, e.g. ``` $ rusp encode_msg_body -f file.probuff Get '["Device."]' ```