The release notes for the 2.1.1 Raspberry Pi Pico SDK have a late holiday present: The RP2040 chip is now certified to run at 200 MHz if you use at least 1.15V as the supply voltage.
Previously, the certified speed was 125 MHz, although it was well-known you could overclock the device. By default, the 125 MHz figure is still what you’ll get, though. If you want a higher frequency, you need to set SYS_CLK_MHZ to 200 before doing a build.
They hint that more speed increases may happen in the future. If you want do go as fast as they’ll allow, you can set PICO_USE_FASTEST_SUPPORTED_CLOCK=1 instead. This will always pick the highest frequency which is currently 200 MHz.
There are other updates, too, of course. We noted several bug fixes and a new version of TinyUSB. There are also some new examples, including a few that they forgot to mention in version 2.1.0. We were particularly interested in the mqtt examples, a PIO/DMA UART example, and the multi CDC USB example, something we’ve struggled to work around before on other projects.
So what will you do with a faster Pico? We doubt we are going to see a practical 1 GHz overclock. The emphasis is on the word practical. But we have seen 312 MHz.
250Mhz isn’t mentioned anywhere in the release notes. HaD typo?
Also, this is amazing, the pico was already pretty great at 125Mhz, and at 200Mhz it is even a bit more amazing.
I don’t know where that slipped in. Changed it.
I have a question for you guys here…
At what speed does the microcontroller become too fast to usefully toggle outputs, check inputs and speak to peripheral chips (as a microcontroller is intended) without the project getting glitchy? Especially in a hand assembled project that might be on a breadboard, or deadbug style, etc.
I like that I can do more/quicker calculations in response to an interupt. 16mhz, 125mbps, 320Mhz, 1ghz…. Why do they still make 16mhz microprocessors? I know current draw factors in but smaller/faster chips can require less. Really I just want to know, at what point am I better off choosing a slower processor when I don’t need it. There is not much difference in cost at hobbyist scale.
Well gpio has own clock source from main clock divided by x. More see “pi pico clock tree” or “xyz uc clock tree”
Most peripherals have clock dividers that allow you to have, for example, a 9600 baud UART, and registers to hold the data that you can read/write to/from when convenient (for example when an interrupt is raised saying the register has data to be read, or the tx register has been exhausted). Doing this at 200MHz vs 16MHz should make no real difference, and higher speed gives you more cycles to manage a register upon interrupt (or task scheduling or RTOS). For toggling pins, that is often done on timer interrupts, so same deal.
Glitchiness can come in with faster rise time, which can cause things to act like noisy antennas. I don’t think this is typically affected by CPU speed but rather the Chip’s IO driver design and supply voltage. Some chips (for example the standby stm32f103) even have different IO speeds set by a registers.
i don’t remember the rp2040 gpio off the top of my head but on stm32 i think i remember that gpio doesn’t happen unless you enable a gpio refresh clock. the cpu can run as fast as it wants but it’s just reading/writing internal registers…the physical i/o pins don’t get updated until the clock triggers at some specific and i think generally lower frequency
On pico, the GPIO is called “SIO”: Single cyce IO. This means that you can set and reset a GPIO on the next cycle. At 200MHz that would be a 5ns pulse.
The GPIO hardware however isn’t able to change the state of the physical output that fast.
” Really I just want to know, at what point am I better off choosing a slower processor when I don’t need it. ” I suppose if power is your ultimate goal. IMHO the ESP32 fits most situations. It has a setting where you can change its clock speed from 80, 160 & 240 MHZ, and the upcoming P4 variant will go to 400MHZ.
To be fair, esp32 chips are great at a lotbof things, but being low power isn’t one of them.
If you don’t need wireless, you can get chips with much smaller power consumption.
This is about overclocking… Underclocking is also an option. To answer your question it would really depend on what kind of circuit you’re hooking it up to, and how well you designed it. May as well have the extra overhead–you can always change your code or go in and set a clock speed to slow things down a little if you run into glitches
like others have said, slower microcontrollers have specific features like size / cost / power that can make them attractive. but in general the faster ones are perfectly capable, so long as they have a good i/o subsystem.
but there’s one detail with these faster cpus…and not so much because of the clock rate. on the rp2040, the memory architecture is pretty complicated. there’s a little bit of cache, so instructions execute slower if they are not in the cache. there’s multiple backings for memory, so things can execute faster out of SRAM than out of eXecute In Place flash, depending on your settings. there’s even a little pipelining so i think some instructions are faster or slower depending on their neighbors? i don’t think any of these things are really a problem — in practice it works very well and if you just ‘don’t think about it’ then a lot of your code will just happen to run out of cache and be absolutely as fast as you can hope for, at least the second time through the loop.
BUT
it means that if you are counting cycles for like bitbang I/O according to a specific timing diagram, it can be very hard to count cycles. you can just assume it’ll operate out of cache at the full speed, and the documentation gives you enough information to figure out how fast that is. and i’ve done that a few times and it’s always worked fine for me. but it’s hard to guarantee that’s what’ll happen. if you really care then you kind of have to bend over backwards just a little bit to prime the cache or flush the cache according to your needs. those sort of games are possible too but they get more complicated.
and on top of that, ARM is just so powerful that there’s no incentive to write handcoded assembly and a lot of people wind up never doing that, they write everything in C from the very beginning. and that means you’ll be exposed to a lot of arbitrary decisions within the C compiler, so if you implement a delay loop with like { volatile int i; for (i = 0; i < 1000000; i++) { } } then there is a lot of room for you to be surprised your SDK changes.
whereas on like a PIC12, it’s so small you almost have to write in ASM. and one cycle is one cycle is one cycle. all program memory takes the same amount of time to access and you can very trivially compute the number of cycles for an instruction stream just using the datasheet. for delay-loop-based bitbang I/O, that is one heck of a simplying assumption! the flip side is every instruction is dog slow :)
of course another take on that is that you just shouldn’t use the CPU to bitbang I/O. rp2040 has a pretty wide variety of timers and I/O peripherals so you really don’t need to be doing that with the CPU, and even if you do, you can usually drive it from a timer interrupt instead of using delay loops.
Yeah, your last paragraph is what I was thinking on over the previous ones, I mean, I had to count cycles (for the university and hobby projects on PIC16, HC08 and ATMega8, and some MC6800 emulator) but then, when you (I think most of the time) are so over the needed speed, you can set timers and work more in a “event driven” kind of way.
For more reliable timing, you can mark a C function to be stored in SRAM instead of XIP. I needed to do that for a different reason. I had a display loop running in the second core, and when I would write to flash, it would take the QSPI out of XIP mode, causing the second core to crash. Common guidance is to stop the other core before writing to flash, but moving its code to SRAM was simpler for me.
Running a cpu at a few 10Mhz on a breadboard is no issue. But if you start generating signals of a few Mhz on simple breadboard wires you will start having a bad time on signal integrety.
I think you meant few Ghz, right? A few Mhz is not a problem on the terribly noisy and parasitic BB busses but when you get into the giggle hertz range it starts doing funny things.
IO speed is always configurable in various ways.
What does increase with clock speed is decoupling requirements. You need to get SMD ceramic capacitors close to the pins of RP2040. But for any reasonable breakout these would be already included on the adapter PCB, so it doesn’t matter even for breadboarding.
like the rp2040 zero used in nintendo switch jailbreak. you need 100ohm on two gpios for proper signal integrity. nice one!
Going for output clocks is not the only consideration when designing your products.
Please also consider in your microcontroller
Power current per pin
Total power draw per gpio
Lower frequency can use lower voltage and can be implemented for low power projects, on the other hand usually your chip manufacturer has specific series of controllers or libraries that anyways tries to save power for you.
There is no digital.
There is only analog.
The answer to your question depends entirely on the circuit hanging off the output.
There might be ‘digital’ in quantum computing world, Heisenberg says hi.
When in doubt, I would look to device data sheets.
Older SDRAM chips, for example, would be rated at 150ns (6.6MHz clock) or 120ns (8.2MHz). I’ve seen a more recent RAM chip rated at 55ns (18MHz). Faster is possible, but you need to add Wait States of a clock step (or two).
Without impedance matching, balanced data lines etc. the standard DIL Pi pico interface is more of a speed limiter to be wary of. Even if everything on the board works at 200MHz, once a signal leaves the board all bets are off.
The 1.15v supply mentioned in the article is not the RP2040’s external supply voltage. That remains 3.3v. Instead, it refers to the core supply voltage that is produced by the internal core supply regulator and is configured by the VSEL field of the VREG register. As the core clock frequency is increased, the core supply voltage must also be increased.
Nice! I’ve got a box full of RP2040 boards and now several RP2350 boards to play with. The 2040 boards (standard clocking) that are in my home automation jobs will stay as the 2040 boards are still very capable ARM based micro-controllers. We live in quite a era of cheap reliable electronic hardware for any project you can possibly imagine. Which begs the question … why is it, with bins full of parts, I usually have to still buy something needed for the next project :rolleyes: . Latest was a ultra-sonic range sensor. Oh, I had two of ’em of the shelf, but they needed 5V. The Pico robotics base board I am using only exposed 3.3V (and the higher input voltage to run the motors/servos. So off to Amazon to pick up some 3.3V Ultra Sonic sensors.
Wonder why you did not choose to use a voltage level shifter so to be able to employ the devices already in your shelf?
Level shifters still require the higher supply voltage and[rclark] said their base board doesn’t expose 5V. That’s probably why.
This is why I no longer buy components “because they’re neat and maybe useful in the future”. I wait until I have a need, and then buy only what I need. Anything else I buy, I rarely end up using…
Is this speed bump available in Arduino or micropython/circuitpython? Or do you have to use their SDK?
Peter Mather, the developer of the PicoMite VGA along with Geoff Graham, has been overclocking the RP2040 for more than 3 years. The latest firmware v6.00.01 released January 2025 at https://geoffg.net/picomitevga.html states on page 14 of the manual “ Versions with VGA video have the clock set to 126MHz however this can be changed using OPTION
CPUSPEED to 157.5MHz, 252MHz, 315MHz or 378MHz.”
So, what files does the speed change go into? (PICO_USE_FASTEST_SUPPORTED_CLOCK)?