japaric / stm32f103xx-hal

HAL for the STM32F103xx family of microcontrollers
Apache License 2.0
115 stars 40 forks source link

Clock source selection #38

Open LunNova opened 6 years ago

LunNova commented 6 years ago

The CFGR builder API doesn't let you select a clock source.

Possible sources:

Currently it only uses the first two options.

Should set cr.hseon and wait for cr.hserdy before setting up PLL. Also HSEBYP if using a clock source and not a crystal. cfgr.pllsrc().external() swaps to HSE as pll source. Probably want pllxtpre().no_div().

Maybe like this?

    let clocks: Clocks = rcc.cfgr
        .sysclk(72.mhz())
        .hclk(72.mhz())
        .pclk2(72.mhz())
        .pclk1(36.mhz())
// This by default?
//       .source().internal()
// pass frequency of external crystal
        .source().external(8.mhz())
// pass frequency of external clock
//      .source().external_bypass(8.mhz())
        .freeze(&mut flash.acr);
japaric commented 6 years ago

Maybe like this?

Looks good to me but I would make external unsafe since it requires the caller to pass the right value. The rationale of unsafe is that if the caller passes a wrong value that could result in a valid clock configuration (e.g. real system clock frequency of 64 MHz) but a wrong flash latency value (e.g. no latency because the value computed in software was 24 MHz) and that would result in undefined behavior (IDK the full consequences but I heard from someone that ran into this that the processor would jump to the hardfault handler at random locations of the program).

TeXitoi commented 5 years ago

Related to https://github.com/japaric/stm32f103xx-hal/pull/93

@mvirkkunen Did you see this issue?

mvirkkunen commented 5 years ago

@TeXitoi Yes, I did, but only after I sent that PR. There doesn't seem to be much activity on this repo at the moment so I'm leaving it be and focusing on other things until somebody wakes up.