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

Objectifs

Le RP2350 n'a aucun GPU ni moteur d'affichage — mais il possède un bloc unique dans sa catégorie : le HSTX (High-Speed Transmit), un émetteur numérique output-only sur 8 broches, en DDR, cité à 300 Mb/s par broche (datasheet RP2350, §1.1 ; chiffre rapporté par Wikipedia RP2350). Combiné aux 520 Ko de SRAM en 10 banques et aux 16 canaux DMA, il alimente des écrans RGB passifs, des DAC R-2R, des afficheurs parallèles — le domaine d'pico-extras (scanvideo/audio, WIP) et de pico-playground. Ce tuto : comprendre la chaîne DMA→HSTX→broches et monter une démo scanvideo.

Matériel

• 1 × carte RP2350 au format Pico-2 (les démos pico-playground ciblent PICO_BOARD=pico2) + câble USB data
• 1 × écran RGB passif type « DVI sans horloges » ou un breakout HSTX (les schémas de référence sont dans pico-extras/pico-playground) —
• pico-sdk 2.x + pico-extras (branche WIP) + pico-playground

Commandes complètes

# 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

Côté API, la philosophie HSTX :

// 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.

Vérification attendue

Une image animée apparaît sur l'écran RGB : le HSTX crache les pixels en continu, le DMA les ressert depuis la SRAM, et les deux cœurs (M33 ou Hazard3 — le HSTX est un périphérique, il se moque de l'architecture CPU) restent libres pour le rendu. Mesure l'apport mémoire : un framebuffer 320×240 en RGB565 = 150 Ko, soit 29 % de la SRAM — impossible en double buffer sur RP2040 (264 Ko), confortable sur RP2350.

Erreurs fréquentes

• Chercher le HSTX dans le SDK principal : il vit dans pico-extras, une branche explicitement WIP — les API bougent, épingle un commit.
• Croire le HSTX bidirectionnel : c'est un transmetteur, output-only — pour de l'acquisition parallèle rapide, c'est la PIO (12 SM !) qui lit, pas le HSTX.
• Oublier le niveau logique : les broches suivent IOVDD (1,8–3,3 V) — un écran 5 V TTL direct n'est pas garanti, d'où les schémas de référence.
• Sous-dimensionner l'alimentation : une sortie DDR à haute fréquence sur 8 broches + écran tire du courant —
• Écrire dans le framebuffer pendant la trame : tearing — le double/triple buffer est obligatoire, et c'est précisément ce que les 520 Ko permettent.
• Confondre HSTX et PIO : le HSTX est taillé pour le flux parallèle large et rapide (vidéo, DAC) ; la PIO reste reine pour les protocoles bit-bang avec conditions. Les deux coexistent : 3 blocs PIO + HSTX en parallèle.
• Coder en RISC-V en pensant que les exemples scanvideo suivent : la plupart des exemples playground sont compilés/testés en Arm — le port RISC-V des démos vidéo est à ta charge.
• Négliger les contraintes thermiques : ambiance max 85 °C (datasheet §14.9.3) et shutdown détection de jonction 100–150 °C config — une démo vidéo en boîtier fermé peut approcher les seuils.