allow stm32f405 to run at 168mhz

[manitou48]

in ports/stm32f4/peripherals/stm32f4/stm32f405xx/clocks.c
increase CPU clock from 84mhz to 168mhz with this change
RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;

[dhalbert]

@hierophect I guess this would affect the mp_hal_delay_us calculation too.

[hierophect]

I would consider this a part of a planned clock settings rework, which should ideally calculate this and other values from settings in mpconfigboard. It also needs to take into account that oscillators for the ST F405 boards vary from 8MHz to 12MHz. I can up the processor speed in the short term without doing the full rework, but I'll want to make sure it doesn't functionality of SPI and other peripherals, and it'll raise their minimum speeds, which may prohibit use with certain off chip modules.

[manitou48]

Sounds like a plan. Note that if I upload micropython on to Adafruit STM32F405, it runs at 168mhz, and if I use the Arduino IDE, sketches run @ 168mhz on the STM32F405. micropython can change the CPU and bus speeds from python with pyb.freq()

I may try changing the divisor in circuitpython and see what breaks. I haven't tried building a circuitpython .bin, but back in 2015 I was building micropython for pyboard.

[hierophect]

@dhalbert do we support CPU and bus speed adjustment from python? I imagine it's less relevant for the NRF and Atmel ports since they assume set frequencies, but it'd be handy for the STM32.

[ladyada]

as an aside, i would like to have samd51 overclocking support - it overclocks nicely and you get quite a boost! so if y'all come up with a clock adjustment protocol, id want to have it available for other chips

[manitou48]

i changed clocks.c to use DIV2 and ran some circuitpython tests with time.sleep(), time.monotonic() and with a scope. stm32f405 seems to be running at 168MHz. I didn't find any problems. But absence of proof is not proof of absence. :-)

[hierophect]

I've also tested it with a variety of modules today. Submitting a PR momentarily

[hierophect]

It's the same bus frequencies anyway due to the APB divisors - I thought there was a APB divisor quirk that would get in the way but it's only at certain low divisor values, and doesn't apply to SPI, etc. So minimum speeds will be unchanged.

[hierophect]

@ladyada I've found some interesting articles about STM32 overclocking today too so that might be a future PR for fun and profit.

[tannewt]

For general clock changing we could just make microcontroller.cpu.frequency settable. We'd need to validate that all of the downstream clocks are ok when this is done though.

[manitou48]

We'd need to validate that all of the downstream clocks are ok when this is done though.

For the pyboard (STM32F405) and micropython's pyb.freq(), changing CPU and bus frequency is managed in stmhal/modmachine.c, machine_freq()