Forum: Mikrocontroller und Digitale Elektronik LCD Signal abfangen und umwandeln


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Sebastian N. (aranox)


Bewertung
0 lesenswert
nicht lesenswert
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 Moderator
von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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?

von Sebastian N. (aranox)


Bewertung
0 lesenswert
nicht lesenswert
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
von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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?

von google (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Häng eine Kamera an Deinen Kleinrechner und filme das Display ab. Dürfte 
die einfachste Lösung sein.

von Μαtthias W. (matthias) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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?

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sebastian N. (aranox)


Bewertung
0 lesenswert
nicht lesenswert
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
von Frank K. (fchk)


Bewertung
0 lesenswert
nicht lesenswert
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

von Sebastian N. (aranox)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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...

von Sebastian N. (aranox)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Sebastian N. schrieb:
> 480x240, sollte doch eigentlich kein Problem für HDMI darstellen.

240 Pixelzeilen? Wieso sollte das kein Problem darstellen?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.