Closed usbalbin closed 1 week ago
I have now gotten rid of a few enums in favor of traits to force the user to pass a reference to the actual type instead of an enum variant. See examples/adc-trigger.rs
for how that looks like(this is the only example updated so far, it is not yet tested).
For anyone wanting to give it a try, I am using usbalbin/stm32-rs@ab9082b55029f03cedcf54495dd3a9eb83a59634 until the next stm32-rs/stm32-rs release
@liamkinne or anyone, I am using this or rather yet another branch at work and I would at some point like to merge this or some future version of it.
Since this is starting to turn into quite big set of changes, do you have any preferences for how it should be done? It is all just one single peripheral device so of course there are interdependencies. So splitting things up into multiple PRs, while possible, might be less fun after a certain point.
Also I am using some of the not yet released features from the pac so depending a bit on when the next pac will be released I would prefer to at least wait for that.
I'm not familiar enough with the peripheral to know if it would be easy to break down. Happy to help in reviewing when that time comes.
@usbalbin was just thinking about this for an upcoming project. Do you think it makes sense do this as a separate hrtim
crate like fdcan
so it can be shared between all of the families that have this peripheral?
Not sure how big the difference is between HRTIM in g4x4 vs f334 vs h7, but sure why not :)
According to this (section 1.4): https://www.st.com/resource/en/application_note/an4539-hrtim-cookbook-stmicroelectronics.pdf
There are only a few differences.
tbh I would still go ahead an when it's ready get this merged into G4-hal and later look at making it generic.
According to this (section 1.4): https://www.st.com/resource/en/application_note/an4539-hrtim-cookbook-stmicroelectronics.pdf
There are only a few differences.
Thats seems promising :)
tbh I would still go ahead an when it's ready get this merged into G4-hal and later look at making it generic.
I currently depend on yet to be released pac features. However if that takes too long then perhaps I will try to make it work with the current version. Or ripp out the affected changes in my future PR.
I will close this in favor of #146
Work in progress.
Currently requires https://github.com/stm32-rs/stm32-rs/pull/860 , thus all the CI errors
Thus this(or some future version of this) should probably not be merged until after #102
TODO:
PreloadSource
,MasterPreloadSource