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
I happened on this while looking at https://github.com/stm32-rs/stm32f4xx-hal/blob/master/src/gpio.rs#L341-L345 (because I need AF10, and I felt there was too much copy-pasta): The f4 crew removed all the "opaque XXX registers" from the API, in particular the split() -> Parts only contain the pins themselves.
This makes everything nicer, you can e.g. call gpiob.pb3.into_push_pull_output() instead of passing in the gpiob.pb3.into_push_pull_output(&mut gpiob.moder, &mut gpiob.otyper), which really is an implementation detail a HAL should not expose.
@MabezDev@mathk@FrozenDroid: Do we want this too? It would break all the dependent code, but fixing it would be simple ("just remove function arguments until compiler is happy").
The text was updated successfully, but these errors were encountered:
An other way to remove duplication could be to use macro. Also we can still keep the split for the time being but removing the moder et al. register in the Part and use the same technique using the unsafe block.
One down side I can see is that we could potentially be unsafe if different pin is own by different interrupt handler and all try to modify the pin state. We could have a race condition that will not be obvious from the user perspective.
I tried with #61 to simplify the into_afxx functions. @nickray is your link still valid (can you please use the "copy permalink" feature next time, which will link to a specific commit?)
What things are left to do?
I happened on this while looking at https://github.com/stm32-rs/stm32f4xx-hal/blob/master/src/gpio.rs#L341-L345 (because I need AF10, and I felt there was too much copy-pasta): The
f4
crew removed all the "opaque XXX registers" from the API, in particular thesplit() -> Parts
only contain the pins themselves.This makes everything nicer, you can e.g. call
gpiob.pb3.into_push_pull_output()
instead of passing in thegpiob.pb3.into_push_pull_output(&mut gpiob.moder, &mut gpiob.otyper)
, which really is an implementation detail a HAL should not expose.@MabezDev @mathk @FrozenDroid: Do we want this too? It would break all the dependent code, but fixing it would be simple ("just remove function arguments until compiler is happy").
The text was updated successfully, but these errors were encountered: