HRTIM

[usbalbin]

We should probably wait until some sort of release before we merge this or we could perhaps put it behind some experimental feature flag(?)

Fixes #69

[usbalbin]

stm32-hrtim is by no means "done", lots of missing features, there is a lot of weird trait bounds etc. Overall there is room for improvement. With that said I do think it is useful for what it does as is.

@burrbull, @AdinAck and @boondocklabs what do you think is the best way to move this forward?

Some steps in no particular order

• Transfer ownership of stm32-hrtim to stm32-rs (if they want it)
• stm32-hrtim publish to crates.io / or just a github release
• Merge this PR(in some form) perhaps with hrtim behind some experimental feature

What are your thoughts? :)

[burrbull]

I think first step is to release stm32-hrtim 0.1 on crates.io.
You can transfer its ownership any time after release.

[AdinAck]

Wow, this clearly took a great deal of effort and I commend you as such.

I do think this should eventually be included in stm32-rs just like any other peripheral, I can't say what intermediate steps should be taken.

Again, great stuff, thank you :) Let's make some buck regulators! Woohoo!

[usbalbin]

Thanks :)

So I'll just

~/stm32-hrtim $ cargo publish --features stm32g474,defmt

then?

[usbalbin]

Done - stm32-hrtim

[usbalbin]

How is this best done? I want the hrtim feature to be optional (just like can and cortic) but only available for stm32g474, stm32g484.

Is there any other/better way than

#[cfg(feature = "hrtim", not(any(feature = "stm32g474", feature = "stm32g484"))]
compile_error!("`hrtim` is only available for stm32g474 and stm32g484");

[usbalbin]

I'll merge this now unless someone objects :)

[usbalbin]

Thank you all for all the help along the way! :)