Albin Hedman
Albin Hedman
See #70 for something close to the obove
I have made a lot more changes in [another branch](https://github.com/usbalbin/stm32g4xx-hal/tree/hrtim2). However that branch also has a lot of unrelated changes so I will at some point try to clean that...
Depending on when there is a new release of stm32g4, I think #102 actually gives us proper support for G491 and G4A1
I just had a sneak peak at [stm32h7xx-hal](https://github.com/stm32-rs/stm32h7xx-hal/blob/master/src/flash/operations.rs) which puts memory fences in the `program` function to prevent the compiler from doing bad things. That is likely the way to...
I will try to re-visit this at a later time
Solves #100
How do we want that to look like? * Move over completely to 1.0 and remove 0.2 support * Use both * Use both but behind features, 1.0 being enabled...
Thanks :) [Here](https://github.com/stm32-rs/stm32g4xx-hal/pull/96/files#diff-eac3481d9342de2b4e8bdf87136844f041041815b5065a5d712c743e139dd2af) is one way in my very much work in progress hrtim PR. :)
Is that sort of API something we want to use for most event based things? ## Just to summarize: Avoid enums for representing event sources in the user facing api...
So implementation wise that would mean that enums are avoided and instead traits are used with member const that are used to configure the listener. Does this make sense? If...