Introduzione alle specifiche e ai protocolli MIPI CSI

Una panoramica dell'interfaccia camera MIPI CSI-2: dall'architettura di sistema e dalla trasmissione a livello fisico ai formati immagine, alla stima della larghezza di banda, all'integrazione Linux e alla risoluzione dei problemi.

Introduzione

Questo articolo offre una panoramica dell'interfaccia camera MIPI CSI-2, analizzando l'architettura di sistema, la trasmissione D-PHY, i meccanismi dei pacchetti, i formati immagine e la stima della larghezza di banda, oltre all'integrazione e alla risoluzione dei problemi nell'ambito del framework Linux media-controller. I contenuti sono rivolti all'integrazione hardware e software di SoC basati su ARM, sensori d'immagine, ISP e pipeline video V4L2.

Architettura del sistema MIPI CSI

MIPI CSI-2 (Camera Serial Interface 2) è un protocollo seriale ad alta velocità utilizzato per trasferire dati immagine da un sensore a un SoC, un ISP o un FPGA. CSI-2 definisce i formati dei pacchetti, i Data Type, i Virtual Channel e i meccanismi di protezione dagli errori, mentre D-PHY o C-PHY gestiscono la trasmissione fisica del segnale.

Trasmissione e temporizzazione D-PHY

Quando è inattiva, una Data Lane D-PHY rimane nello stato LP Stop e passa attraverso la sequenza di stati LP per entrare in modalità HS prima di trasmettere i pacchetti CSI-2. L'accesso ai registri del sensore e il controllo dello streaming sono generalmente gestiti tramite un bus I²C/I³C separato, distinto dagli stati LP della Data Lane D-PHY.

• In modalità clocked, la Clock Lane supporta il campionamento del ricevitore durante la trasmissione HS. Il funzionamento con clock continuo o non continuo deve essere verificato in base al sensore d'immagine, al PHY del SoC e alla configurazione del driver.
• HS-Settle deve essere regolato in base alla frequenza di link effettiva, alla documentazione del ricevitore SoC e ai contatori di errore; un valore più alto non è necessariamente migliore.

Pacchetti CSI-2 e sincronizzazione

CSI-2 utilizza Short Packet per trasportare eventi di protocollo o informazioni di sincronizzazione, mentre i Long Packet trasportano dati RAW, YUV, RGB o dati embedded. Un Long Packet è composto da un header di 4 byte, un payload e un footer CRC di 2 byte.

Frame Start (FS) e Frame End (FE) forniscono la sincronizzazione a livello di frame. Line Start (LS) e Line End (LE) forniscono una sincronizzazione opzionale a livello di linea. L'effettiva trasmissione di LS e LE deve essere verificata nella documentazione del sensore d'immagine, nelle tracce del ricevitore CSI o nei contatori del driver.

Formati immagine e larghezza di banda

I Data Type CSI-2, i codici media-bus V4L2, i formati di memoria di acquisizione V4L2 e la negoziazione dei formati ISP devono rappresentare dati immagine compatibili, pur appartenendo a livelli di astrazione differenti. I nomi e le posizioni delle configurazioni non devono necessariamente corrispondere uno a uno. Per i dati RAW, verificare sia la profondità in bit sia l'ordine Bayer; per i dati YUV, verificare l'ordine dei byte.

Questo calcolo rappresenta soltanto il payload minimo richiesto dai dati dei pixel attivi. Il throughput CSI-2 effettivo e il data rate delle lane D-PHY devono considerare anche header dei pacchetti, CRC, pacchetti di sincronizzazione, strategia di trasmissione del blanking, numero di Data Lane, modalità di clock, frequenze di link disponibili per il sensore e limiti del ricevitore CSI del SoC.

Integrazione e avvio su Linux

Il Device Tree descrive generalmente i graph endpoint, le data-lanes, le clock-lanes e le connessioni remote-endpoint. Nella maggior parte delle architetture media-controller, i formati immagine vengono negoziati a runtime tramite i formati dei pad dei sub-device, i media link e la negoziazione del routing. I binding effettivi e i formati supportati dipendono dal driver kernel del SoC utilizzato.

# Inspect entities, pads, and links
media-ctl -p -d /dev/media0

# Example: Configure the upstream sensor pad format
media-ctl -d /dev/media0 --set-v4l2 '"sensor 1-001a":0 [fmt:SRGGB10_1X10/1920x1080]'

# Example: Enable the link
media-ctl -d /dev/media0 --links '"sensor 1-001a":0 -> "csi2rx":0 [1]'

# Configure the capture node memory format and start streaming
v4l2-ctl -d /dev/videoX \
  --set-fmt-video=width=1920,height=1080,pixelformat=RG10 \
  --stream-mmap=4 --stream-count=100

dmesg -w

I nomi delle entità, gli indici dei pad, i codici media-bus, i valori FourCC e i nodi video mostrati nell'esempio devono essere adattati al media graph effettivo e non sono uniformi tra le diverse piattaforme.

Compatibilità e analisi degli errori

• Se la comunicazione I²C funziona ma non viene ricevuta alcuna immagine, verificare alimentazione/reset/MCLK, stato stream-on del sensore, data-lanes, mappatura delle lane, frequenza di link, media graph e stato del CSI RX.
• Se viene rilevata attività sui frame ma si verificano errori ECC/CRC, controllare i contatori di errore RX, la mappatura delle lane, il link rate, HS-Settle, l'integrità del segnale a livello di scheda e la configurazione TX/RX.
• Se i frame vengono acquisiti ma i colori sono errati, verificare profondità RAW, ordine Bayer, codice media-bus, FourCC della memoria e pipeline ISP.

Domande frequenti

Hai bisogno di supporto per il tuo progetto di visione embedded?

FIRST Components supporta OEM e system integrator nella valutazione di piattaforme embedded e tecnologie display, contribuendo a soddisfare i requisiti di interfaccia, integrazione e applicazione.