The new Raspberry Pi Pico 2 with its RP2350 microcontroller has only been with us for a short time, and thus its capabilities are still being tested. One of the new peripherals is HSTX, for which the description “High speed serial port” does not adequately describe how far it is from the humble UART which the name might suggest. CNX Software have taken a look at its capabilities, and it’s worth a read.
With a 150 MHz clock and 8 available pins, it’s a serial output with a combined bandwidth of 2400 Mbps, which immediately leaves all manner of potential for streamed outputs. On the RP2040 for example a DVI output was made using the PIO peripherals, while here the example code shows how to use these pins instead. We’re guessing it will be exploited for all manner of pseudo-analogue awesomeness in the manner we’re used to with the I2S peripherals on the EP32. Of course, there’s no corresponding input, but that still leaves plenty of potential.
Have a quick read of our launch coverage of the RP2350, and the Pico 2 board it’s part of.
Important part left out, no receive functionality.
Perhaps you could do it with MeshTastic? No ?
I think “it’s a serial output” implies this :)
implication is more or less the reverse of clarification
“Of course, there’s no corresponding input, but that still leaves plenty of potential.”
From the end of the second paragraph.
Its a shame this article relies heavily on following the link to the other website. It leaves out a lot of core details like the ability to operate in ddr mode for 300mt/s at 150mhz, at up to 8 pins wide to get the 2400mbps.
Additionally it contains dedicated equipment for streaming data directly from the PIOs and the dedicated full speed TDMS encoder.
The TDMS encoder seems targetted specifically for DVI as the datasheet mentions it.
All of these specs and features are significant as its now possible to reach and pass the required DVI speed for 1080p @60fps, though I feel you’d have a tough time filling the screen with anything more than test patterns with the limited memory and processing power available.
TMDS : Transition Minimized Differential Signaling
Not TDMS.
This hardware only doubles the external bandwidth relative to the RP2040.
The RP2040 got (by overclocking, and maybe overvolting) 25-40MPx/sec, this “only” gets you DDR so probably 25-80MPx/sec, not particularly near the needed 149MPx/sec for 1920×1080@60Hz. Which at least includes 1280×720@50. ( https://types.pl/@wren6991/112928551154168764 )
What makes this really interesting for is 640×480@60Hz without any overclocking at all, meaning it’s now officially usable for commercial products.
It’s worth mentioning that the interpolation unit is interestingly graphics-friendly, with hardware support for alpha compositing and affine texture mapping at one cycle per pixel. There’s not enough SRAM for a full 640×480 framebuffer but there are very possible, er, possibilities for doing scanline-at-a-time video generation based on a display list.
Like the Atari VCS in 1977? ;-D
Yes, but Atari couldn’t update every pixel every frame. Not enough clock cycles. And it had palette colors anyway, we are speaking about rgb888.
And there is that second core..
Can the encoder be used for multiple streams, or is it directly tied to the output? DVI/HDMI take 3 TMDS lines to operate, and 6 for dual-link DVI.
Now get the chip in stock alreadyy.
Here is an article from a developer who has been lucky enough to play with the new RP2350 for an entire year! It’s so well written it deserves its own Hackaday post!
https://dmitry.gr/?r=06.%20Thoughts&proj=11.%20RP2350
As [Pat] mentioned in the previous article, 8 IOs and 125 MHz means one should be able to send out UDP packets via GMII, or even leverage two RGMII PHYs for twice the throughput. Not bad for projects like logic analyzers that’ll land between the venerable FX2 and FX3.
The cheapest PHY I found is YT8531C ($0.8622 /100).
It’d need to be a little hack-y without receive capability, but not too bad: for a dedicated point-to-point setup you could always do the low-bandwidth commanding via USB and heavy data dump via RGMII.
The HSTX alone lets you try doing GMII with receive, I guess: the old PIOs couldn’t toggle pins fast enough to generate a 125 MHz clock (as far as I knew) but the HSTX might – might require being overclocked a bit.
I do love that circuitPython now has frameBuffer to DVI built in, along with USBhost/HID: baby python computers in the style of 8-bit machines are already here as adapters to the Pico.
s/EP32/ESP/
s/EP32/ESP32/
I wonder if the pico is now poerful enough to implement a RGB to HDMI converter for retro hardware…
HDCP stripper would be a killer use case, but I believe it’s asking too much.
It seems limited. HDMI uses only so many lines (and isn’t 720p the minimum transmission format?). I can’t remember details. You still have intra frame and line blanking taking away bandwidth.
It should be able to handle wide SD resolutions, which is good. But on HDMI, can it handle 10 bit 720p60 or any 1080? Ideally, higher speed per pin is more important for HDMI.
Personally, I’m interested in emulating line graphics on a 4k/8k raster display so they look smoother. But, I doubt I can do an Atari 2600 racing the beam plantation, even at 1080p. What do people think?
HDMI can do lower than 720p, including 640p and even wide SD resolutions such as 1440x480i.
I think it’s going to be useful for outputs up to 640p, and possibly even 720p, but it would have to be some sort of streaming configuration, or else very basic beam racing graphics, unless there’s something I’m missing.