rp2: Using machine.freq() changes UART speed and SPI sck.

[robert-hh]

Less and issue than an observation:

When using machine.freq() the peripheral clock seems to be changed from 125MHz to 48MHz. That change affects the speed of already created UART, SPI. Is does not matter to which value is used for machine.freq(). It may be the same that is already set. This change is persistent until a hard reset,
For I2C and PWM using machine.freq() causing a scl or freq change relating to the ratio of old/new frequency. Setting the freq to the same value as it was before does not change the I2C scl or PWM frequency.
Setting the device speeds again after changing the frequency is then needed for proper rate. The lower and upper limits will be changed. This behavior is not uncommon to ports. So at least it should be documented.

Maybe related to #8424.

[GitHubsSilverBullet]

That's what I was referring to.
Without using the machine.freq() a UART speed up to 1/16 of cpu_clock (~7.8Mbaud @ default 125MHz)) is possible.
After using machine.freq(machine.freq()) which does not change the cpu frequency, the clk_peri changes to 48MHz, thus limiting the achievable baudrate to 3Mbaud.
But even manually restoring clk_peri to the proper value does not resolve the problems.

[robert-hh]

Thanks. The problem with UART baud rate is in the PICO SDK. MicroPython just calls uart_init() from the SDK, and that code looks for me overly complicated. So if (since) your approach works, the a PR has to be made against the Pico SDK.

[robert-hh]

Just a quick test at 20MBaud shows, that it is capped at 12.5 MBaud as expected.

[GitHubsSilverBullet]

Yep, 200MHz ÷ 16
I'd say that's plenty fast for a tiny µC.
And for the huge overhead that Micropython and its UART module brings to the table, even reaching 4Mbaud would be quite a stretch.

OTOH, DMA would be a way to go.
My best PiPico hardware was able to reach significantly more than 300MHz.
Completely useless but fun nevertheless.
Feeding significantly more data through the UARTs than through USB, oh well… ;-)

[robert-hh]

When implementing buffered I/O for UART, I made the stress test at 4 MBaud, which worked well. No data lost while transferring hundreds of MBytes of data in random chunks. The transfer is fast. Working with the data takes it's time, and that does not get substantially faster when using DMA for the transfer between RAM and UART.

[GitHubsSilverBullet]

In general and for smaller buffers (meaning most of the time) I totally agree.
But sending bulk data repeatedly, ie. a 100kB buffer using IRQ/ISR there's at best (using the 7/8 FIFO depth) an overhead of almost 3600 ISR calls every time.
For DMA there's a short setup and then it runs entirely undisturbed (and undisturbing) in the background while the two cores can so whatever cores do to prepare the next 100kB block. ;-)

[aiot-maker]

Thanks @robert-hh for bringing up this discussion (or issue). I could not understand the impact to I2C and PWM. Can you possibly reword your original explanation please ? I have perceived this issue in a code developed some time ago an fixed the misbehaving with an uart.init(). I would never imagine that could be related to the use of machine.freq() used earlier in the code. After reading your post and doing a search on Pico SDK I found the following entries:

Changing system clock sets peripheral clock to 48MHz #841
Changing the sys clock also sets peripheral clock to 48MHz #1346

However the issue has been fixed in the SDK.

[robert-hh]

Thank you for the links. I can try the suggested setting. But anyhow seems clocking UART from a fixed peripheral frequency the better choice, only that should be set at startup. Then the UART baud range is 50 to 3M, which is fine, and will not change with MCU freq setting. Being synchronous, a changing baud rate is less critical for I2C and SPI.
Any comment, @jimmo?

[xyzzy42]

ESP32 had this exact same problem, I also fixed it by changing to a fixed clock. Or rather, keeping a fixed clock, since ESP-IDF already took this into account in the initial UART clock config and upy was undoing it.

I don't know the rp2040 supports dynamic frequency scaling, but probably it will at some point, it's a good way to save power. Thus a non-fixed clock is/will be a problem even for I2C and SPI, because the clock will be constantly changing speed. Even if they are synchronous, you don't want it running at one eighth speed when the CPU slows down and speeding up to full speed mid-transfer.

[robert-hh]

One can change the MCI frequency is required. But that's not automatic. I'm not saying that with I2C and SPI the problem may not exist, but it seems less critical. A changeds freq will not cause immediate data corruption like it does for UART, but the frequency range of peripherals may be exceeded.

[robert-hh]

I made a PR #13718, setting the clock to 125MHz at boot and soft reset. As a side effect, this will set the peripheral freq to 48MHz.

[GitHubsSilverBullet]

Why not set ›clk_peri‹ back to ›clk_sys‹ after the SDK has messed it up so badly during a CPU frequency change.
And then just add a simple note in the SPI and UART docs that they have to reinitialize after a cpufreq() change?

I feel that we unnecessarily limit the ›clk_peri‹ speed to less than 40% of the original value, thus limiting SPI and UART as well.

[robert-hh]

There are two options:

a) set and keep the peripheral clock to 48MHz.
b) let the peripheral clock follow the system clock, and document it for users, that they have to reconfigure the speed of all uart, I2C and SPI device in use whenever they change the frequency.

I went for option a). This is more dependable and causes less confusion to users. It cuts the speed for UART at 3MBaud and for SPI at 24MBaud. But that seems to me acceptable. UART is not meant for high speed. Unlike e.g. Ethernet , the logic level interface has not clear definition in terms of impedance, wiring types etc. So working at high speeds may work for short wires, but is subject to trouble. V24 drivers usually do not support high baud rates. To a lesser extend the same applies to SPI.

[GitHubsSilverBullet]

I can and do follow your reasoning.
But we'll have to ask ourselves, how often will the average user change speed multiple times in a program?
Most of them quite likely not a single time at all.
And if a user does it, it's quite likely towards the northern end to gain a bit more power.
A simple one-liner in the cpufreq() documentation would remind them about the consequences.
Again, most likely none, all they have to do is changing early in their program.
But this is just my personal opinion, others might disagree.

[trentp-igor]

One could automatically reconfigure all peripherals when the CPU clock changes if they depend on the CPU clock. I doubt it would be possible to do it without glitches, so this probably isn't a good idea.

The clock source could be configurable. After all, if there was one clock source that made sense for all applications, the MCU wouldn't have configurable clocks in the first place.

Changing clock speed makes a lot of sense. It is very common that work loads go from nearly idle to busy. Lowering the CPU speed when waiting for something to happen saves power. Every desktop CPU for years always does this. CPUs that just run at a fixed frequency are a thing of the past there. MCUs like the ESP32 series have dynamic frequency scaling too now. I think is only a matter of time until all MCUs that are battery powered will be expected to perform frequency scaling, following the lead of desktop CPUs. As the highest clock speeds possible on cheap silicon processes increases so does the need to not use that speed when you don't need it.

[robert-hh]

One could automatically reconfigure all peripherals when the CPU clock changes if they depend on the CPU clock. I doubt it would be possible to do it without glitches, so this probably isn't a good idea.

Yes, some ports' UART show a glitch when changing the frequency. The reconfiguration shoudl be left to the user code, otherwise there would be bookkeeping overhead which may not be needed. Changing the frequency if required can as well be done by the user code. For power saving most ARM based ports used WFE() or WFI() in the idle state. That save already a low of power.