[(maybe?)DON'T MERGE] Update pac #102
Conversation
usbalbin
force-pushed
the
update_stm32g4
branch
from
b4c460e to
ac223dc
Compare
usbalbin
force-pushed
the
update_stm32g4
branch
from
2adb9f0 to
f197daf
Compare
usbalbin
force-pushed
the
update_stm32g4
branch
from
be8318e to
369754d
Compare
|
@AdinAck this is now updated for stm32g4-staging v0.17.0
|
|
Awesome!! HRTIM support would be great! This enables me to upstream the fully enforced Cordic interface, would you like me to do so? |
| #[cfg(any(feature = "stm32g471", feature = "stm32g491", feature = "stm32g4a1"))] | ||
| opamps! { | ||
| Opamp1 => opamp1: { | ||
| vinm0: crate::gpio::gpioa::PA3<crate::gpio::Analog>, |
There was a problem hiding this comment.
You could reexport all pins from gpio::gpiox to gpio and get access by just gpio::PA3.
src/dma/stream.rs
Outdated
| dma.ifcr().write(|w| w | ||
| .[<ctcif $x>]().set_bit() //Clear transfer complete interrupt flag | ||
| .[<chtif $x>]().set_bit() //Clear half transfer interrupt flag | ||
| .[<cteif $x>]().set_bit() //Clear transfer error interrupt flag | ||
| .[<cgif $x>]().set_bit() //Clear global interrupt flag | ||
| ); |
There was a problem hiding this comment.
DMA can be fully demacrofied:
| dma.ifcr().write(|w| w | |
| .[<ctcif $x>]().set_bit() //Clear transfer complete interrupt flag | |
| .[<chtif $x>]().set_bit() //Clear half transfer interrupt flag | |
| .[<cteif $x>]().set_bit() //Clear transfer error interrupt flag | |
| .[<cgif $x>]().set_bit() //Clear global interrupt flag | |
| ); | |
| let num = Self::NUMBER as u8; | |
| dma.ifcr().write(|w|{ | |
| w.ctcif(num).set_bit(); //Clear transfer complete interrupt flag | |
| w.chtif(num).set_bit(); //Clear half transfer interrupt flag | |
| w.cteif(num).set_bit(); //Clear transfer error interrupt flag | |
| w.cgif(num).set_bit() //Clear global interrupt flag | |
| }); |
Co-authored-by: Zgarbul Andrey <zgarbul.andrey@gmail.com>
What is the plan with regards to the pac? Is it going to be released soon (not staging) or are there potentially more things on the horizon until then? Not really sure how best to proceed here. Should we merge this PR soonish and continue building on top of that? Or keep a separate experimental branch with new features requiring this new staging pac? |
A dev branch sounds like the best course of action to me. I think once the actual PAC is updated then we can merge it. But in the meantime I'd love to keep improving on peripheral interfaces with the staged PAC. |
Only @adamgreig can say something about this. |
|
I will close this in favor of #142. Thank you both :) |
#96 requires updates to the pac. However the new pac changes register blocks member fields to access methods.
Almost all this PR does is adding paranthesis to things like
This PR currently uses stm32g4 from the nightly repo, I assume at some point a new version of the pac is released. We can then merge this PR(after updating it to depend on that released pac).
I will use this as a base when working on #96 for now..
Edit:
Now using stm32g4-staging