Servus allerseits! Ich plane derzeit ein kleines Projekt und hänge leider bei einem "kleinen" Problem. Ich möchte gerne ein 18bit Signal, das via 36pin FFC normalerweiße in einen TFT geht, abfangen, umwandeln (am besten CAMIF) und als Input in einen Rock64 (ähnlich RPi) nutzen. Zu Info das Datasheet des Dispays: https://datasheetspdf.com/pdf-file/921629/Sharp/LQ070T5DR02/1 Hat jemand eine Idee? Lg Sebastian
:
Verschoben durch User
Sebastian N. schrieb: > normalerweiße ? Sebastian N. schrieb: > CAMIF Das ist ein französischer Versandhandel. Das wirst Du nicht meinen. Was für Schnittstellen hat denn Dein "Rock64", die Du für geeignet hältst?
Rufus Τ. F. schrieb: > Sebastian N. schrieb: >> normalerweiße > > ? Normalerweiße würde ein Display angeschlossen sein, dieser würde aber ersetzt werden. > Sebastian N. schrieb: >> CAMIF > > Das ist ein französischer Versandhandel. > > Das wirst Du nicht meinen. Was für Schnittstellen hat denn Dein > "Rock64", die Du für geeignet hältst? Die Grundidee war den Rock64 mit Android 8 zu betreiben und hier den camif driver zunutzen, also wird das Signal sozusagen als Kamera erkannt, ich lasse mir hier aber gerne von einer besseren Idee belehren. Beim Rock64 würde ein Pi-2 Bus ,ein Pi-P5+ Bus und natürlich USB3.0 zur verfügung stehen. Der Rock64 wäre in dem Fall auch kein Muss eigentlich, nur habe ich mich auf diesen schon etwas eingelesen.
:
Bearbeitet durch User
Sebastian N. schrieb: > Normalerweiße ?? Schreibst Du auch "Rieße", wenn Du das Gegenteil eines Zwergs meinst? Sebastian N. schrieb: > Beim Rock64 würde ein Pi-2 Bus ,ein Pi-P5+ Bus Die bitte was sein mögen? > mit Android 8 zu betreiben und hier den camif driver zunutzen Für welche Hardware ist dieser Treiber gedacht? Das muss passen, sonst wird das nichts. Aus der Ansteuerung Deines Displays kannst Du mit etwas Glück einen HDMI-Datenstrom machen, vorausgesetzt, daß das Timing, mit dem das Display von der ungenannten Hardware angesteuert wird, irgendwie sinnvoll ist. Um einen HDMI-Datenstrom in Deinen "Rock64" hineinzubekommen, braucht der eine dafür geeignete Schnittstelle. Es gibt USB-Devices, die einen HDMI-Datenstrom so komprimieren, daß man ihn über USB transportieren kann; "Elgato Camlink" wäre ein Kandidat dafür. Allerdings ist das mit Deinem eher sehr niedrigauflösenden Display (480x240) nicht nur kompletter Overkill, sondern auch bereits bei der Grundvoraussetzung --brauchbares Timing-- zum Scheitern verurteilt; es gibt AFAIK keine via HDMI transportierte so niedrige Auflösung. Mit sehr großem Aufwand könnte man natürlich einen Frameratekonverter konstruieren, der das Timing des Displays auf irgendeinen Videostandard (576i beispielsweise) hebt, aber spätestens da bleibt die Frage, ob der Aufwand in irgendeiner Relation zum Nutzen steht, sehr groß und laut im Raum stehen. Trotzdem: Dein Display wird mit 25 MHz Pixeltakt und 18 Bit RGB angesteuert, das sind also mindestens 56.5 MByte pro Sekunde (wenn man die Pixeldaten "packt", d.h. sie ohne Lücken in aufeinanderfolgende Bytes stopft, was an beiden Enden einigen Aufwand bedeutet), und effektiv 75 MByte pro Sekunde (wenn man für jeden R-, G- oder B-Wert ein komplettes Byte "verschwendet". So etwas transportiert man nicht mal eben über irgendwelche Ports, die z.B. ein Raspberry Pi hat. Was soll das ganze denn werden? Welches Problem willst Du lösen?
Häng eine Kamera an Deinen Kleinrechner und filme das Display ab. Dürfte die einfachste Lösung sein.
Hi Ich sehr da an dem SOC keine passende Schnittstelle. Das CAMIF scheint keinen passenden Modus zu kennen. Diverse iMX6 könnten das aber auch nur wenn alle Pins für RGB Capture zugänglich sind. Das ist aber eher selten der Fall denn typischerweise kommt ein externes Bildsignal gemultiplext über einen 8 Bit Bus. Matthias
Sebastian N. schrieb: > hänge leider bei einem "kleinen" Problem. Du schätzt die Größe dieses Problems falsch ein... Aber treten wir doch einfach mal einen Schritt zurück, und hinterfragen diese Aufgabenstellung: > Ich möchte gerne ein 18bit Signal, das via 36pin FFC normalerweiße in > einen TFT geht, abfangen, umwandeln (am besten CAMIF) und als Input in > einen Rock64 (ähnlich RPi) nutzen. Warum willst du das machen? Was passiert dann im Rock64 mit diesem Bild? Wird da dann einfach mir zusätzlich was eingeblendet? Oder läuft da eine OCR, die die eingelesenen Texte wieder entschlüsselnlt? Was ist denn die Aufgabe des Gesamtsystems? Gibt es eine einfachere Schnittstelle, um an die gewünschte Information zu kommen, als diesen LCD-Port?
Sebastian N. schrieb: > Hat jemand eine Idee? Das Ding hat doch schon fast ein CAMeraInterFace, Pixelclock und je 6 bit RGB parallel. Die Frage ist, ob dein Mikrosteinchen Daten mit solcher Datenrate annehmen kann. Mindestens DMA in den Speicher, und dann pro Bild auf einen anderen Speicherbereich umschalten damit man das Bild überhaupt bearbeiten kann. Dir wird erst beim implementieren auffallen, wo es hakt.
MaWin schrieb: > Sebastian N. schrieb: >> Hat jemand eine Idee? > > Das Ding hat doch schon fast ein CAMeraInterFace, Pixelclock und je 6 > bit RGB parallel. > Die Frage ist, ob dein Mikrosteinchen Daten mit solcher Datenrate > annehmen kann. Mindestens DMA in den Speicher, und dann pro Bild auf > einen anderen Speicherbereich umschalten damit man das Bild überhaupt > bearbeiten kann. > Dir wird erst beim implementieren auffallen, wo es hakt. Schaffen würde er es warscheinlich, jedoch macht es wohl, wenn ich mich hier auf rufus beziehe, keinen Sinn das System permanent mit 75MB/s zu belasten nur damit ein "Standbild" übertragen wird. Lothar M. schrieb: > Sebastian N. schrieb: >> hänge leider bei einem "kleinen" Problem. > Du schätzt die Größe dieses Problems falsch ein... Fällt mir leider auch schon auf. Lothar M. schrieb: > Aber treten wir doch einfach mal einen Schritt zurück, und hinterfragen > diese Aufgabenstellung: >> Ich möchte gerne ein 18bit Signal, das via 36pin FFC normalerweiße in >> einen TFT geht, abfangen, umwandeln (am besten CAMIF) und als Input in >> einen Rock64 (ähnlich RPi) nutzen. > Warum willst du das machen? Was passiert dann im Rock64 mit diesem Bild? > Wird da dann einfach mir zusätzlich was eingeblendet? Oder läuft da eine > OCR, die die eingelesenen Texte wieder entschlüsselnlt? Was ist denn die > Aufgabe des Gesamtsystems? Gibt es eine einfachere Schnittstelle, um an > die gewünschte Information zu kommen, als diesen LCD-Port? Es handelt sich um den Display eines Audi MMI 2G Systems. (Ich hoffe das zieht das Diskussion jetzt nicht ins lächerliche) Es wird einfach nur zusätzlich angezeigt um die Informationen und Umschaltmöglichkeiten des MMI zu erhalten. Der original Display soll dann eben wenn schon ein Android System integriert wird auch gleich mit getauscht werden gegen einen Display mit Touch und doppelter oder dreifacher Auflösung.
:
Bearbeitet durch User
Die einzig zielführende Lösung wäre, das Displaysignal per FPGA in einen Framebuffer einzulesen und von dort aus hardwaremäßig über/unter das Display des Android-System zu blenden. Heißt also: Das Displaysignal des Android-System wird ebenfalls in das FPGA gelesen, und überall, wo ein bestimmter RGB-Wert auftaucht, wird das korrespondierende Pixel des MMI-Displays aus dem RAM angezeigt. Das kann man alles machen, es wird auch so funktionieren, aber ein schnelles und halbwegs großes FPGA und solide VHDL oder Verilog-Kenntnisse sind Pflicht. Andere realistische Möglichkeiten sehe ich nicht. fchk
Frank K. schrieb: > Die einzig zielführende Lösung wäre, das Displaysignal per FPGA in einen > Framebuffer einzulesen und von dort aus hardwaremäßig über/unter das > Display des Android-System zu blenden. Heißt also: Das Displaysignal des > Android-System wird ebenfalls in das FPGA gelesen, und überall, wo ein > bestimmter RGB-Wert auftaucht, wird das korrespondierende Pixel des > MMI-Displays aus dem RAM angezeigt. > > Das kann man alles machen, es wird auch so funktionieren, aber ein > schnelles und halbwegs großes FPGA und solide VHDL oder > Verilog-Kenntnisse sind Pflicht. > > Andere realistische Möglichkeiten sehe ich nicht. > > fchk Übersteigt eindeutig meine Kompetenzen. Allerdings hast du mich da auf eine Idee gebracht. Wäre es einfacher das Signal in ein HDMI Signal umzuwandeln?
Sebastian N. schrieb: > Wäre es einfacher das Signal in ein HDMI Signal umzuwandeln? Womit? Ich kenne nur die andere Richtung: https://www.hy-line.de/produkte/detail/cat7/tft-controller/crttolcd-61-pro/
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Womit? Das hatte ich angebracht; das geht mit einem TFP410. Parallel rein-TDMS raus. Das Problem ist, daß hier noch eine Konvertierung der viel zu niedrigen Auflösung erfolgen muss; das Display hat nur 320x240 Pixel. Man bräuchte also einen Abtastratenkonverter. Wahrscheinlich aber ist es sinnvoller, das Autoradio durch ein anderes mit dem gewünschten Featureset zu ersetzen. Der Aufriss, der hier nötig ist, steht nach meiner Einschätzung in überhaupt keiner Relation zum Ergebnis.
Rufus Τ. F. schrieb: > Parallel rein-TDMS raus. Ich würde das auch mit einem FPGA machen. Und dann eine Kamera mitsamt Interface nachbilden. Mit ein wenig Glück geht das ohne großartigen Buffer, wenn die beiden Bildfrequenzen gleich gehalten werden können. Wo dieses Kamera-Bild dann eingeblendet und sakliert wird, ist dann dem Rock64 überlassen...
Rufus Τ. F. schrieb: >das Display hat nur 320x240 Pixel 480x240, sollte doch eigentlich kein Problem für HDMI darstellen. Lothar M. schrieb: > Rufus Τ. F. schrieb: >> Parallel rein-TDMS raus. > Ich würde das auch mit einem FPGA machen. Und dann eine Kamera mitsamt > Interface nachbilden. Mit ein wenig Glück geht das ohne großartigen > Buffer, wenn die beiden Bildfrequenzen gleich gehalten werden können. > Wo dieses Kamera-Bild dann eingeblendet und sakliert wird, ist dann dem > Rock64 überlassen... Ich würde das eher prakmatischer angehen und einen HDMI Switch verwenden, würde für diese Anwendung mMn völlig reichen.
Sebastian N. schrieb: > 480x240, sollte doch eigentlich kein Problem für HDMI darstellen. 240 Pixelzeilen? Wieso sollte das kein Problem darstellen?
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.