Closed pigrew closed 4 years ago
Not a big fan of debug assertions (or anything that radically changes the behaviour between dev and release builds, really) but the rest of your proposal sounds good to me.
I've been struggling with how much #[cfg(...)]
to use in the code. On one hand, it makes mistakes (targeting features not on the particular MCU) create compile-time errors (good thing, IMHO). On the other hand, it will make the generated API documentation and source code harder to read (since they will have lots of conditional compile directives in them).
Currently, I have:
#[cfg(any(
feature = "stm32f042",
feature = "stm32f048",
feature = "stm32f070", // Doesn't have HSI48
feature = "stm32f072",
feature = "stm32f078",
))]
pub enum USBClockSource {
#[cfg(feature = "stm32f070")]
/// USB peripheral tranceiver clock is disabled
Disabled,
/// HSI48 is used as USB peripheral tranceiver clock
#[cfg(not(feature = "stm32f070"))]
HSI48,
/// PLL output is used as USB peripheral tranceiver clock
PLL
}
Should I continue with these cfg
statements, or just let the enum be defined for all MCUs but have assertions that they are valid in the freeze()
function?
On the STM32F070RB, USB can only be used with the PLL source, not HSI48 (which doesn't exist). A method to select
RCC.CFGR3.USBSW=1
should be provided.Some implementation points to be considered (with my tentative answers in parenthesis):
freeze()
that the PLL is enabled if the PLL source is selected for USB? (Yes)enable()
that the selected clock's speed is 48 MHz? (Maybe not since we'd need to start also adding Rcc to the USB peripheral struct)Proposed usage:
ADDENDUM: The STM32F1xx HAL has some logic related assertions about the USB clock, so my plan is to duplicate its API as much as possible.