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.
Der ganze Userspace-Kram ist einfach. Da nimmt man FFmpeg oder GStreamer und stellt sich eine Kommandozeile zusammen, die das Video ins Netzwerk pustet. Das schwierige ist einen Treiber für den Sensor zu schreiben, wenn es, wie du gesagt hast, ein neuer Sensor ist. Um zu entscheiden wie schwer das ist, schau dir am besten existierende Treiber an, z.B. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/media/i2c/imx214.c oder https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/media/i2c/ov5647.c Das ausführliche Datenblatt des Sensors mit der Beschreibung der Register zu haben, ist dafür Voraussetzung. Beim RasPi wirst du den bcm2835-unicam Treiber brauchen, der hier diskutiert wird: https://www.mail-archive.com/linux-media@vger.kernel.org/msg119399.html Mit dem anderen CSI-Treiber, der den Großteil der Arbeit dem VC4 überlässt, kann man keine Kameras einbinden, die die VC4-Firmware nicht schon kennt.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.