Why I rewrote my Rust keyboard firmware in Zig: consistency, mastery, and fun
Having distinct types for P0 and P1 is deliberate and is what is called &quot;type state programming&quot; in the embedded rust book [0]. The advantage is that you can prevent misconfiguration at compile time  (ensuring that a given pin cannot be used in multiple places). In the Zig example, it seems to me (and I have zero knowledge of Zig, so sorry if this is inaccurate) that you can potentially introduce bugs where the same pin is used twice.<p>For a generic led driver, it should not use these types, but instead the trait types from the embedded_hal crate, such as &quot;OutputPin&quot; that is implemented by the different chip-specific HALs. There is an example of a generic led driver that uses these traits at [1].<p>In general I recommend everyone who wants to try out Rust on embedded to read the embedded rust book, because it clarifies a lot of the reasons and advantages of its approach.<p>[0] <a href="https:&#x2F;&#x2F;docs.rust-embedded.org&#x2F;book&#x2F;static-guarantees&#x2F;typestate-programming.html" rel="nofollow">https:&#x2F;&#x2F;docs.rust-embedded.org&#x2F;book&#x2F;static-guarantees&#x2F;typest...</a><p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;drogue-iot&#x2F;drogue-device&#x2F;blob&#x2F;main&#x2F;rt&#x2F;src&#x2F;driver&#x2F;led&#x2F;matrix.rs#L12" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;drogue-iot&#x2F;drogue-device&#x2F;blob&#x2F;main&#x2F;rt&#x2F;src...</a>