"> <@jmanches:matrix.org> Hi all,..." <- > <@ryan-summers:matrix.org> My view on the matter is that typestates within the HAL often makes it far more difficult to use flexibly in an end application. Anything that needs to store the type-stated object then needs to have a container that can store all possible typestates it may need, which gets really hard to do very quickly. HALs like stm32-hal2 were designed specifically because the author disliked design choices like typestating in some existing stm32 HALs. > > In general, my recommendation would be to start simple and just provide implementations for the basic embedded-hal traits at first. Peripherals can be used in so many various ways that it's quite difficult to make them flexible enough to support all use cases, but those in the embedded-hal have been pretty thoroughly thought through over the years Thanks for your reply! My part is not stm32, I'm just familiar with them, so this is where I started looking at. Maybe it's me being new on the matter, but while I see the value of compile-time extra _safety_, I also see that complexity and code readability quickly grows. I can take any C based HAL and quickly understand what's going on, on most rust HALs, it's not trivial.