Tracking issue for refactoring

[teskje]

Let's use this issue to track the state of any larger refactors we are planning to do.

This is also the place for discussing new ideas on a higher level. More specific discussions related to the individual refactors should be taken into the respective sub-tickets.

• Refactor use of features for conditional compilation
• Refactor the RCC module (WIP Make freeze() fallible #153)
  • Discussed in Thoughts on clock config #157
  • Evaluation of approaches Add support for HSE bypass and CSS #156
  • Previous attempt Added new clocks approach #159
• GPIO
  • Refactor the GPIO module (done in GPIO features #129)
  • Input Pin Type consistency
    • See Collapse Input<OpenDrain / PullUp / PullDown) into Input #125
• Refactor CAN (WIP Can refactor #178)
  • Exiting work is done over embedded-can, bxcan and stm32f1xx-hal
• Refactor ADC (WIP Adc refactor #175, Adc instance #281)
  • breaking changes are needed to extend the unfinished feature set.
    At least make it robust of breaking changes and future proof
  • Get inspired by the stm32f4xx-hal adc implementation
  • Allow more devices
• Refactor RTC (WIP Rtc refactor #174)
  • Add RTC example to prove rtc is working. See Initialization of real time clock on stm32f3 Discovery board #87
• Refactor peripheral access
  • Resolve Improve race free register access ergonomics #37
  • Possible solution Improve race free register access ergonomics #37 (comment)
• Serial
  • UART Flow Control Uart Flow Control #128
  • Parity configuration Add support for configuring parity and stop bits for Serial #231
• Incorporate alt-stm32f30x-hal

Whenever we refactor anything, we should be aware of the current state of the art. That means looking at the other HALs under stm32-rs and understanding the design decisions and trade-offs they made. This should help us come up with designs that are future-proof and maintainable.

[teskje]

I'm going to create tickets for the individual action points soon.

Refactor use of features for conditional compilation

The goal of this refactoring is to escape the current #[cfg] hell or at least make it less painful/more maintainable. I quite like what the stm32l0xx-hal is doing, namely introducing internal features for peripheral versions and then using these instead of #[cfg(any(feature = ..., feature = ..., ...))] where possible. If we can get something like this implemented for us as well, that would be a huge improvement I think.

Refactor the RCC module

The main change I'd like to make here is getting rid of the current automatic approximation of settings the user suggested. If the user requests an invalid clock setting, it should simply panic (or ideally fail to build). That would avoid much confusion of users ending up with slightly unexpected clock setting. It should also simplify our code and reduce the opportunity for bugs (which we had in the past).

Refactor the GPIO module

We need to get rid of these huge macros. I don't think we can remove them entirely, but other HALs seem to have managed to significantly reduce them in size at least. At the same time, we also need to ensure that all of our register mappings are actually correct (see #118). The refactor of features mentioned above might help us with that. Done in #189