ryan

interesting idea! the trouble with a specialised impl is that they can only be used in certain situations, so by standardising we would still be introducing a canonical source of...

> Is the issue that core::time::Duration is too large to pass around? iirc this is because `core::time::Duration` is 64-bit and we didn't want to impose that on (what are predominantly)...

>No, drivers would provide their own "bus interface trait" like the DisplayDevice I proposed above, and provide implementations for it that take either: > > Bus - exclusive, no bus...

i'm not super convinced making CS pins infallible / wrapping in panics is the right way to handle this... i can't think of any situations with fallible IOs in which...

hey interesting idea, seems worthwhile to me! it might be worth looking at how folks are using [smolctp](https://github.com/smoltcp-rs/smoltcp/) and [embedded-nal](https://github.com/rust-embedded-community/embedded-nal) with RMII-based devices (for embedded use i would suggest this...

neat! i really appreciate that they seem to keep a consistent protocol (and publish the spec). > This is a promising start, but because a bunch of constants would have...

good effort! i need to fix the CI but otherwise happy to merge the new functionality / play with things later if we come up with better abstractions. > But...

> Strongly recommend HALs implement core::error::Error. If/when/once most HALs do, drivers can just demand that explicitly. this seems pretty reasonable to me. no weird trait tricks, it's a nice way...

welp, turns out this only works below a certain clock frequency... there's a proposal for an upstream fix in https://github.com/stm32-rs/synopsys-usb-otg/issues/37 that seems to work for clock rates above 400MHz.