Testing the RP2350B

[SiliconWizard]

I started testing the RP2350B (48 GPIO version).

The obligatory primes benchmark:

Code: [Select]

// 206.142 sec RP2350B @ 250 MHz               ??? bytes  51.5 billion clocks
Yes it runs @ 250 MHz without a problem. The RP2040 did too. I didn't try higher yet.
The number of cycles is not too impressive, it's barely lower than a Cortex-M4 (not significantly) while I was expecting a bit better with a M33. I haven't tested on a STM32U5 (which is also a M33) to confirm if it's solely reflecting the "performance" of the M33 or if the Flash cache of the RP2350 is maybe a bit less efficient. Doubt it, but can't say for sure. This is of course only comparing the results of "primes", which only says what uh, it says.

Note for those who want to use the pico sdk without their Cmake-based build system: the SDK v2 has become even much more of a monster than v1 was, so you've been warned. You probably remember the gigantic hierarchy of directories; well, with the support of two families, it hasn't gotten any better. They have also dramatically increased the number of macros to define various parameters. Anddd... they don't just use Cmake and some Python now; they now also use Bazel, which I didn't even know the existence of a couple days ago: https://en.wikipedia.org/wiki/Bazel_(software) . Now I do, but it didn't entice me in the least.

I used openocd to flash it. You'll have to build the RPi fork for now, as the official openocd doesn't support the RP2350 yet: https://github.com/raspberrypi/openocd . (The official openocd does support the RP2040 so it's probably safe to assume that they will integrate the RPi changes at some point). You can of course go via UF2 otherwise (but that's not very practical for development purposes). But here again, if you don't intend to use their Cmake/Bazel build system, you'll be in for a rough ride as the old tool (elf2uf2) doesn't support the RP2350 and they have switched to a different tool now for UF2 instead of updating the old one. Of course. So you'll need to build (or download if available for your platform) their new 'picotool' executable, which does a bit of everything except coffee.

Oh and for those who are keen to go directly baremetal without going via the pico-sdk-with-your-own-build-system way first, you can get some (working but very, very crude) starting point here:
https://github.com/metebalci/rp2350-bare-metal-build

Its startup code is very basic, and in particular, it doesn't enable any of the coprocessors of the RP2350 ARM core(s), so if you want to be able to use them, you'll have to figure out how to (oh, and also it only copies the data section, but doesn't zero-out the bss section, so, yes, did I say crude?). Which you'll find in the crt0.S file in the pico-sdk, inside a mountain of conditional compilation and additional source code spread in the runtime.c and runtime_init.c source files. With a non-trivial (before you get to know it) call chain system. I know, because I did build my tests with the pico-sdk and my own makefile, and there were a lot of new things to care about compared to the older sdk with the RP2040, and my first attempts made the CPU hardfault. Finally tracked it down to a NOCP error. Which was because I was calling GPIO functions from the pico sdk, which uses the GPIO coprocessor on the RP2350 (which is nice, btw, doesn't go via a peripheral bus anymore), and this coprocessor was not enabled in the startup code... with the way I was building it.

Just to say that if you're going baremetal, keep this coprocessors thing in mind. The RP2350 -M33 has several of them, and they are nice.

That's all for now, but I'm curious to test PSRAM on it next. And the new PIO.

(Speaking of PSRAM, it doesn't seem to be directly supported by the pico-sdk yet, and there isn't any example in pico-examples either - that I could find - but here's a small project that shows how to configure the QSPI controller for PSRAM, that should be handy to spend less time figuring it all out: https://github.com/FreddyVRetro/pico_psram/tree/main )

[cfbsoftware]

Interesting...

Last October we reported a comparison of the code produced by our Oberon compilers for the RP2040 and the RP2350:

https://www.astrobe.com/forum/viewtopic.php?f=19&t=803

The test program that we ran was originally written in Modula-2 by Niklaus Wirth for his Lilith computer. It is documented in Appendix 2 of the *ETH Report Nr 40 - The Personal Computer Lilith* (The Yellow Report). Apr 1981. N. Wirth which you can download from:

https://www.astrobe.com/Modula2/

The results shown there indicate (taken with a huge grain of salt) that the Pi Pico is ~ 50x faster, and the Pi Pico 2 is ~ 100x faster than a Lilith.

The price comparison of the systems is even more impressive at ~ 5000x:

The Lilith cost ~ $US 8000 (~ $US 25,000 today) whereas you can get a Pi Pico 2 for $US 5

[SiliconWizard]

Ah, for sure. Yes there's about 2x more performance over the M0+ of the RP2040, although of course it's an average and will depend on what exactly is executed.

Having a FPU is nice, and they have added a double-precision coprocessor too, allowing to compute some double-precision operations (it's of course limited compared to a full double-precision FPU) very efficiently compared to resorting to soft FP for double precision. The GPIO coprocessor is also nice if GPIO latency is critical (although in this case, you'll be using the PIO, but I guess having efficient GPIO handling via the CPU itself can still be handy in some cases).

Compared to what was powerful 40 years ago... Yes this is insane. This for the price of a candy bar (the chip)

I'm sure a full Lilith workstation could be emulated on a RP2350 and possibly perform better (that has been done for 68k Macs). I mean emulation of the hardware, CPU included! Could be fun.

[brucehoult]

I started testing the RP2350B (48 GPIO version).

The obligatory primes benchmark:

Code: [Select]

// 206.142 sec RP2350B @ 250 MHz               ??? bytes  51.5 billion clocks

"obligatory" ... heh. Fame! Can fortune be far away?

I'm assuming it's probably the same 228 bytes as the BluePill & BlackPill (submitted), and Teensy (done by me) entries?

Want to try the Hazard3?

This is of course only comparing the results of "primes", which only says what uh, it says.

I think it's as good a test of a CPU core and L1 cache with a decent amount of load/store and branching as any. Or SRAM for microcontrollers.  And with a decent branch mispredict rate even on the top x86 and Apple cores, which isn't easy to do in a micro-benchmark (it's comparable to e.g. gcc)

[brucehoult]

The results shown there indicate (taken with a huge grain of salt) that the Pi Pico is ~ 50x faster, and the Pi Pico 2 is ~ 100x faster than a Lilith.

The price comparison of the systems is even more impressive at ~ 5000x:

The Lilith cost ~ $US 8000 (~ $US 25,000 today) whereas you can get a Pi Pico 2 for $US 5

For $5 you can also get the Milk-V Duo (I paid $3 for mine, but they seem to have gone up) which does the primes test in 43.048s at the default 850 MHz set by the standard buildroot image which is 4.8x faster than this Pi Pico 2 result -- at the 1 GHz they're advertised at (which I'm sure it will happily do I've just never bothered) it should be 5.6x faster.

That's a 64 bit CPU with full FPU, MMU, 64 MB in package RAM, and a 128 bit vector unit.  Plus a bonus 700 MHz 64 bit microcontroller core. And an 8051 :-)

[SiliconWizard]

That's a 64 bit CPU with full FPU, MMU, 64 MB in package RAM, and a 128 bit vector unit.  Plus a bonus 700 MHz 64 bit microcontroller core. And an 8051 :-)

Yes! Now it draws much more power than the RP2350, so the latter still has its place.
I have considered using the CV1800B or SG2002 for a product actually, but I'm still unsure about long-term availability. That's the main issue.

[SiliconWizard]

I started testing the RP2350B (48 GPIO version).

The obligatory primes benchmark:

Code: [Select]

// 206.142 sec RP2350B @ 250 MHz               ??? bytes  51.5 billion clocks

"obligatory" ... heh. Fame! Can fortune be far away?

Getting there!

I'm assuming it's probably the same 228 bytes as the BluePill & BlackPill (submitted), and Teensy (done by me) entries?

I don't know. Haven't checked the size nor the assembly.

Want to try the Hazard3?

I should. Seeing how primes does on RV compared to arm cortex-M, I'm almost certain it will do better. Even the CH32L103 and 32V307 do better for primes.

This is of course only comparing the results of "primes", which only says what uh, it says.

I think it's as good a test of a CPU core and L1 cache with a decent amount of load/store and branching as any. Or SRAM for microcontrollers.  And with a decent branch mispredict rate even on the top x86 and Apple cores, which isn't easy to do in a micro-benchmark (it's comparable to e.g. gcc)

Well, yes. But all I can say is that it tends to perform significantly better on RV32 than on cortex-M for some reason, even the M4/M33, at least for all RV32 cores I've tested it with. While other kinds of tasks will give an edge to the cortex-M. Comparing the assembly will probably explain the reason why. The M7 tends to be better OTOH. CoreMark seems to "favor" the cortex-M compared to your primes.

[brucehoult]

I'm still unsure about long-term availability. That's the main issue.

Sadly, geopolitics is probably a much bigger risk there than the usual question of how long the company will make them for.

Sophgo maybe slightly higher risk than WCH, Espressif, Gigadevice, Allwinner, Rockchip, Amlogic, Gowin, StarFive ... but I think not much more on these things made on older process nodes at domestic factories.

[brucehoult]

I think it's as good a test of a CPU core and L1 cache with a decent amount of load/store and branching as any. Or SRAM for microcontrollers.  And with a decent branch mispredict rate even on the top x86 and Apple cores, which isn't easy to do in a micro-benchmark (it's comparable to e.g. gcc)

Well, yes. But all I can say is that it tends to perform significantly better on RV32 than on cortex-M for some reason, even the M4/M33, at least for all RV32 cores I've tested it with. While other kinds of tasks will give an edge to the cortex-M. Comparing the assembly will probably explain the reason why. The M7 tends to be better OTOH. CoreMark seems to "favor" the cortex-M compared to your primes.

Is it time to again mention that I wrote primes at Samsung in 2016, to compare ARM SBCs such as Pi 3, Odroid XU4 and C2 with the CPUs in Google and Samsung phones and with x86? I hadn't heard of RISC-V at the time, and the HiFive1 wasn't yet announced. It was not biased towards RISC-V!

RISC-V benefits a lot on twisty code, especially on simple cores, from the integrated "compare and branch" instructions.

On the other hand Coremark is in my opinion overweighted on having a fast multiply (which primes does use too) and Arm often has 1-cycle multiply on their lower clock frequency cores, while I don't know of any RISC-V with multiply in less than 3-4 cycles (possibly with an early out if one of the operands is small).

Also there was a kerfuffle in the early days of RISC-V with Coremark. Coremark's code uses "unsigned int" for array indexes which, in my experience, goes against industry practice of using int, long, or size_t. This benefits ISAs that automatically zero-extend 32 bit values and penalises ISAs that automatically sign-extend 32 bit values, which then need extra instructions (two! in basic RV64GC) to zero-extend. RISC-V people put in a typedef for those variables, using "int" instead. The Coremark overlords noticed this and said "your results are illegal, you're not allowed to change the source code" and made everyone change., resulting in lower Coremark results being published from then on.

I think this was unfortunate. Any normal open source project would happily accept a patch typedefing something differently on different machines.

The Zba extension solved this problem with the sh1add, sh2add, sh3add instructions working with int, long, and unsigned long indexes and add.uw, sh1add.uw, sh2add.uw, sh3add.uw efficiently covering the unsigned int case by zero-extending rs1 before shifting and/or adding to the 64 bit rs2.

Of course none of this applies to 32 bit CPUs.

[SiliconWizard]

Yes, the type of your indices can make a significant difference - benchmarked that on RV64 too.

That can also happen on 32-bit CPUs when using a smaller-sized index (like uint16_t or uint8_t). But it also depends on *how* the indices are used. For instance, if simply incremented by 1, it doesn't make a difference. But if doing something different with the indices, then that becomes interesting. That's at least with gcc 14.2. To illustrate the point:

https://godbolt.org/z/rTc6hj5M7

[cfbsoftware]

I'm sure a full Lilith workstation could be emulated on a RP2350 and possibly perform better (that has been done for 68k Macs). I mean emulation of the hardware, CPU included! Could be fun.

That would be an interesting exercise. All the necessary source code of EmuLith, a full working Lilith workstation emulator, is available. The Lilith CPU design uses the AMD2901 bit-slice processor and the emulator emulates the execution of the microcode. However, it might be a bit slow on the RP2350:

The performance of Emulith on a 1 GHz machine is comparable with the real hardware, which used a 7 Mhz main clock. Any operation involving the disk is considerably faster on the emulator.

http://pascal.hansotten.com/niklaus-wirth/lilith/emulith/

[SiliconWizard]

Ok I tested PSRAM.
* Read: 37 MB/s
* Write: 12 MB/s
(Writing an alternate pattern and reading it back/checking, 4 MB data block.)

That's not fantastic. Not completely sure why the discrepancy with the write speed. I tried tweaking timings but I can't get better than this so far.
CPU running at 250 MHz, PSRAM clocked at 125 MHz.

And.... the RISC-V tests.

Interestingly, the read speed I get from PSRAM with the RISC-V core is a bit higher: 39 MB/s (consistently). The write speed is identical.

For primes:

Code: [Select]

// 178.424 sec RP2350B (RV32 Hazard3) @ 250 MHz ??? bytes  44.6 billion clocks
Better than the Cortex-M33. On par with the QingKeV4 cores (but the latter don't currently run at such high speeds on WCH products).

For the "fun" fact: once the RISC-V cores have started, one (possibly obvious, but annoying) consequence is that the chip becomes unaccessible via SWD. Since the ARM cores are off. I haven't dug into the docs deeply enough to figure out if the Hazard3 cores have some kind of SWD-like debug interface or how to access it, so until then, they can't be "debugged" and you can't even flash the chip again using OpenOCD unless you force to boot it in UF2 update mode (which appears to run on ARM cores, luckily enough). Maybe there's a way to deal with it and I haven't found it yet (didn't search yet). If not, that's quite, uh... funky.

[brucehoult]

And.... the RISC-V tests.

Very interesting. The two cores are very comparable, one better on some things e.g. M33 4.09/MHz on Coremark vs Hazard3 3.81 (7% difference), one better on others ... 15.5% to the Hazard3 on primes.

For primes:

Code: [Select]

// 178.424 sec RP2350B (RV32 Hazard3) @ 250 MHz ??? bytes  44.6 billion clocks

Added, thanks!

For the "fun" fact: once the RISC-V cores have started, one (possibly obvious, but annoying) consequence is that the chip becomes unaccessible via SWD. Since the ARM cores are off.

Oh, that's weird and unfortunate and unexpected.

[brucehoult]

I asked grok. YMMV. Information not verified.

[SiliconWizard]

I'll look into that and will report back.

Yes, it does work. You only need to use the rp2350-riscv.cfg config file instead of rp2350.cfg (which is for ARM cores).
https://github.com/raspberrypi/openocd/blob/sdk-2.0.0/tcl/target/rp2350-riscv.cfg
Again only available with the RaspberryPi fork of OpenOCD for now.

Seems to work fine, couldn't fault it so far.

[SiliconWizard]

And.... the RISC-V tests.

Very interesting. The two cores are very comparable, one better on some things e.g. M33 4.09/MHz on Coremark vs Hazard3 3.81 (7% difference), one better on others ... 15.5% to the Hazard3 on primes.

One nice thing with the RISC-V cores is the A extension, supported by most available RISC-V cores these days. Compare a simple atomic add on the Hazard3 and on the CM-33:

Code: [Select]

#include <stdatomic.h>

atomic_int Counter;

void Foo()
{
atomic_fetch_add_explicit(&Counter, 1, memory_order_relaxed);
}

CM-33:

Code: [Select]

Foo:
        ldr     r3, .L4
.L2:
        ldrex   r1, [r3]
        adds    r1, r1, #1
        strex   r2, r1, [r3]
        cmp     r2, #0
        bne     .L2
        bx      lr
.L4:
        .word   .LANCHOR0
        .set    .LANCHOR0,. + 0
Counter:
        .space  4

Hazard3:

Code: [Select]

Foo:
        lui     a5,%hi(Counter)
        li      a4,1
        addi    a5,a5,%lo(Counter)
        amoadd.w        zero,a4,0(a5)
        ret
Counter:
        .zero   4

 

[MK14]

There is an interesting article on overclocking the RP2350/Pico2:

https://learn.pimoroni.com/article/overclocking-the-pico-2

It seems, because the CPU voltage can be set to much higher values than the original RP2040/Pico, it is VERY overclockable, if you are willing to risk messing with the CPU voltage (not recommended for production or any serious use).

Edit: Previous post was too long and hard to understand, so rewritten.

[brucehoult]

Code: [Select]

.L2:
        ldrex   r1, [r3]
        adds    r1, r1, #1
        strex   r2, r1, [r3]
        cmp     r2, #0
        bne     .L2


RISC-V A extension does of course also have the LR/SC way to do it.

Atomic RMW is annoying to implement on a very small RISC core because it needs some kind of sequencing within an instruction, either a state machine or microcode -- and actually more complex than Arm's LDM/STM (which Hazard3 has too, in the form of the Zcmp extension).

One option is to let AMOADD etc trap and emulate it with LL/SC in M mode code: SBI on a bigger machine, a microcontroller could have the code in a little bit of mask ROM and a custom trap vector, maybe even not documented.

Big machines implement AMOADD in the last level cache controller, or even potentially on a completely different machine, on the other side of the room, where that bit of memory exists. If the dst register is Zero (x0), as here, then no reply is needed and on the bus it's just like a store with an extra 3 bit opcode (ADD, AND, OR, XOR, MAX, MAXU, MIN, MINU).

[SiliconWizard]

There is an interesting article on overclocking the RP2350/Pico2:

https://learn.pimoroni.com/article/overclocking-the-pico-2

It seems, because the CPU voltage can be set to much higher values than the original RP2040/Pico, it is VERY overclockable, if you are willing to risk messing with the CPU voltage (not recommended for production or any serious use).

Yes, although past 1.2V/1.3V, I think you're getting into dangerous territory, not just the temperature. I wonder what process node they use for this die?

I'm pretty happy with 300 MHz already. But yes, I've heard some people even considering replacing a STM32H7 with an overclocked RP2350, so... you could need the extra clock frequency. You'll have to set up the Flash wait state appropriately too.

[SiliconWizard]

As to PSRAM read/write speed, I've read about that in a couple threads on the RPi forums. Apparently, it could be due to the QMI cache, that works well for Flash but not so much for PSRAM and it appears that disabling it for PSRAM yields much higher throughput. I'll experiment with that.

Confirmed, when using uncached access:
* Read: 35 MB/s
* Write: 41 MB/s

Since I write and check an alternate pattern, I manually unrolled my loops a little and got this:
* Read: 38 MB/s
* Write: 53 MB/s

So, getting close to the maximum at all possible of ~60 MB/s (bus speed = 125 MHz - just making it clear that I'm talking about MiB/s here, but I refrained from using this not to offend some people), the difference for reads here being just because I check the pattern on the fly which adds a bit of overhead.

That makes sense when writing large contiguous blocks of data considering how the cache is flushed (which unfortunately creates a lot of short bursts on the QSPI bus), so uncached writes of large blocks are much faster. Uncached reads are slightly slower, expected as well. A bit unfortunate for writes, but I guess this cache was really optimized for flash reads anyway rather than writes.

OTOH, writing through the cache will be more efficient if you do a lot of writes in an area of a few KB.
Good thing is that you don't have to disable and re-enable the cache, as they have mapped uncached QSPI access at a different address. So you can combine cached and uncached accesses on the fly, where it makes the most sense.
(See section "4.4.1. XIP Cache")

[jnk0le]

You can also try the streamer interface to improve read speeds if the linear prefetching is lacking.

[SiliconWizard]

You can also try the streamer interface to improve read speeds if the linear prefetching is lacking.

I'll have to figure it out too. Read about it in the datasheet.

[neil555]

Here's some more information on overclocking ...

https://forums.raspberrypi.com/viewtopic.php?t=375975

I've been torture testing one of my boards for weeks now at 576Mhz (1.8v) with no issues, it barely even gets warm!

[Harjit]

How narrow a pulse can one generate on the RP2350B?

I'm curious if the RP2350B can be used to commutate several brushless motors. The STM32G4, some TI and Microchip parts can do single digit nanosecond wide pulses.

I've read the PIO document section but couldn't find a clock tree to work out the details. Thanks in advance.

[brucehoult]

How narrow a pulse can one generate on the RP2350B?

"HSTX Interface: For high-speed applications, the RP2350 includes a High-Speed Serial Transmit (HSTX) interface, which can drive up to 8 GPIOs (pins 12–19) at 150 MHz with double-data-rate (DDR) output, achieving up to 300 Mbps per pin (effectively 150 MHz per bit, as DDR doubles the data rate per clock cycle). This is significantly faster than standard GPIO toggling due to dedicated hardware."

You may not be able to get rail to rail at those speeds, or anywhere near close to it, due to capacitive loading on the output pin, drive strength (maximum 12 mA, default 4 mA), trace length, etc.

[hans]

How narrow a pulse can one generate on the RP2350B?

I'm curious if the RP2350B can be used to commutate several brushless motors. The STM32G4, some TI and Microchip parts can do single digit nanosecond wide pulses.

I've read the PIO document section but couldn't find a clock tree to work out the details. Thanks in advance.

Perhaps my comment will be DOA: but is it necessary for BLDC drive?
E.g. I'm just about to finish a PCB design with STM32H725 which has 275MHz timers. PWM at 25kHz => 275M/25k = 11000 steps per cycle. Divide by 2 for center alignment, so still 12.4 bits. Sure 16-bit resolution is better (you'd even have to slow down the timers on STM32G4 to get 25kHz), but in my mind I would also need to have 16-bit position sensors and 16-bit current sensing to match that resolution.

Other than the RP2350B looks like a fine candidate for 1 motor drive. I've ran some tests with SimpleFOC on the RP2040, and it could only do FOC ticks at 1-2kHz or so. That library uses floating point everywhere..
The RP2350B ARM M33 core has a FPU, so that should speed things up a lot. I measured the performance on a STM32H747 nucleo, and it was processing ticks in around 3.6-3.8 us. I would expect a RP2350B to be more or less on the same magnitude (my guess probably around 10-20 us per FOC tick). The more serious FOC controllers can typically do FOC loops at tens of kHz.

The second problem I had with the RP2350B for BLDC drive is its lack of ADC channels. The QFN-60 only has 4 , the QFN-80 has 8. It wouldn't make it unusable, but I would need 1 MCU per motor. Similarily, the timers only have 2 outputs per channel and no sync at all. Iirc the SimpleFOC library solved that issue by enabling all PWM slices at once.

The Raspberry Pi Pico's are fun chips with PIO etc. but its also clear they choose not to get into the way of ST, NXP etc. for these kinds of applications. The reason ST/NXP/etc. timer peripherals are convoluted as it is, is probably because customers want to build these kinds of applications with them. E.g. if your design is controlling a H-bridge directly, then ideally you'd also want complementary PWM outputs with hardware deadtime insertion. The STM32G4 can do that with HRTIM, many STM32's with their advanced-control timers, but these Pico's can't do it at all.

[SiliconWizard]

How narrow a pulse can one generate on the RP2350B?

I'm curious if the RP2350B can be used to commutate several brushless motors. The STM32G4, some TI and Microchip parts can do single digit nanosecond wide pulses.

I've read the PIO document section but couldn't find a clock tree to work out the details. Thanks in advance.

The PIO can run at up to the system clock and so, officially, up to 150 MHz.
The cores overclock gracefully to a very high degree as discussed earlier. But of course, that doesn't mean that the IO pads will follow.
The PIO can change IO states in just one clock cycle, so you can expect a min pulse width of 6.67 ns. At 250 MHz (at which cores operate just fine), it would be 4 ns. Whether IOs have enough actual analog bandwidth, I don't know.

Since they seem to guarantee 150 MHz, I guess you can count on 150 MHz. I couldn't find any specific specs in the datasheet for IOs though.
Whether the HSTX blocks would enable you to get shorter pulse widths, you'll have to read the datasheet carefully. And the HSTX is less flexible than the PIO, it's essentially a streaming interface so you'll have to prepare all data beforehand, while the PIO can execute simple code on the fly.

But if 6.67 ns min pulse width meets your requirements, then you can absolutely use the PIO to do just about anything in more flexible ways than on a STM32G0. Now what do the "pulses" look like at 150 MHz from the RP2350 GPIOs, I don't know - yet - either. The datasheet seems to lack these specs, unless of course I missed them.

[Harjit]

@hans - my current design is around the STM32G4. My problem is that the motor time constant is extremely low, and the resistance is low. So, I think I'm going to be only using 15% of the PWM range. Then, this means I need finer resolution.

Appreciate the information the clock base for the PIO.

[iMo]

PIO runs on main_clock/2, afaik.. (at least the 2040 does)..

[SiliconWizard]

PIO runs on main_clock/2, afaik.. (at least the 2040 does)..

No, it's clocked from sys_clk directly and connects via the AHB to the CPU cores. There are fractional dividers for each state machine, but you can absolutely use 1 as a the divisor. I haven't seen any difference regarding this point with the RP2040, it was already like this.

[SpacedCowboy]

The RP2040 can do 252MHz  over its general GPIO pads with a pretty darn clear eye diagram. There's a second diagram (slightly less wonderful but still pretty clean IMHO) with it running at 372MHz.

I think the line: "Honestly, this has shaken me. This is a silly amount of bandwidth for a tiny little microcontroller." is a pretty good sum-up...

I'd expect the 2350 to not be worse, but I haven't tested it.

[phil from seattle]

The RP2040 can do 252MHz  over its general GPIO pads with a pretty darn clear eye diagram. There's a second diagram (slightly less wonderful but still pretty clean IMHO) with it running at 372MHz.

I think the line: "Honestly, this has shaken me. This is a silly amount of bandwidth for a tiny little microcontroller." is a pretty good sum-up...

I'd expect the 2350 to not be worse, but I haven't tested it.

On the raspi forum there are reports of >300MHz. YMMV

https://forums.raspberrypi.com/viewtopic.php?t=375975&start=25

[SiliconWizard]

Well someone managed 375 MHz with HSTX pins to output 720p DVI. That's DDR over HSTX meaning... 750 Mbps per pin.