Testing the RP2350B - Page 1
Forum section: electronics / general

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 07, 2025, 10:22:48 pm
content: I started testing the RP2350B (48 GPIO version).The obligatory primes benchmark:Code:// 206.142 sec RP2350B @ 250 MHz ??? bytes 51.5 billion clocksYes 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-buildIts 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)

author: cfbsoftware
author_rank: Regular Contributor
timestamp: April 07, 2025, 11:22:10 pm
content: 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=803The 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

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 07, 2025, 11:47:01 pm
content: 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.

author: brucehoult
author_rank: Super Contributor
timestamp: April 07, 2025, 11:55:40 pm
content: Quote from: SiliconWizard on April 07, 2025, 10:22:48 pm"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?QuoteI 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)

author: brucehoult
author_rank: Super Contributor
timestamp: April 08, 2025, 12:03:45 am
content: Quote from: cfbsoftware on April 07, 2025, 11:22:10 pmFor $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 :-)

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 08, 2025, 12:36:48 am
content: Quote from: brucehoult on April 08, 2025, 12:03:45 amYes! 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 08, 2025, 12:46:04 am
content: Quote from: brucehoult on April 07, 2025, 11:55:40 pmGetting there!Quote from: brucehoult on April 07, 2025, 11:55:40 pmI don't know. Haven't checked the size nor the assembly.Quote from: brucehoult on April 07, 2025, 11:55:40 pmI 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.Quote from: brucehoult on April 07, 2025, 11:55:40 pmWell, 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.

author: brucehoult
author_rank: Super Contributor
timestamp: April 08, 2025, 12:52:32 am
content: Quote from: SiliconWizard on April 08, 2025, 12:36:48 amSadly, 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.

author: brucehoult
author_rank: Super Contributor
timestamp: April 08, 2025, 01:16:59 am
content: Quote from: SiliconWizard on April 08, 2025, 12:46:04 amIs 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 08, 2025, 01:40:50 am
content: 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

author: cfbsoftware
author_rank: Regular Contributor
timestamp: April 08, 2025, 11:17:51 pm
content: Quote from: SiliconWizard on April 07, 2025, 11:47:01 pmThat 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:Quotehttp://pascal.hansotten.com/niklaus-wirth/lilith/emulith/

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 09, 2025, 11:19:00 pm
content: 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:// 178.424 sec RP2350B (RV32 Hazard3) @ 250 MHz ??? bytes 44.6 billion clocksBetter 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.

author: brucehoult
author_rank: Super Contributor
timestamp: April 10, 2025, 04:07:12 am
content: Quote from: SiliconWizard on April 09, 2025, 11:19:00 pmVery 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.QuoteAdded, thanks!QuoteOh, that's weird and unfortunate and unexpected.

author: brucehoult
author_rank: Super Contributor
timestamp: April 10, 2025, 04:13:58 am
content: I asked grok. YMMV. Information not verified.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 10, 2025, 12:03:55 pm
content: 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.cfgAgain only available with the RaspberryPi fork of OpenOCD for now.Seems to work fine, couldn't fault it so far.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 10, 2025, 01:19:14 pm
content: Quote from: brucehoult on April 10, 2025, 04:07:12 amOne 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:#include <stdatomic.h>atomic_int Counter;void Foo(){atomic_fetch_add_explicit(&Counter, 1, memory_order_relaxed);}CM-33:Code:Foo:ldr r3, .L4.L2:ldrex r1, adds r1, r1, #1strex r2, r1, cmp r2, #0bne .L2bx lr.L4:.word .LANCHOR0.set .LANCHOR0,. + 0Counter:.space 4Hazard3:Code:Foo:lui a5,%hi(Counter)li a4,1addi a5,a5,%lo(Counter)amoadd.w zero,a4,0(a5)retCounter:.zero 4

author: MK14
author_rank: Super Contributor
timestamp: April 10, 2025, 02:12:01 pm
content: There is an interesting article on overclocking the RP2350/Pico2:https://learn.pimoroni.com/article/overclocking-the-pico-2It 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.

author: brucehoult
author_rank: Super Contributor
timestamp: April 10, 2025, 02:16:38 pm
content: Quote from: SiliconWizard on April 10, 2025, 01:19:14 pmRISC-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).

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 10, 2025, 07:26:51 pm
content: Quote from: MK14 on April 10, 2025, 02:12:01 pmYes, 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 10, 2025, 08:04:50 pm
content: 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/sSince I write and check an alternate pattern, I manually unrolled my loops a little and got this:* Read: 38 MB/s* Write: 53 MB/sSo, 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")

author: jnk0le
author_rank: Regular Contributor
timestamp: April 11, 2025, 04:32:25 pm
content: You can also try the streamer interface to improve read speeds if the linear prefetching is lacking.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 11, 2025, 08:22:39 pm
content: Quote from: jnk0le on April 11, 2025, 04:32:25 pmI'll have to figure it out too. Read about it in the datasheet.

author: neil555
author_rank: Contributor
timestamp: April 13, 2025, 08:59:49 pm
content: Here's some more information on overclocking ...https://forums.raspberrypi.com/viewtopic.php?t=375975I've been torture testing one of my boards for weeks now at 576Mhz (1.8v) with no issues, it barely even gets warm!

author: Harjit
author_rank: Regular Contributor
timestamp: April 17, 2025, 12:55:00 am
content: 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.

author: brucehoult
author_rank: Super Contributor
timestamp: April 18, 2025, 07:32:34 am
content: Quote from: Harjit on April 17, 2025, 12:55:00 am"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.

author: hans
author_rank: Super Contributor
timestamp: April 18, 2025, 07:55:31 am
content: Quote from: Harjit on April 17, 2025, 12:55:00 amPerhaps 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 18, 2025, 12:52:01 pm
content: Quote from: Harjit on April 17, 2025, 12:55:00 amThe 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.

author: Harjit
author_rank: Regular Contributor
timestamp: April 18, 2025, 09:57:38 pm
content: @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.

author: iMo
author_rank: Super Contributor
timestamp: April 19, 2025, 06:43:40 pm
content: PIO runs on main_clock/2, afaik.. (at least the 2040 does)..

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 19, 2025, 11:45:23 pm
content: Quote from: iMo on April 19, 2025, 06:43:40 pmNo, 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.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: April 21, 2025, 05:17:48 pm
content: The RP2040can do 252MHzover 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.

author: phil from seattle
author_rank: Super Contributor
timestamp: April 21, 2025, 06:01:57 pm
content: Quote from: SpacedCowboy on April 21, 2025, 05:17:48 pmOn the raspi forum there are reports of >300MHz. YMMVhttps://forums.raspberrypi.com/viewtopic.php?t=375975&start=25

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 21, 2025, 08:29:31 pm
content: Well someone managed 375 MHz with HSTX pins to output 720p DVI. That's DDR over HSTX meaning... 750 Mbps per pin.