ST ha rilasciato da poco la famiglia STM32N6, un MCU ad alte prestazioni che integra in un solo silicon un Cortex-M55 con estensioni Helium (SIMD a 128 bit), un’NPU Neural-ART dichiarata a 600 GOPS e 3 TOPS/W, un ISP, encoder H.264 hardware e oltre 4 MB di RAM interna. È un pezzo di hardware che, sulla carta, abilita una categoria di prodotti che fino a ieri richiedevano due chip distinti o un SoC Linux-based: imaging con elaborazione a bordo, deterministico, a basso consumo.
Per noi è interessante perché lavoriamo su imaging medicale con elaborazione embedded, e questa è esattamente la traiettoria che vogliamo seguire: portare elaborazione classica e inferenza neurale dentro lo stesso MCU, senza dover ricorrere a Linux. STM32N6 è il primo silicon ST che lo rende plausibile.
Perché partire da una webcam UVC
Quando arriva un silicon nuovo, la tentazione è fare un benchmark sintetico — qualcosa che esercita una singola feature e produce un numero. Noi abbiamo scelto la strada opposta: il banco prova più rappresentativo possibile di una pipeline reale, anche a costo di non avere numeri “puliti” da pubblicare.
Una webcam UVC tocca due dei sottosistemi più impegnativi del silicon: l’encoder H.264 hardware e il trasporto USB high-speed. Entrambi vanno fatti funzionare insieme con timing serio: l’encoder deve produrre frame compressi a ritmo costante, l’endpoint USB deve consegnarli senza perdere pacchetti. A monte c’è poi un sensore reale collegato via MIPI-CSI2, con un ISP che fa debayering e color processing on-chip. Tre sottosistemi che parlano fra loro: se manca la sincronizzazione di uno, l’intero throughput collassa.
Soprattutto, una pipeline imaging completa modificabile per aggiungere elaborazione — classica o NPU — è una base infinitamente più utile di un benchmark che non riproduce uno scenario reale.
La pipeline
Il flusso end-to-end è lineare:
text IMX335 → MIPI-CSI2 → ISP → buffer RAM → encoder H.264 HW → USB UVC
L’orchestrazione è zero-copy con DMA, schedulata da FreeRTOS. I frame raw dal sensore arrivano in RAM via MIPI-CSI2 e DMA; l’ISP processa in-place (debayering, gain, AWB); l’encoder H.264 hardware legge dal buffer di sistema e scrive lo stream compresso in un secondo buffer; lo stream viene infine consumato e servito come endpoint UVC al PC tramite USBX, lo stack USB di Microsoft Azure RTOS integrato in ST CubeMX. Niente memcpy nascoste: ogni stadio scrive dove il successivo legge.
Sul silicon, in questa demo, usiamo davvero ISP, encoder H.264 hardware e DMA-2D (per movimenti di blocchi nell’orchestrazione buffer). NPU e Helium SIMD restano spenti: non servono per una webcam, sono il territorio della prossima fase.
Throughput effettivo nel setup attuale: 720p a 100 fps, latenza glass-to-USB di circa 50 ms, bitrate H.264 di circa 3 Mbit/s. Sono numeri che danno una scala — non sono il limite del silicon, sono i numeri della configurazione che abbiamo usato. La Nucleo non ha PSRAM esterna, quindi lavoriamo interamente nei 4,2 MB di RAM interna, ed è il vincolo che decide quanti frame buffer possiamo tenere in volo contemporaneamente.
Quello che è stato facile e quello che no
Niente sorprese tecniche sul comportamento del silicon: la demo ST ufficiale gira su EVAL e funziona bene. Il nostro lavoro è stato adattarla a Nucleo — board più accessibile, periferiche più limitate, niente PSRAM esterna. Quello che ST documenta sul silicon, sull’ISP e sull’encoder, in produzione si comporta come promesso.
La difficoltà reale è stata altrove: mancano esempi ufficiali ST per il caso UVC H.264 su Nucleo specifico. Per la EVAL c’è una demo completa di riferimento; per la Nucleo bisogna ricostruire la configurazione delle periferiche partendo da pezzi sparsi in vari example projects, e cambiare il pinning dove la Nucleo non espone le stesse linee. Il lavoro è in larga parte di carpentry — capire cosa la demo originale dà per scontato e che sulla nuova board va riconfigurato — più che di esplorazione del silicon. È il tipo di lavoro che vale fare una volta sola, però, e che ti lascia in mano una base solida per tutto quello che fai dopo su Nucleo-N657X0-Q.
Cosa segue
Questo repo è un MVP funzionante: copre il caso UVC H.264 end-to-end, è verificabile in pochi minuti aprendolo come webcam in OBS o Zoom, e serve come base per le esplorazioni successive. Il passo logico successivo è accendere l’NPU Neural-ART per pipeline AI on-camera, su un caso d’uso reale di imaging medicale — non in astratto.
Che cosa ha deciso il risultato
Il silicon nuovo si valuta non leggendo il datasheet ma trovando il banco prova più semplice che esercita le sue capability vere. Per STM32N6 quel banco era una webcam UVC: è l’esercizio minimo che mette in moto contemporaneamente ISP, encoder hardware e DMA — le tre cose che distinguono questo silicon dal resto della famiglia STM32. Tutto quello che vorremo costruirci sopra, NPU compresa, passa per questi tre blocchi. Che funzionino davvero si verifica prima di tutto il resto.
Il firmware è open source, MIT-licensed, e vive su GitHub: x-cube-n6-camera-capture-nucleo. Per la documentazione tecnica completa c’è la pagina wiki dedicata.
Stai valutando STM32N6 per un tuo progetto di imaging embedded, o lavori su pipeline imaging con AI on-device? Parliamone.