Frans Skarman

> Thank you both! I think this can be closed, it seems I was just using it wrong. I'll go ahead and re-open this since this crate is designed to...

Thanks for the PR, and sorry for the review delay! Looks good to me, I left a small note on the return value of `enable_temp_vref` for discussion. Could you also...

My question was more about if the function should return anything at all. Is there a use case for knowing if it was previously on (or off)?

Good catch (and sorry for the delay), I don't think there is a good reason for us not having that already. If you're interested, I could show you how to...

Sorry for the delay. I think all that is required is to add another one of these macros https://github.com/stm32-rs/stm32f1xx-hal/blob/master/src/gpio.rs#L1315 for the other peripherals. It probably also needs feature gating because...

That's interesting. I don't quite remember the details of how flash works so I may not be of much help ATM. Do you have access to a debugger (rtt, itm...

I also like 2, but 3 would also work well. I made a PR to the stm32f103 repo a while ago implementing 2 https://github.com/japaric/stm32f103xx-hal/pull/53

While I prefer 2, I wouldn't mind 3 either. However, I think it's important to be consitent. If 3 is chosen, but resets are also done automatically by some crates,...

> Not sure what you mean by that What I mean is that with method 2, the responsibility to clear errors is on the HAL implementation author. This means that...

This looks like a good proposal to me. It would solve most issues I pointed out in #46. One thing it doesn't directly solve is specifying timeouts for `CountDown` without...