Hallo zusammen,
ich bin auf der Suche nach einer variablen Plattform - variabel im Sinne
des zu verwendenden Kamera Moduls.
Es gibt ja prinzipiell zwei verschiedene Ansätze:
- Hardwarelösungen mittels FPGA/SOC
- Software lastige Lösungen mit fertigen embedded Plattformen
Die FPGA Lösungen habe ich entsprechend analysiert und bewertet und
möchte mich nun etwas in der Softwarelastigen Lösung vertiefen.
Viele Plattformen (RPI, NV Jetson TX1/2, Qualcomm) bieten ja eine
fertige MIPI Implementierung an. Man kann also nativ MIPI Module
anschließen, aber dann beginnt die Arbeit am Treiber.
Bis auf ein paar Grundkenntnisse in Linux und Python habe ich keine
tiefgreifende Erfahrung auf dem Gebiet Linux/V4L/Treiber und möchte nun
den Aufwand abschätzen, ob es lohnt sich damit auseinanderzusetzen.
Nehmen wir den RPI als Basis mit seinen zwei MIPI Lanes.
Dort gibt es ja fertige Linux Images incl. Treiber für die
unterschiedlichsten Module.
Wie kompliziert ist es, auf Basis dieser existierenden Treiber, einen
neuen Sensor einzubinden?
Das bedeutet ja die Konfiguration des Sensors mittels I2C und dann die
Implementierung der Sensor Funktionen (Integration, usw.) und das
Handling der Bilddaten die reinkommen, so dass sie von einem externen PC
Interface zugänglich sind. Der RPI dient dann nur als "Kamera-Hardware"
und die Bilddaten werden via USB oder LAN zum PC gesendet. Auch hier
gibt es zahlreiche Applikationen, auf denen man aufsetzen könnte.
Die Daten zum LAN/USB zu bekommen ist hoffe ich machbar, wenn man die
V4L Schnittstelle verwendet und ein fertiges Modul hernimmt?!
Nvidia Jetson TX1/2 incl. J100 Carrier Board stelle ich mir dann analog
zum RPI vor. Wenn man also den RPI mit frischen Sensoren behandeln kann,
sollte das auf Jetson auch machbar sein - nur dann mit zwei Kameras und
wesentlich performanter.
Könnte man grob vorab die Arbeitspakete umreißen, was genau zu tun ist,
so dass ich dann mit diesen Stichworten weiter recherchieren kann, um
die Aufwände abzuschätzen?
Braucht man wirklich jahrelange C/C++ Erfahrung, um einen Treiber zu
schreiben, oder gibt es alles im Netz und die Kunst ist nur es korrekt
zusammenzukopieren und anzupassen?
Vielen Dank!
Das hängt sehr von den Anforderungen ab. Wenn du einen bekannten Sensor
mit üblichem Format hast, ein vordefiniertes Protokoll verwenden kannst
und einen Treiber hast, dann ist das wirklich rasch zusammengefügt. Die
Datentransportierung durchs Linux in die Applikationsebene ist mehr oder
weniger gelöst. Oft muss da überhaupt nichts gemacht werden.
Hat der Sensor oder die Quelle ein spezielles Format oder Timing, muss
ein Treiber her. Also Treiber klauen, modifizieren und im Linux bekannt
machen. Schwierig wird es bei erhöhten Bandbreiten. Da kommt schnell die
Frage auf, ob eine embedded Linux oder eine abgespeckte und angepasste
Desktopversion läuft. Bei einer Ubuntu, wie wir das machen, auf der noch
einiges anderes läuft, muss gfs der Kernel angepasst werden.
Spätestens bei Sonderanforderungen, wie Codierungen oder Markierungen im
Bild oder eigenen Kompressionsformaten lässt sich nicht alles im Treiber
oder der Anwendungsebene machen.
Kritisch wird es bei Anpassungen an die eigene Hardware. Da gibt es eine
Reihe von Einstell-optionen, in denen man sich verlieren kann, um den
JETSON in die eigene Umgebung anzupassen.
Bench schrieb:> Braucht man wirklich jahrelange C/C++ Erfahrung, um einen Treiber zu> schreiben, oder gibt es alles im Netz und die Kunst ist nur es korrekt> zusammenzukopieren und anzupassen?
Nein, eigentlich brauchst du nur Erfahrung oder Intuition beim Debuggen
der Probleme, die typischerweise auftauchen.
Wenn du die i2c-R/W-Transaktionen erst mal im User-Space prototypen
kannst (d.h. das board-supply-package die Kommunikationsschicht und
device tree hergibt), ist das nur noch Fleissarbeit, um einen Treiber
fuer v4l2 (Video for Linux 2) zu portieren. Um eine Kamera zu bauen, ist
das aber nicht zwingend noetig, da viele v4l2-ioctl()-Parameter nur
bedingt umsetzbar sind.
Die eigentliche Bilderfassung sollte typischerweise ueber den
MIPI-CSI-Teil des v4l2-Treibers abgehakt sein. Sollte. Da gibt es eine
Menge Parameter, die die MIPI-Timings betreffen, und da kann bei manchen
Sensoren auch viel schiefgehen, die Pakete kommen stotternd rein und der
CSI versteht sie nicht richtig, oder das highspeed-lowspeed-Umschalten
tut nicht sauber.
Wenn du also einen neuen Sensor implementieren willst: Schau, dass du
eine funktionierende Referenz hast (Parameter, oder bereits
existierender Code).
Die Crux an den MIPI-Kram ist die typischerweise fehlende bis nicht
verfuegbare Dokumentation, auch mit NDA kriegt man teils nicht alles.
Und MIPI ist elektrisch sehr schwer zu debuggen, d.h. das
Reverse-Engineering aufwendiger als beim Parallel-Video.
Streaming per LAN ist dann im user space per gstreamer abgehakt, bei USB
wird es kniffliger, USB unter Linux im Slave-Betrieb ist teils recht
zeitkritisch und ein groesserer Softwareaufwand als ein einfaches System
mit FPGA und/oder USB-Soc wie FX3.
Daniel schrieb:> Das schwierige ist einen Treiber für den Sensor zu schreiben, wenn es,> wie du gesagt hast, ein neuer Sensor ist.
Das ist eigentlich nicht die Kunst, da immer das gleiche. Sensor via I2C
initialisieren, MIPI Daten buffern, Bilddaten verarbeiten. Da
unterscheidet sich der neue Treiber nur minimal von existierenden
Implementierungen. Die Hauptarbeit uebernimmt da der MIPI PHY im MCU, da
kommt man mit MIPI und den damit verbunden "Eigenheiten" in der Regel
garnicht mit in Beruehrung.
Das groesste Problem ist immer an die Startup Sequenz des Sensors zu
kommen. Da ruecken die Herstelle nur das noetigste an Informationen
heraus und entsprechend bekommt man auch keine Datenblaetter wenn man
nicht wirklich Stueckzahlen hat.
