# Banda di un'interfaccia camera MIPI CSI-2 > Come si dimensiona il collegamento tra un sensore camera e un SoC: dal pixel rate al data rate, l'occupazione delle lane D-PHY, i formati pixel e l'overhead di packetizzazione. Pubblicato: 2026-06-23 Aggiornato: 2026-08-25 Ambito: elettronica Riferimento normativo: MIPI Camera Serial Interface 2 e Physical Layer D-PHY Repository: Pagina: --- Quando colleghi un sensore camera a un microcontrollore o a un SoC, prima di scegliere quante lane usare e a che velocità farle andare devi rispondere a una domanda semplice: **quanti bit al secondo produce il sensore, e l'interfaccia li regge?** Questo strumento risponde a quella domanda; questa pagina spiega il calcolo. ## Cos'è MIPI CSI-2 **CSI-2** (*Camera Serial Interface 2*) è il protocollo con cui, nella stragrande maggioranza dei dispositivi moderni, un sensore d'immagine parla con il processore. Definisce come i pixel vengono impacchettati e marcati (inizio/fine riga, inizio/fine frame, canali virtuali), ma non *come* viaggiano fisicamente sul filo: quello è compito del livello fisico, di norma **D-PHY**. Su D-PHY i dati scorrono su **lane** differenziali in parallelo — tipicamente 1, 2 o 4 — affiancate da una lane di clock. Ogni lane gira a un certo **lane rate** (es. 800, 1500, 2500 Mbps). La banda complessiva è la somma delle lane. ## Come si calcola la banda Il flusso video grezzo è un getto continuo di pixel. La banda richiesta è il prodotto di *quanti pixel al secondo* e *quanto pesa ogni pixel*: $$ \begin{aligned} \text{pixelRate} &= \text{larghezza}\cdot\text{altezza}\cdot\text{fps} && [\text{pixel/s}] \\[6pt] \text{dataRate} &= \text{pixelRate}\cdot\text{bit-per-pixel} && [\text{bit/s}] \\[6pt] \text{capacity} &= \text{numero-lane}\cdot\text{lane-rate} && [\text{Mbps}] \\[6pt] \text{util}\% &= \dfrac{\text{dataRate}}{\text{capacity}}\cdot 100 \end{aligned} $$ Un esempio: **1920×1080 a 30 fps in RAW10**. Il pixel rate è 1920 · 1080 · 30 ≈ 62,2 Mpixel/s; a 10 bit per pixel il data rate è ≈ **622 Mbps**. Su **2 lane a 1500 Mbps** la capacità è 3000 Mbps, quindi l'occupazione è ≈ **21%**: c'è ampio margine. La regola di lettura dell'occupazione: - **sotto ~80%** — c'è margine; - **80–100%** — si è al limite (poco spazio per blanking, overhead, tolleranze); - **oltre 100%** — le lane non reggono il flusso: serve più lane, un lane rate più alto o un formato più leggero. Quella soglia dell'80 % non è arbitraria e non viene dalla specifica: è il blanking del sensore letto al contrario, come si vede più sotto. Un caso opposto: **3840×2160 a 60 fps in RAW12**. Il pixel rate è 3840·2160·60 ≈ 498 Mpixel/s; a 12 bit/pixel il data rate è ≈ **6,0 Gbps**. Sulle stesse 2 lane a 1500 Mbps (3000 Mbps) l'occupazione sarebbe ~199% — impossibile; servono **4 lane a 1500 Mbps** (6000 Mbps), e anche così si è al ~99,5%, al limite. È il tipico punto in cui conviene salire di lane rate o passare a un formato più leggero. ## I formati pixel e i bit/pixel A parità di risoluzione e frame rate, il formato è ciò che fa cambiare la banda: | Formato | bit/pixel | Note | |---|---|---| | RAW8 / 10 / 12 / 14 | 8 / 10 / 12 / 14 | uscita Bayer del sensore, prima dell'ISP | | YUV422 | 16 | luminanza + crominanza sottocampionata | | RGB888 | 24 | RGB pieno, dopo l'ISP | Passare da RAW10 a RGB888 quasi triplica la banda (da 10 a 24 bit/pixel): è il motivo per cui le pipeline ad alta risoluzione preferiscono trasferire il RAW e fare l'elaborazione a valle. ## Overhead: due meccanismi diversi, spesso confusi Il data rate dei pixel è il pavimento, non il soffitto. Ma le due cose che alzano il soffitto sono di natura diversa, e vanno tenute separate: pesano in modo molto diverso. ### La packetizzazione, calcolata: meno dell'1 % Un *long packet* CSI-2 porta un **Packet Header** di 4 byte (Data Identifier, Word Count su due byte, ECC) e un **Packet Footer** di 2 byte di checksum; a questi si aggiungono i *short packet* di Frame Start e Frame End (4 byte ciascuno) e, se abilitati, quelli di Line Start e Line End. Il payload di una riga è width · bpp / 8 byte, quindi: $$ \text{overhead}_\text{pkt} = \dfrac{6 + 8_{\,(\mathrm{LS+LE})}}{\text{width}\cdot\text{bpp}/8} $$ I byte di controllo sono una **costante per riga**, il payload cresce con la larghezza: l'overhead è quindi inversamente proporzionale alla risoluzione orizzontale, e sui formati veri è minuscolo. | Risoluzione | Formato | Payload di riga | Overhead senza LS/LE | Con LS/LE | |---|---|---|---|---| | 160×120 | RAW8 | 160 B | 3,792 % | 8,792 % | | 640×480 | RAW8 | 640 B | 0,940 % | 2,190 % | | 1280×720 | RAW10 | 1600 B | 0,376 % | 0,876 % | | 1920×1080 | RAW10 | 2400 B | 0,250 % | 0,584 % | | 1920×1080 | RGB888 | 5760 B | 0,104 % | 0,243 % | | 2592×1944 | RAW10 | 3240 B | 0,185 % | 0,432 % | | 3840×2160 | RAW12 | 5760 B | 0,104 % | 0,243 % | Su un 1080p in RAW10 la packetizzazione vale **0,25 %** — o 0,58 % con i sincronismi di riga attivi. Diventa significativa solo dove il payload è minuscolo: a 160×120 in RAW8 sono 3,8 %, e con LS/LE 8,8 %. È il caso dei sensori di visione a bassa risoluzione e alto frame rate, dove però il collo di bottiglia è di solito il tempo LP fra pacchetti, non i byte. Quindi: **la packetizzazione non è il 10–20 %**. Chi cita quella cifra sta parlando di un'altra cosa. ### Il blanking, che è il vero 10–30 % Il blanking non *aggiunge* byte: comprime gli stessi byte in una finestra più corta. Un sensore trasmette una riga durante il tempo attivo, poi resta zitto per il blanking orizzontale; alla fine del frame resta zitto per il blanking verticale. Il link, però, deve reggere il rate **istantaneo** durante la riga attiva, non la media sul frame. Detti *b_h* e *b_v* i blanking relativi (i registri `line_length_pck` e `frame_length_lines` del sensore diviso l'area attiva, meno uno), la riga attiva dura 1/((1+b_h)(1+b_v)) del tempo che avrebbe senza blanking, quindi: $$ \dfrac{R_\text{picco}}{R_\text{medio}} = (1 + b_h)(1 + b_v) \qquad\Longrightarrow\qquad \text{util}_\text{max} = \dfrac{1}{(1+b_h)(1+b_v)} $$ I valori tipici di un sensore CMOS stanno fra il 5 % e il 30 % per asse: | Blanking orizzontale | Blanking verticale | Picco / medio | Utilizzo medio massimo | |---|---|---|---| | 5 % | 3 % | 1,082 | 92,5 % | | 10 % | 5 % | 1,155 | 86,6 % | | 12 % | 10 % | 1,232 | 81,2 % | | 15 % | 8 % | 1,242 | 80,5 % | | 14 % | 13 % | 1,288 | 77,6 % | | 20 % | 15 % | 1,380 | 72,5 % | | 30 % | 20 % | 1,560 | 64,1 % | Ed è qui che la soglia dell'80 % smette di essere una convenzione: **80 % di utilizzo medio corrisponde esattamente a un rapporto picco/medio di 1,25**, cioè a circa il 12 % di blanking su ciascun asse — un sensore assolutamente ordinario. La soglia non è prudenza generica: è il blanking tipico, letto al contrario. Con un sensore a blanking più largo (14 %/13 %, rapporto 1,288) il tetto scende al 77,6 %, e con uno stretto (5 %/3 %) sale al 92,5 %. ### Cosa mettere nel campo overhead Lo strumento espone il dato **netto** (i soli pixel) e, se imposti un overhead, anche l'**effettivo**, ed è su quello che calcola l'occupazione. Il numero da metterci è quindi il **blanking**, non una stima di packetizzazione: (1+b_h)(1+b_v) − 1, che per il caso 14 %/13 % fa **28,8 %**. La packetizzazione, se si vuole essere pignoli, si aggiunge sopra e vale qualche decimo di punto. ## Quando servono più lane Se l'occupazione supera la soglia, hai tre leve: 1. **Più lane** — raddoppiare da 2 a 4 lane raddoppia la capacità. È la leva più diretta, se il sensore e il SoC le espongono. 2. **Lane rate più alto** — D-PHY più recenti raggiungono lane rate più elevati; spesso però è il sensore o il PCB a porre il limite. E il lane rate non è continuo: nasce da un PLL con divisori interi, quindi i valori realmente selezionabili sono una griglia. Chiedere «1500 Mbps» può significare ottenere 1440 o 1584, ed è un motivo in più per non progettare a filo di capacità. 3. **Formato più leggero** — scendere di profondità di bit o sottocampionare riduce il data rate alla fonte. Lo strumento calcola anche il **numero minimo di lane** per stare sotto la soglia a quel lane rate, così vedi subito quanta interfaccia serve. ### Un po' di casi, netti e con blanking Gli stessi collegamenti visti prima, calcolati dal motore, con e senza il 28,8 % di blanking del caso 14 %/13 %: | Caso | Netto | Con blanking 14/13 % | Capacità | Utilizzo | Verdetto | |---|---|---|---|---|---| | 1920×1080 30 fps RAW10, 2 lane @ 1500 | 622 Mbps | 801 Mbps | 3000 Mbps | 26,7 % | regge | | 1920×1080 60 fps RAW10, 2 lane @ 1500 | 1244 Mbps | 1603 Mbps | 3000 Mbps | 53,4 % | regge | | 1280×720 100 fps RAW10, 2 lane @ 1500 | 922 Mbps | 1187 Mbps | 3000 Mbps | 39,6 % | regge | | 2592×1944 30 fps RAW10, 2 lane @ 1500 | 1512 Mbps | 1947 Mbps | 3000 Mbps | 64,9 % | regge | | 3840×2160 30 fps RAW12, 4 lane @ 2500 | 2986 Mbps | 3847 Mbps | 10000 Mbps | 38,5 % | regge | | 3840×2160 60 fps RAW12, 4 lane @ 2500 | 5972 Mbps | 7693 Mbps | 10000 Mbps | 76,9 % | **al limite** | L'ultima riga è il punto interessante: 4K a 60 fps in RAW12 su 4 lane a 2500 Mbps sta al 59,7 % sul netto — rassicurante — ma al 76,9 % con il blanking, cioè a un passo dalla soglia. È esattamente il caso in cui ragionare sul solo netto porta a un progetto che non funziona. ## I limiti del calcolo È un calcolo di **banda**, non di temporizzazione. Dice se il flusso ci sta nelle lane; **non** valida il timing, il clock training, lo skew tra lane, l'equalizzazione, né la distinzione tra clock continuo e discontinuo. Non modella l'ISP né la compressione, e usa la sola **area attiva**: il blanking non è dedotto dai registri del sensore ma va inserito a mano nel campo overhead, come spiegato sopra, e vale il 20–30 %. Per il dimensionamento reale di un link camera restano indispensabili i datasheet del sensore e del SoC e la specifica MIPI. ### E se il PHY è C-PHY Il calcolo assume **D-PHY**, dove ogni lane trasporta un bit per tempo di bit e la capacità è la somma delle lane. Il **C-PHY** funziona in modo diverso: lavora a **trio** invece che a coppia differenziale e codifica più di un bit per simbolo — 16 bit ogni 7 simboli, cioè **2,286 bit/simbolo**. Un trio a un dato symbol rate porta quindi più di quanto suggerisca il numero: | Trio C-PHY | Symbol rate | Bit rate equivalente | |---|---|---| | 1 | 2500 Msps | 5714 Mbps | | 2 | 2500 Msps | 11 429 Mbps | | 3 | 2500 Msps | 17 143 Mbps | | 2 | 5700 Msps | 26 057 Mbps | Per usare questo strumento con un link C-PHY basta convertire: numero di trio × symbol rate × 16/7 dà la capacità equivalente in Mbps, da confrontare col data rate. Restano fuori i casi multi-canale-virtuale, dove più flussi condividono le stesse lane e la somma dei rate va fatta prima del confronto. ## Riferimenti - **MIPI Alliance** — [mipi.org](https://www.mipi.org), ente che pubblica e mantiene le specifiche **CSI-2** e **D-PHY**. - **x-cube-n6-camera-capture-nucleo** — il nostro progetto di acquisizione camera UVC su STM32N6 (IMX335 via MIPI-CSI2 + ISP), da cui nasce questo strumento: [github.com/stefanofante/x-cube-n6-camera-capture-nucleo](https://github.com/stefanofante/x-cube-n6-camera-capture-nucleo). - **Strumento correlato** — il [calcolatore di banda MIPI CSI-2](/tools/mipi-csi2-bandwidth/) mette in pratica tutto questo: inserisci risoluzione, formato e lane e leggi data rate e occupazione.