Add clock_configure_mhz function

[will-v-pi]

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.

[kilograham]

As per new code in #2225 we should catch cases where the divider between 1 and 2.

[lurch]

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? 🤣

[lurch]

See also #2255

[will-v-pi]

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 🤣

[will-v-pi]

@kilograham do we want this function, or should I close this PR?

[kilograham]

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 ;-)

[will-v-pi]

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