RP2: Overclock or CPU_MHZ as a board config option
For PicoSystem we shipped a port of MicroPython that clocks the RP2040 to 250MHz at 1.2v (up from the stock 133MHz 1.1v settings) and have (short of needing to apply the slight overvolt in response to some units not being stable) generally seen these settings to be stable and safe. I accomplished this by maintaining a fork full of hacks where I've modified main.c :grimacing:
Many RP2040-based projects leveraging MicroPython could probably benefit from this same overclock, particularly if the manufacturers are happy to support boards at these speeds.
As such I'd like to propose a board config approach to setting CPU frequency and overvolt, with a view to supporting this in the RP2 port at first and perhaps expanding to other boards (we've encountered MCUs that are ostensibly one speed, but get a manufacturer certified OC frequency later).
This is part of a multi-step process to untie all the hacks I needed to implement for PicoSystem, justify their existence and bring them upstream for the benefit of everyone.
It also seems a shame to leave that 2x+ speedup on the table.
- What settings are common across MCUs for achieving overclock? I guess CPU_FREQ and VOLTAGE perhaps, but the latter could be derived from the former in most cases
- Is there anywhere in the MicroPython codebase where assumptions are made about CPU frequency that this would horribly break?
- Would it be appropriate to configure an "Overclocked Pico" board variant, for those who want to opt in to more performance?
ports/rp2: Add board overclock config.
This is a first shot at implementing #8208
Some points for discussion:
- Naming things, ugh, what should these variables be called?
- The 10ms delay for vreg stabilization is... entirely without experimentation. It's what we use in PicoSystem but that number may have to be higher/lower for other frequencies. Looking at people pushing the limits of clock speed and there are delays anywhere from 1 to 1000ms. There's no SDK function or register we can poll to wait for a stable vreg. (@kilograham do you have any insight into a sensible approach here?)
- Should the delay even happen if the vreg is set to default? It could be optimized out with an ifdef.
It's worth noting that since machine.freq(250_000_000) does not apply an overvolt, it's suboptimal for actually overclocking the RP2040 since some chips (we found this out when testing PicoSystem) do not run stably without at least a modest overvolt. A default overclock for boards that benefit from it would "guarantee" (insomuch as we can do so) that a board will run at the given frequency.
The change intends to clean up this hack - https://github.com/pimoroni/micropython/commit/10c57803c032754e4323977cc815e24e092a4a5d
This will permit us to ship some more overclocked MicroPython firmware variants for boards where it makes sense- mostly stuff that does a lot of pixel-pushing like Galactic Unicorn, PicoSystem and Plasma 2040. The end-user can always use machine.freq() to downclock if they prefer power savings over raw performance.