Dario Nieuwenhuis

yes! there should be no unrelated commits. If you have to open a new PR then so be it :)

We shouldn't rely on unclaimed pins being in a particular state, we should consider them undefined. Some don't start in analog mode (I think?) and there could also be bootloaders...

- Make sure you're configuring RCC to clock from HSE. The default is HSI, which is less precise which can cause issues if there's differences between the two boards, as...

Sounds great to me! The more features, the better! I don't think I'll be able to help much, I'm not personally invested in LoRa. I can help with API design/consistency...

IMO tests that mock register reads/writes have limited value, wrt the required effort. Many bugs in peripheral drivers are due to the peripheral not doing what you think it does...

Interesting! What protocols are you going to implement? Some prior art on nrf52 radio stuff: [ieee802154](https://github.com/nrf-rs/nrf-hal/blob/master/nrf-hal-common/src/ieee802154.rs), [ESB](https://github.com/thalesfragoso/esb), [BLE](https://github.com/jonas-schievink/rubble). The issue with RADIO is that protocols often have very tight timing...

It is intentional that the current `Timer` implementation is tied to the executor. It keeps track of expirations per task, not per timer, which allows it to reuse the task...

Agreed! Maybe splitting `new` into `new` and `new_with_dma` would work, so that `new_with_dma` can have the right trait bounds.

:+1: to having a "portable" time driver that only uses ARM stuff, but ARM isn't making it easy, yeah... :sweat_smile: "Calibrating" how much time stopping+restarting systick takes doesn't seem like...

> fails when openning the com port. What error do you get? Also, can you try connecting with a pre-made terminal program, like PuTTY? Also, please paste the full trace-level...