Add clock_configure_mhz function
This adds a clock_configure_mhz function, which trades off accuracy compared to clock_configure (only gets to +/- 1MHz) for reduced code size as it doesn't need 64 bit division.
It takes the source and target frequencies in MHz as 16-bit numbers, to ensure they fit within the 32-bit division.
This is useful for example if you want to calibrate the ROSC using an XOSC and then run off the ROSC, in which case you don't need a very accurate frequency as the ROSC frequency isn't accurate.
As per new code in #2225 we should catch cases where the divider between 1 and 2.
It takes the source and target frequencies in MHz as 16-bit numbers
I guess that means you can't overclock the Pico to 66 GHz? :rofl:
See also #2255
It takes the source and target frequencies in MHz as 16-bit numbers
I guess that means you can't overclock the Pico to 66 GHz? 🤣
That's better than the normal clock_configure, which only lets you overclock to 4.3GHz 🤣
@kilograham do we want this function, or should I close this PR?
no, it is good; i didn't look in detail at the accuracy; does it at least get you near to the right answer, vs 1Mhz away ;-)
no, it is good; i didn't look in detail at the accuracy; does it at least get you near to the right answer, vs 1Mhz away ;-)
If the divider is an integer (ie (src_freq << CLOCKS_CLK_GPOUT0_DIV_INT_LSB) / freq is an integer) then it'll always get the exact frequency, and from having a play I can't find any frequency combinations where that isn't an integer, so I think it'll generally always be correct? If there is a case where that divider is a non-integer then it's rounded down, so you'll get a slightly higher frequency than requested