"Hi all, I need to implement a..." <- > <@jmanches:matrix.org> Hi all, I need to implement a HAL for a new SoC, and to me choosing the "right" approach is proving to be quite challenging. Starting with the PAC, I've found at least 3 different ways: svd2rust, chiptool and RAL (like stm32-ral or imxrt-rs). Is there any recommendation for new projects? Is there any article comparing the benefits of one or another? > > When it comes to HALs, I've seen even more divergences when it comes to design patterns. For example, there are many HALs using the typestate pattern, some simply don't (e.g. stm32-hal2) and some others use traits to represent type classes (atsamd). While any type safety is very welcome, it's also true that code explodes in complexity, and it is no longer trivial to read if we compare e.g. with any C based HAL. HALs like stm32-hal2 are in comparison far easier to understand. Based on your experience, is it worth adding such complexity? > > I understand there will probably be many views on the topic, but I'd like to hear them all as I haven't found a good read that exposes/compares them. Also, if there's any kind of implementation manual it would help! Thanks! 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