teskje
commented
4 years ago 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
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.
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.