The code #1
The code #1
Conversation
|
I have sort of tried to get stm32f334 to work(or at least compile). However since this crate is based on the staging pac and the hal is still based on the released pac, well... Edit: I have updated stm32f3xx-hal for the new pac |
|
FYI, here is a very rough attempt at this as its own crate. Nothing too serious for now, mostly just copy paste and fix the errors. Getting it to compile for the stm32f334 was done in the qickest way possible mostly cfg ing out the problematic parts. CC @liamkinne @AdinAck @burrbull in case you find it interesting |
| #[cfg(feature = "stm32f3")] | ||
| otyper: &mut <PINS::GpioX as hal::gpio::marker::GpioStatic>::OTYPER, | ||
| #[cfg(feature = "stm32f3")] | ||
| afr: &mut PINS::Afr |
There was a problem hiding this comment.
Turned out to be quite some differences in how the gpio types work in g4 vs f3 hals. I made an ugly fix for now just to get it to compile but there is a lot if room for improvement there.
The main difference that affects this is how pins are put into alternate mode. The f3 hal requires exclusive access to the gpio blocks shared registers (moder, otyper and afr) which makes sense since it will in fact modify them.
let mut gpioa = dp.GPIOA.split(&mut rcc.ahb);
let pa4 = gpioa
.pa4
.into_af_push_pull(&mut gpioa.moder, &mut gpioa.otyper, &mut gpioa.afrl);The g4 hal however, does not require this and just conjures access to these registers internally(likely not sound?).
let gpioa = dp.GPIOA.split(&mut rcc);
let pin = gpioa.pa8.into_alternate();It is recommended that the pins are connected the HRTIM peripheral only as the last step of initialization to prevent any glitches from occuring on the pins. In my mind, this means that the into_af_push_pull and into_alternate methods should be called by the hrtim init, not by the user. This means that we need to pass in those registers in the f3 case. However there is also the use case where the peripheral is used without any output pins...
|
The most basic example has been ported for all devices and it compiles. Not sure if it works yet though... |
|
Published both https://crates.io/crates/stm32h7-staging and https://crates.io/crates/stm32f3-staging |
Awesome! Thanks a lot :) |
src/control.rs
Outdated
|
|
||
| pub fn wait_for_calibration(self) -> (HrTimCalibrated, FaultInputs, EevInputs) { | ||
| let common = unsafe { &*HRTIM_COMMON::ptr() }; | ||
| while common.isr().read().dllrdy().bit_is_clear() { |
There was a problem hiding this comment.
TODO: Should this even be done on the H7 since they do not have the DLL feature? Should this register field even exist in the pac?
| // Start calibration procedure | ||
| common | ||
| .dllcr() | ||
| .write(|w| w.cal().set_bit().calen().clear_bit()); |
There was a problem hiding this comment.
Dont do this for H7 since it does not have DLL
Compiles for (not at all tested, yet compiles)