Hallo, wir sind auf der Suche nach einer "einfachen und günstigen" Möglichkeit einen CMOS-Kamerastream zu kodieren. Eine Kamera mit Parallelinterface oder MIPI-CSI-Interface soll zum Einsatz kommen (RAW oder RGB etc. noch unklar; Hersteller: Omnivision, Onsemi, Framos etc.). Dieser Kamerastream, 1080p und 30fps, soll mittels Mikrocontroller über eine 100 Mbit Ethernet-Leitung gesendet werden. Auf den Mikrocontroller möchten wir zunächst nicht verzichten da dieser noch andere Aufgaben erledigt. Ein FPGA wäre jetzt u.a. interessant, weil er zusätzlich noch die Schnittstellenwandlung (MIPI-CSI) übernehmen könnte. Die Schnittstelle zwischen FPGA und Mikrocontroller könnte dann z.B. SPI sein. Ein FPGA wird aber für uns schnell uninteressant, wenn man über 45k€ für einen H.264-I IP core zahlen muss. Es muss dazu noch gesagt werden, dass wir zwar unerfahren mit dem Umgang von FPGAs sind aber wir hätten die Zeit uns damit tiefergehend (2 Jahre+) zu beschäftigen. Welche Lösungen gäbe es denn noch einen Kamerastream zu kodieren? Möglichst Lösungen mit gut erhältlichen Chips von namhaften Herstellern, da dieser später auf einem eigenen Design bestückt werden soll. CMOS Kamerachips die selbst schon JPEG kodieren sind auch eher uninteressant, da es zu wenige davon gibt. Meine Frage ist bewusst im FPGA Bereich, da es bestimmt noch andere Lösungen als H.264 gibt. Danke. Ralf
Es gibt von Xilinx in der Zynq Ultrascale+ Familie FPGAs mit einem Hardware H.264 Encoder. Die Chips sind allerdings nicht ganz billig und lohtn sich eigentlich nur wenn du dein komplettes System in den FPGA packst. Der hat auch genug CPU Power dank vierer ARM Kerne. Was fuer Hardewarekosten pro Unit schweben dir denn vor? Das schraenkt dann die Auswahl wahrscheinlich am schnellsten ein. ;-)
:
Bearbeitet durch User
Ralf schrieb: > Welche Lösungen gäbe es denn noch einen Kamerastream zu kodieren? Nimm so einen potenten "µC" wie den i.MX8. In der Hardware ist der sicher billiger als die FPGA-Lösung und hat soweit alles drin. Inklusive des aktuell verwendeten µC... ;-) https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-8-processors/i-mx-8m-plus-arm-cortex-a53-machine-learning-vision-multimedia-and-industrial-iot:IMX8MPLUS https://www.digikey.de/product-detail/de/nxp-usa-inc/8MMINILPD4-EVK/568-15279-ND/9857774
:
Bearbeitet durch Moderator
Die Kosten kann ich ehrlich gesagt noch gar nicht so genau beziffern. Blöd gesagt, es wird nachher so teuer wie es teuer wird. Ich denke, was ich definitiv sagen kann ist, dass ein FPGA-System samt Entwicklungszeit zu teuer wird. Wir dachten da eher an einen kleinen low-cost FPGA, den man bespielt und fertig ist die Schnittstellenwandlung und Videokodierung - salopp gesagt. In dieser Größenordnung kann man sich ja dann schon nach z.B. einem i.MX6 oder i.MX8 umsehen. Die haben ja auch schon HW codec und MIPI-CSI Schnittstellen und PCIe und und und. Aber der Nachteil für uns wäre dann zusätzlich, dass man ein OS wie Linux benötig.
Da wir keine Erfahrung mit FPGAs haben, kann ich schlecht die Kosten abschätzen bzw. nachher das Pro und Contra. Mal angenommen man würde versuchen die Kodierung in einem preisgünstigen FPGA (<10€) zu machen. Für mein System bräuchte ich folgende Funktionen in dem FPGA realisiert: 1. Wandlung von MIPI-CSI zu Parallelport 2. Umschaltung zwischen Kamera mit MIPI-Interface oder Parallel-Interface 3. Videokodierung (MJPEG oder MPEG-2 oder MPEG-4 AVC) 4. Controller für DDR (evtl. in 3. untergebracht) 5. SPI Schnittstelle zwischen FPGA und µC Dazu habe ich noch ein paar Fragen und Fragen genereller Natur: I. Auch wenn man das Geld für die IP cores zur Verfügung hätte, bliebe ja trotzdem noch die Aufgabe diese Module miteinander zu verheiraten. Wie seht ihr da den Aufwand für einen FPGA-Anfänger? Oder kann man das mehr oder weniger in den FPGA IDEs "zusammenklicken" :| ? Wie gesagt, ich habe keine Vorstellung... II. Es gibt ja auch kostenlose IP-cores. Wie findet man diese, insbesondere auf den FPGA Herstellerseiten? Ich nehme mal an, dass die Programmierung um einiges schneller ist, wenn IP cores verwendet werden. Wenn man sich jetzt für den ein oder anderen Hersteller entscheiden muss, dann nimmt man vielleicht auch denjenigen, der viele kostenlose IP-cores anbietet. Wie blickt man da durch? III. Habe ich das richtig verstanden, IP cores kauft man nur, wenn man angesichts kurzer Entwicklungszeit keine Möglichkeit hat die benötigten Funktionen selbst zu schreiben ? SPI werden bestimmt noch einige hinbekommen. Aber bei H.264 bleibt den meisten dann nichts anderes übrig als 40k€ zu zahlen? IV. Oder einfach nochmal anders gefragt. Wo liegt man preislich (ungefähre Hausnummer) wenn man 1 bis 5 umsetzen wollte, ohne Stunden? - IDE - IP-cores - sonstiges
Hi Ralf, betr. MJPEG-Streaming-SoCs im FPGA und MIPI kann ich prinzipiell helfen: https://section5.ch/index.php/documentation/jpeg-encoder-ip-modules-developer/ Gibt fertige 2-Chip (FPGA/Phy) Refdesigns fuer die ueblichen Lattice-Plattformen (EVDK, HDR60). Wird aber eng mit guter Qualitaet bei 1080p@30fps ueber 100Mbit.. Macht auf dem FPGA auch nur unter gewissen Randbedingungen Sinn, wenn's kleine Stueckzahlen sind, kopiert man sich besser eins der oben erwaehnten imx8-Setups. Da darf man sich allerdings dann mit Linux-Treibermodellen und dem nicht sonderlich eleganten v4l2-Konzept herumschlagen, oder macht 'bare metal', was aehnlich viel Aufwand wie auf dem FPGA macht. Einiges an den MIPI-Interfaces ist un- oder schlecht dokumentiert und auf dem FPGA deutlich leichter zu debuggen. Es gibt sonst fuer h.264 den hardh264-Encoder, der fuer gewisse Sachen auch ganz brauchbar ist. Der Implementations-Aufwand ist aber deutlich groesser, und mit 45k EK kommst du da nicht weit. Wenn du h.264, aber keine low-latency brauchst, guck' dich mal bei den imx6 VPU-Loesungen um, da sollte es in der offiziellen gstreamer-Source was geben.
:
Bearbeitet durch User
Ralf schrieb: > Die Kosten kann ich ehrlich gesagt noch gar nicht so genau beziffern. > Blöd gesagt, es wird nachher so teuer wie es teuer wird. Ich denke, was > ich definitiv sagen kann ist, dass ein FPGA-System samt Entwicklungszeit > zu teuer wird. Wir dachten da eher an einen kleinen low-cost FPGA, den > man bespielt und fertig ist die Schnittstellenwandlung und > Videokodierung - salopp gesagt. Ja, da liegst du mit deiner Einschaetzung nicht ganz falsch. Die Flagschiff FPGA Loesung lohnt sich halt nur, wenn die Stueckzaheln so gross sind, dass die FPGA Preise einigermassen ertraeglich sind und die Entwicklungskosten dann im Rauschen untergehen. Ausserdem amcht es nur Sinn wenn man sein komlpettes System in den FPGA packt, ohne zusaetzliche Controller Anbindung. Aber wie Lothar (und Martin) schon schrieb, es gibt echt tolle Prozessoren auf dem Markt die MIPI faehig sind und die Kodierung auch beherrschen. Das ist preislich sicherlich interessanter. Sogar der Raspberry Pi kann schon MIPI, ich weiss nur nicht ob der auch einen Hardware Encoder hat oder nur einen Dekoder. Sollte es nur um MIPI gehen und die Video Enkodierung wird ausgelagert, dann sind die Crosslinks von Lattice ein toller lowcost FPGA. Ralf schrieb: > In dieser Größenordnung kann man sich ja dann schon nach z.B. einem > i.MX6 oder i.MX8 umsehen. Die haben ja auch schon HW codec und MIPI-CSI > Schnittstellen und PCIe und und und. Aber der Nachteil für uns wäre dann > zusätzlich, dass man ein OS wie Linux benötig. Ich weiss nicht ob eine OS Schicht mit Linux hier wirklich ein Nachteil ist. Die kannst halt fertige Bibliotheken nutzen, damit ist die Entwicklungszeit kaum mehr zu druecken.
:
Bearbeitet durch User
Ralf schrieb: > Ich denke, was > ich definitiv sagen kann ist, dass ein FPGA-System samt Entwicklungszeit > zu teuer wird. Wenn du es selber machst ja. Aber es gibt ja Leute, die das schon gemacht haben und daheim herumliegen haben. Einen MPG-Dekoder muss man auch nicht nehmen, wenn man nur das Format komprimieren will. Muss es denn ein Video-format sein? Wir nehmen einen ZIP-ähnliche Kompression. Tobias B. schrieb: > Die kannst halt fertige Bibliotheken nutzen, damit ist die > Entwicklungszeit kaum mehr zu druecken. Wenn man ins Linux eingearbeitet ist, ja. Aber auch das ist ein großer overhead. Eine Sensordatenanbindung hat man in Tagen programmiert und den Decoder reingeworfen. Es gibt schließlich auch solche zum Einkaufen. Für 30fps braucht es auch keine große Bandbreite. Woher kommt denn dein Horrorpreis von 45k?
Tobias N. schrieb: > Wenn man ins Linux eingearbeitet ist, ja. Aber auch das ist ein großer > overhead. Das stimmt allerdings auch wieder. Wenn ich aber davon ausgehen wuerde er kennt sich in beiden Welten nicht aus und wuerde die Dienstleistung einkaufen, dann wuerde die Linux Variante im Preis wahrscheinlich gewinnen. Kosten und Zeit sind ja faktisch in fixer Relation zueinander Vielleicht koennen wir Ralf ja noch ein bisschen aus der Reserve locken und herausfinden was er vor hat. Vielleicht finden wir dann eine ideale Loesung. :-)
Dank für eure Antworten, hilft schon etwas weiter. Bevor wir auf eine komplette FPGA Lösung gehen, wären iMX6 deutlich interessanter. Ein System aus FPGA und µC wäre ein schöner Kompromiss gewesen. Dafür müsste man eben noch den Aufwand und Kosten abschätzen können. Tobias B. schrieb: > Sollte es nur um MIPI gehen und die Video Enkodierung wird ausgelagert, > dann sind die Crosslinks von Lattice ein toller lowcost FPGA. Wir haben noch ein, zwei andere Lösungen gefunden, wenn es nur um MIPI geht. TI und Maxim haben IC um MIPI zu LVDS und LVDS zu Parallel wandeln. Und es gibt noch ein IC von ST Micro, das eine direkte Umwandlung von MIPI zu Parallel kann. Wenn FPGA dann, dann sollte er auch noch die Videokodieren machen. Tobias B. schrieb: > Ich weiss nicht ob eine OS Schicht mit Linux hier wirklich ein Nachteil > ist. Die kannst halt fertige Bibliotheken nutzen, damit ist die > Entwicklungszeit kaum mehr zu druecken. Das Ziel ist es eine Lösung ohne Linux zu finden. Wenn es diese nicht gibt, ohne hohe Kosten (FPGA), dann muss es sicherlich ein iMX6 o.ä. mit all seinen VOR- und Nachteilen sein. Tobias N. schrieb: > Einen MPG-Dekoder muss man > auch nicht nehmen, wenn man nur das Format komprimieren will. Muss es > denn ein Video-format sein? > > Wir nehmen einen ZIP-ähnliche Kompression. Kannst du das bitte etwas näher erläutern? Wir sind da noch nicht wirklich festgelegt. Hauptsache die Auflösung wird nicht verändert und die optische Qualität bleibt in vernünftigen Grenzen. Welchen Kompressionsfaktor erreicht ihr mit der ZIP-ähnlichen Kompression? Auf welchem System läuft diese? Gibt es da eine bessere Bezeichnung als "ZIP-ähnliche Kompression". Tobias N. schrieb: > Eine Sensordatenanbindung hat man in Tagen programmiert und den Decoder > reingeworfen. Es gibt schließlich auch solche zum Einkaufen. Für 30fps > braucht es auch keine große Bandbreite. Woher kommt denn dein > Horrorpreis von 45k? Das war ein Angebot von Visengi für Zynq UltraScale+ H264E-I Netzliste: 45k€ H264E-P Netzliste: 60k€ Martin S. schrieb: > Es gibt sonst fuer h.264 den hardh264-Encoder, der fuer gewisse Sachen > auch ganz brauchbar ist. Der Implementations-Aufwand ist aber deutlich > groesser, und mit 45k EK kommst du da nicht weit. Wenn man jetzt den hardh264 nehmen könnte, dann weiß ich immer noch nicht was da noch so an Kosten auf einen zukommt.
Ralf schrieb: > Für mein System bräuchte ich folgende Funktionen[...] > in dem FPGA realisiert: > 1. Wandlung von MIPI-CSI zu Parallelport > 2. Umschaltung zwischen Kamera mit MIPI-Interface oder > Parallel-Interface > 3. Videokodierung (MJPEG oder MPEG-2 oder MPEG-4 AVC) > 4. Controller für DDR (evtl. in 3. untergebracht) > 5. SPI Schnittstelle zwischen FPGA und µC 1. würde ich heutzutage in die andere Richtung machen. Also Parallelport zu MIPI-CSI. Vielleicht sogar direkt beim Sensorchip, dann sind die Kameraköpfe austauschbar. Ob man dazu einen FPGA braucht oder ob es dazu ASSP ICs müsste jemand recherchieren. Wie schon empfohlen wurde die Punkt 3 bis 6 (6 ist Streamen über Ethernet) würde ich auch eher auf einem Mikroprozessor sehen. Encodieren wohl über eine GPU beschleunigt (da meistens in Hardware nur ein Decoder verfügbar ist). Bei Mikroprozessoren bekommt man heute so extrem viel Leistung und Features für fast kein Geld. Kurz: Nimm ein Raspberry Pi Compute Module :-) https://stackoverflow.com/a/50854229 Martin S. schrieb: > Wird aber eng mit guter Qualitaet bei 1080p@30fps ueber 100Mbit.. Ja, wir haben bisher keine Angaben zur geforderten Qualität. 1080p@30fps macht mein Smartphone (Xperia Z3C) von 2014 mit 8000kbit/s via WLAN. Braucht dann aber mehr Strom als vom Ladegerät kommt :-) Tobias B. schrieb: > Ja, da liegst du mit deiner Einschaetzung nicht ganz falsch. Die > Flagschiff FPGA Loesung lohnt sich halt nur, wenn die Stueckzaheln so > gross sind, dass die FPGA Preise einigermassen ertraeglich sind und die > Entwicklungskosten dann im Rauschen untergehen. Oder du nicht darum herum kommst weil z. B.: - low-latency gefragt ist - viele parallele Kameras synchron und aufeinander kalibriert laufen sollen - Es strahlungsfest (Weltraum) sein soll - (mir gehen die Ideen aus...)
Christoph Z. schrieb: > Kurz: Nimm ein Raspberry Pi Compute Module :-) > https://stackoverflow.com/a/50854229 Geht nicht, darf ja kein Linux sein. :-( Christoph Z. schrieb: > Oder du nicht darum herum kommst weil z. B.: > - low-latency gefragt ist > - viele parallele Kameras synchron und aufeinander kalibriert laufen > sollen > - Es strahlungsfest (Weltraum) sein soll > - (mir gehen die Ideen aus...) Das beisst sich wieder mit den lowcost Anforderungen, daher gehe ich mal stark davon aus, dass keiner dieser Punkte zutrifft. Andernfalls haette man wohl andere Kostenvorstellungen. ;-) Ralf schrieb: > Das Ziel ist es eine Lösung ohne Linux zu finden. Wenn es diese nicht > gibt, ohne hohe Kosten (FPGA), dann muss es sicherlich ein iMX6 o.ä. mit > all seinen VOR- und Nachteilen sein. Duerfte ich da mal nachhaken, warum Linux ausgeschlossen ist? Dadurch verbaust du dir halt enorm viele Moeglichkeiten, vor allem im unteren Preissegment. Ich habe keine Ahnung von den iMXen, bekommt man da wirklich Video Encoding und Streaming ohne eine OS Schicht hin? Das kann ich mir fast nicht vorstellen, wuerde mich aber freuen wenn ich mich da irre. :-)
Auch wenn ich solche stumpfen Gegenfragen eigentlich selbst hasse: Warum wollt ihr das quasi "koste es was es wolle" selbst machen? Es gibt ja durchaus Firmen wie IDS Imaging, die genau sowas schon sehr lange und recht gut machen und neben ihrem Baukasten auch Sonderentwicklungen anbieten, falls man da wirklich nichts passendes findet. https://de.ids-imaging.com/customised-cameras.html https://de.ids-imaging.com/store/products/cameras/ids-interface-group/ethernet/sort-by/position/sort-direction/desc.html Meiner Erfahrung nach lohnt es, sich auf das zu konzentrieren, was man wirklich selbst einschätzen und erledigen kann und andere komplexe Aufgaben an spezialisierte Firmen zu vergeben bzw. sich eine fertige Lösung rauszupicken und ggf. seine eigene Hardware darauf anzupassen.
Tobias B. schrieb: > Geht nicht, darf ja kein Linux sein. :-( Dann nimmt er halt Android, ist ja kein "richtiges" Linux oder Windows 10 IoT core ;-) (JA, das soll ein schlechter Witz sein...) Na gut, dann halt mal weitergucken. Vielleicht kann QNX da was anbieten, wird ja in genug Krempel im Auto eingesetzt wo auch Kameras drinstecken und billig sein muss.
Tobias B. schrieb: > Christoph Z. schrieb: >> Oder du nicht darum herum kommst weil z. B.: >> - low-latency gefragt ist >> - viele parallele Kameras synchron und aufeinander kalibriert laufen >> sollen >> - Es strahlungsfest (Weltraum) sein soll >> - (mir gehen die Ideen aus...) > > Das beisst sich wieder mit den lowcost Anforderungen, daher gehe ich mal > stark davon aus, dass keiner dieser Punkte zutrifft. Andernfalls haette > man wohl andere Kostenvorstellungen. ;-) Stimmt Tobias B.! Keine geringe Latenz und nur eine Kamera pro Modul. Sorry mein Fehler. Tobias B. schrieb: > Duerfte ich da mal nachhaken, warum Linux ausgeschlossen ist? Dadurch > verbaust du dir halt enorm viele Moeglichkeiten, vor allem im unteren > Preissegment. Es geht um Zertifizierung. Je weniger Codezeilen desto besser. Tobias B. schrieb: > Ich habe keine Ahnung von den iMXen, bekommt man da wirklich Video > Encoding und Streaming ohne eine OS Schicht hin? Das kann ich mir fast > nicht vorstellen, wuerde mich aber freuen wenn ich mich da irre. :-) Da habe ich mich falsch ausgedrückt. Auf so einem iMX läuft schon ein Linux. Wenn wir unser Vorhaben mit einfachen Mitteln nicht hinbekommen, dann muss es eben ein Gerät mit OS Schicht sein. Momentan ist es noch Recherche und abwägen..
Moin, Ralf schrieb: > Das Ziel ist es eine Lösung ohne Linux zu finden. Das hat aber schon was von: Ich muss einen Nagel in ein Brett schlagen, darf aber keinen Hammer nehmen. Es ist ja nicht nur die nackerte encodierung (ist da h264 schon fix gesetzt, haut das von Latency, Qualitaet, Lizenzgebuehren, ... hin?). Aus dem Encoder(IP-Core) faellt ein Elementarstrom raus. Der sollte aber noch irgendwie aufgehuebscht und verpackelt werden (z.b. RTSP, RTMP, MPEGTS, DASH, ...) damit der "schoen" uebers Ethernet geht... Gruss WK
Christoph Z. schrieb: > Tobias B. schrieb: >> Geht nicht, darf ja kein Linux sein. :-( > > Dann nimmt er halt Android, ist ja kein "richtiges" Linux oder Windows > 10 IoT core ;-) (JA, das soll ein schlechter Witz sein...) > > Na gut, dann halt mal weitergucken. Vielleicht kann QNX da was anbieten, > wird ja in genug Krempel im Auto eingesetzt wo auch Kameras drinstecken > und billig sein muss. Und ploetzlich wird durch das Stichwort "Zertifizierung" aus dem Witz vll. der Schluessel zur Loesung. :-D Ralf schrieb: > Es geht um Zertifizierung. Je weniger Codezeilen desto besser. Um welche Zertifizierung handelt es sich denn. Ich kenne mich leider nur im Medizin Bereich aus, aber hier im Forum gibt es zu eigentlich jedem Bereich jemanden der dir da weiterhelfen kann. Wenn du das noch preisgibst, bin ich mir ziemlich sicher, dass da eine vernuenftige Loesung gefunden wird. :-)
> > Wenn man jetzt den hardh264 nehmen könnte, dann weiß ich immer noch > nicht was da noch so an Kosten auf einen zukommt. Ohne Erfahrung und gemachtes Nest baust du da ev. erst mal ein Jahr das Nest auf, bis die Sache laeuft, je nachdem ob ihr besser Software oder Hardware koennt. Auf was wollt ihr Euch fokussieren/was ist das eigentliche Ziel? Zu einer fertigen Streaming-Loesung mit VLC/gstreamer laesst sich schon eine Hausnummer hinschreiben (sowohl MJPEG auch hardh264, erstere ist niedriger). Muss allerdings noch mehr Fleisch an den Knochen (Typ Sensor, Latenzanforderungen, Simulationsmodell ja/nein, ...). Die niedrigsten EK bietet sonst halt nur die embedded-Linux-Loesung. Die letzte Option, naemlich eine bestehende Industriekamera fuer seine Anwendung zu 'hacken' ist auch noch offen. Zur MIPI-Thematik solltet ihr euch auf jeden Fall sehr frueh Gedanken machen, bzw. den Sensor gut aussuchen. Die Hersteller der entsprechenden Sensoren verhalten sich da typischerweise verschlossen, und wenn's mal mit dem Timing hakt, ist man ewig am reverse-engineeren (und das nur mit Crosslink/LIFMD wirklich effektiv). Regel Nr. 4: Den LIFMD im ersten Design niemals einsparen :-)
Tobias B. schrieb: > Und ploetzlich wird durch das Stichwort "Zertifizierung" aus dem Witz > vll. der Schluessel zur Loesung. :-D "Witz"? Schön zu wissen, dass du mein Anliegen gleich als Witz abgetan hast. Seh' das jetzt mal nicht so genau. Wenn möglich kein Linux, wenn nicht, dann eben nicht. Gut, ich dachte man könnte einen kleinen FPGA (RAM etc.) rein nur für die Videokompression und Schnittstellenwandlung nehmen. Die Kosten für FPGA Tools und IP cores sind zu hoch. Bis auf die eine genannte Zahl von Martin S. konnte ich keine grobe Hausnummer genannt bekommen. Es wird dann wohl mindestens im 45k Bereich liegen. Und natürlich noch höher, wenn man man auf nicht-freie IP cores zurückgreifen muss. Martin S. schrieb: > Ohne Erfahrung und gemachtes Nest baust du da ev. erst mal ein Jahr das > Nest auf, bis die Sache laeuft, je nachdem ob ihr besser Software oder > Hardware koennt. Auf was wollt ihr Euch fokussieren/was ist das > eigentliche Ziel? Die Erfahrung ist bis auf ein FPGA Praktikum ziemlich Null. Ziel: recherchieren ob folgendes geht: Ein µC basiertes System mit FPGA als Kamerainterface und Kodierung. Streaming über 100 Mbit Ethernet. Max 1080p @ 30fps (20fps vielleicht auch ok). Keine besonderen Latenzanforderungen. Qualität: so, dass wenn man auf den Bildschirm schaut, man nicht denkt es wäre 1990. Wie gesagt, Zeit für FPGA Einarbeitung ist theoretisch da. Martin S. schrieb: > Zur MIPI-Thematik solltet ihr euch auf jeden Fall sehr frueh Gedanken > machen, bzw. den Sensor gut aussuchen. Die Hersteller der entsprechenden > Sensoren verhalten sich da typischerweise verschlossen, und wenn's mal > mit dem Timing hakt, ist man ewig am reverse-engineeren (und das nur mit > Crosslink/LIFMD wirklich effektiv). Regel Nr. 4: Den LIFMD im ersten > Design niemals einsparen :-) Danke für den Tipp!
Ralf schrieb: > Tobias B. schrieb: >> Und ploetzlich wird durch das Stichwort "Zertifizierung" aus dem Witz >> vll. der Schluessel zur Loesung. :-D > > "Witz"? Schön zu wissen, dass du mein Anliegen gleich als Witz abgetan > hast. Seh' das jetzt mal nicht so genau. Wenn möglich kein Linux, wenn > nicht, dann eben nicht. Bitte richtig lesen und zitieren, das empfinde ich jetzt doch als beleidigend mir gegenueber und ich wuesste jetzt nicht warum das sein muss? :-/ Der Witz war auf Christophs Beitrag bezogen, der seine Aussage selbst als Witz gekennzeichnet hat. Und da es hier um Zertifizierung geht, hat er nicht nur einen Witz gerissen, sondern evtl. sogar ins Schwarze getroffen. Das konnte er zum Zeitpunkt seines Posts noch nicht wissen.
:
Bearbeitet durch User
Oh ja Tobias B., da hab ich zu schnell gelesen und falsch reagiert. Entschuldige bitte!
Ralf schrieb: > Oh ja Tobias B., da hab ich zu schnell gelesen und falsch reagiert. > Entschuldige bitte! Vergeben und vergessen. Magst du uns vielleicht trotzdem noch mitteilen um was fuer eine Zertifizierung es geht? Diese Info koennte vll. wirklich das fehlende Puzzleteil sein. Ich bin mir sicher da findet sich jemand hier im Forum der wirklich aus erster Hand berichten kann, weil er die gleiche Zertifizierung / Zulassung schonmal mitgemacht hat.
Tobias B. schrieb: > Der Witz war auf Christophs Beitrag bezogen, der seine Aussage selbst > als Witz gekennzeichnet hat. Und da es hier um Zertifizierung geht, hat > er nicht nur einen Witz gerissen, sondern evtl. sogar ins Schwarze > getroffen. Wieso, das Wort Zertifizierung und Android bzw. Windows in einem Satz, macht doch den Witz noch besser :-) Darum auch der ernst gemeinte Hinweis auf QNX. Da weiss ich, dass die Multimedia können. VXworks, Integrity, PikeOS sind nach meinem Wissen nicht gedacht auf GPUs Video zu encodieren, dicke GUIs anzuzeigen oder ähnliches. Ralf schrieb: > Es geht um Zertifizierung. Je weniger Codezeilen desto besser. Jaja, aber dann Video Kompression und Ethernet mit TCP/IP wollen... Lass mich raten, in deiner Branche gelten FPGA Designs immer noch als Hardware und darum als sicher. Fragen und Diskussionen in diese Richtung hatten wir hier schon ein paar mal. Das letzte mal z. B. hier auch mit Blick auf die nötige Arbeit zur Zulassung vom eingesetzen RTOS: Beitrag "Re: Xilinx Zynq 7000: IEC 62304 + OS"
By the way: (wir bauen Kameras) es gibt auch IP-Core-Anbieter die zu den fertigen eval kits Module und Encoder als Netzliste kostenlos anbieten. Die laufen dann ein paar Stunden, dann man muß das System reseten. Für proof of concept reicht das. Mir bekannte Anbieter sind u.a. auch Visengi oder Helion Vision. Man muß einfach nur mal anfragen und vielleicht NDA unterzeichen. Und Zertifizierung kostet mehr als ein JPEG codec!
Tobias B. schrieb: > Vergeben und vergessen. Puh, da bin ich aber froh :) Tobias B. schrieb: > Magst du uns vielleicht trotzdem noch mitteilen um was fuer eine > Zertifizierung es geht? Diese Info koennte vll. wirklich das fehlende > Puzzleteil sein. Sorry aber ich glaube nicht. Wir stehen nicht kurz vor einer Zertifizierung und auch nicht in 5 Jahren. Es ist auch nicht so, dass Linux auf garkeinen Fall nicht geeignet wäre. Es geht erst mal nur um Prototypen. Momentan schreit alles einfach nach einem CPU-basierten System. Es ist aber dennoch nicht so, als wäre das generell nicht machbar: https://www.st.com/en/automotive-adas-devices/stv0991.html Aber nur als Automotive-Kunde. Christoph Z. schrieb: > Jaja, aber dann Video Kompression und Ethernet mit TCP/IP wollen... Hab ich nicht gesagt. Christoph Z. schrieb: > Lass mich raten, in deiner Branche gelten FPGA Designs immer noch als > Hardware und darum als sicher. Fragen und Diskussionen in diese Richtung > hatten wir hier schon ein paar mal. Nein. Videoman schrieb: > By the way: (wir bauen Kameras) es gibt auch IP-Core-Anbieter die zu den > fertigen eval kits Module und Encoder als Netzliste kostenlos anbieten. > Die laufen dann ein paar Stunden, dann man muß das System reseten. > Für proof of concept reicht das. Mir bekannte Anbieter sind u.a. auch > Visengi oder Helion Vision. Man muß einfach nur mal anfragen und > vielleicht NDA unterzeichen. Das war auch im Angebot von denen, 10k so rum. Videoman schrieb: > Und Zertifizierung kostet mehr als ein JPEG codec! Ja das denk ich doch auch. Trotzdem kann man doch mal links und rechts fragen. Und hier im Forum bekommt man sein erstes Gefühl ;)
Christoph Z. schrieb: > Lass mich raten, in deiner Branche gelten FPGA Designs immer noch als > Hardware und darum als sicher. Das wundert mich auch. Wo doch so ein FPGA-Design aus viele tausenden Codezeilen bestehen kann. Und was ein schlechter "Programmierer" aus einem FPGA machen kann, das sieht man hier allenthalben... ;-) Ich würde auf jedem Fall einem Komprimierer im i.MX8 locker die selbe Qualität zutrauen wie einem FPGA-Core. Ralf schrieb: > Es ist auch nicht so, dass Linux auf garkeinen Fall nicht geeignet wäre. Dann würde sich doch generell eine Einarbeit dort lohnen. Und es muss ja nicht mal Linux sein. > Aber nur als Automotive-Kunde. Das ist ein "Versatile imaging processor" und da steckt ein "ARM® Cortex-R4 CPU @500 MHz" dahinter. Der braucht auch Software. Und ich könnte mir gut vorstellen, dass da von Haus aus ein Linux drauf läuft: https://www.google.com/search?q=STV0991+linux
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.