You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In stm32l0xx-hal, we implement traits for pins in any mode and then configure the proper mode for those pins in a setup trait method. For example, for serial:
In contrast, in the stm32f0xx-hal, alternative functions are pin modes, just like Input or Output:
/// Alternate modepubstructAlternate<MODE>{_mode:PhantomData<MODE>,}/// PinpubstructPA0<MODE>{_mode:PhantomData<MODE>,}impl<MODE>PA0<MODE>{/// Configures the pin to operate in AF0 modepubfninto_alternate_af0(self,_cs:&CriticalSection) -> PA0<Alternate<AF0>>{_set_alternate_mode($i,0);PA0{_mode:PhantomData}}
...
The trait impls are purely marker traits and expect the pins to be in the proper state.
I think this is the much nicer design for three reasons:
The user is aware that pins need to be put into the correct mode, it's not something that happens implicitly. Furthermore, if the pin already is in the right mode, then nothing needs to be done.
In stm32l0xx-hal, we implement traits for pins in any mode and then configure the proper mode for those pins in a
setup
trait method. For example, for serial:In contrast, in the stm32f0xx-hal, alternative functions are pin modes, just like Input or Output:
The trait impls are purely marker traits and expect the pins to be in the proper state.
I think this is the much nicer design for three reasons:
setup
method is not implemented for every pin, the resulting binary might be smaller (unless this is optimized out by the compiler).Thoughts?
The text was updated successfully, but these errors were encountered: