🛠 HSTX : générer une sortie vidéo/parallèle haute vitesse avec les 8 broches DDR

Objectives

The RP2350 has no GPU or display engine — but it features a unique block in its category: the HSTX (High-Speed Transmit), an output-only, 8-pin, DDR digital transmitter, cited at 300 Mb/s per pin (RP2350 datasheet, §1.1; figure reported by Wikipedia RP2350). Combined with 520 KB of SRAM in 10 banks and 16 DMA channels, it drives passive RGB screens, R-2R DACs, and parallel displays — the domain of pico-extras (scanvideo/audio, WIP) and pico-playground. This tutorial: understand the DMA→HSTX→pins chain and build a scanvideo demo.

Hardware

• 1 × RP2350 board in Pico-2 format (pico-playground demos target PICO_BOARD=pico2) + USB data cable
• 1 × passive RGB screen of the "DVI without clocks" type or an HSTX breakout (reference schematics are in pico-extras/pico-playground) —
• pico-sdk 2.x + pico-extras (WIP branch) + pico-playground

Complete commands

# 1) SDK + extras + playground côte à côte
git clone https://github.com/raspberrypi/pico-sdk.git
git clone https://github.com/raspberrypi/pico-extras.git
git clone https://github.com/raspberrypi/pico-playground.git
export PICO_SDK_PATH=$PWD/pico-sdk PICO_EXTRAS_PATH=$PWD/pico-extras

# 2) Les démos scanvideo du playground (dossier scanvideo)
cd pico-playground && mkdir build && cd build
cmake -DPICO_BOARD=pico2 ..
make -j$(nproc) scanvideo/hello_scanyuv   # exemple type

On the API side, the HSTX philosophy:

// Le HSTX lit la SRAM via DMA et émet en DDR sur 8 broches.
// Pseudo-squelette (API pico-extras WIP, vérifie l'en-tête hardware/hstx.h)
// - configurer le timing : front porch / sync / back porch par ligne
// - charger les pixels en SRAM (banque dédiée pour ne pas bloquer le CPU)
// - armer un DMA circulaire : buffer -> HSTX_DATA, déclenché par le timer vidéo
// - le CPU peut peindre le buffer suivant pendant la transmission : le
//   double buffering tient parce que le RP2350 a 520 Ko, pas 264 Ko.

Expected verification

An animated image appears on the RGB screen: the HSTX spits out pixels continuously, the DMA serves them from SRAM, and both cores (M33 or Hazard3 — the HSTX is a peripheral, it doesn't care about the CPU architecture) remain free for rendering. Measure the memory footprint: a 320×240 framebuffer in RGB565 = 150 KB, which is 29% of the SRAM — impossible with double buffering on the RP2040 (264 KB), comfortable on the RP2350.

Common errors

• Looking for the HSTX in the main SDK: it lives in pico-extras, an explicitly WIP branch — the APIs change, pin a commit.
• Believing the HSTX is bidirectional: it is a transmitter, output-only — for fast parallel acquisition, it is the PIO (12 SMs!) that reads, not the HSTX.
• Forgetting the logic level: the pins follow IOVDD (1.8–3.3 V) — direct connection to a 5 V TTL screen is not guaranteed, hence the reference schematics.
• Undersizing the power supply: a high-frequency DDR output on 8 pins + screen draws current —
• Writing to the framebuffer during the frame: tearing — double/triple buffering is mandatory, and this is precisely what the 520 KB allows.
• Confusing HSTX and PIO: the HSTX is designed for wide and fast parallel streams (video, DAC); PIO remains king for bit-bang protocols with conditions. Both coexist: 3 PIO blocks + HSTX in parallel.
• Coding in RISC-V thinking that the scanvideo examples follow: most playground examples are compiled/tested in Arm — the RISC-V port of the video demos is up to you.
• Neglecting thermal constraints: max ambient temperature 85 °C (datasheet §14.9.3) and junction shutdown detection 100–150 °C config — a video demo in a closed case can approach the thresholds.