mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Touch Display - Typ der beiligenden Platine?


Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Ich hab eine Frage bzgl. der bei eBay erwerbbaren Touch Display.
Bei so ziemlich jeden Display das direkt keinen HDMI Eingang hat, liegt 
eine solche Platine bei wie hier auf den Fotos:

Ebay-Artikel Nr. 262473174562

Ich hab mehere Fragen:

1. Welcher Standard ist der Display Anschluss (Flachbandkabel) ?
   Ich vermute DSI?

2. Ist der Display Controller direkt am Bildschirm oder auf der
   beiligenden Platine? Wenn er am Display ist, kann ich den Controller
   dann parallel per Flachbandkabel direkt ansteuern (ohne diese 
Konverter
   Platine)? Und wenn er auf der Platine ist, und ich möchte nur das
   Display ohne Platine betreiben, muss ich dann einen Display 
Controller
   erst dazu kaufen (um nicht die fette Platine zu nutzen?)

   Ich vermute mal die Ansteuerungslogik bzw. der Displaycontroller ist 
am
   Display und auf der Platine nur ein Konverter (HDMI/VGA <--> DSI 
o.ä.)


3. Könnte ich dieses Display rein theoretisch (sofern das ein DSI 
Anschluss
   am Flachbandkabel ist) einfach ohne Konverter Platine direkt am DSI
   Anschluss des Raspberry betreiben?

Ich würde mich riesig freuen wenn Ihr mir weiter helft!
Vielen Dank im Vorraus!

Freundliche Grüße
Alex

PS: Ich weiß, das Angebot ist nicht sehr einladend bei dem miserablen 
Deutsch. Aber da die anderen Display mehr oder weniger identisch sind, 
und in dem Angebot gute Bilder sind hab ich das genommen ;-)

Autor: Gerald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat jetzt nix mit der Frage zutun aber hast du gesehen das der Versand 
mit 30€ angegeben ist?.

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex schrieb:
> Ich weiß, das Angebot ist nicht sehr einladend

Und ich sagte auch:
> Ich weiß, das Angebot ist nicht sehr einladend

Ich würde sowieso kein Display aus China bestellen.
Es ging um die Fotos.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex schrieb:
> 1. Welcher Standard ist der Display Anschluss (Flachbandkabel) ?
>    Ich vermute DSI?

Nein. Das dürfte ein stinknormales LVDS-Display sein.

> Ich vermute mal die Ansteuerungslogik bzw. der Displaycontroller ist am
>    Display und auf der Platine nur ein Konverter (HDMI/VGA <--> DSI
> o.ä.)

Die Platine ist ein HDMI/VGA-zu-LVDS-Konverter.

Das ist damit auch der Displaycontroller; was stellst Du Dir darunter 
anderes vor?

Da das Display kein DSI-Display ist, kannst Du es auch nicht am 
DSI-Anschluss betreiben.

DSI ist praktisch undokumentiert, da die MIPI keine Unterlagen an 
Nicht-Mitglieder 'rausrückt. Obendrein wird DSI nur in Mobilgeräten 
(Smartphones & Tablets) verwendet; nur deren Hersteller produzieren 
ausreichende Stückzahlen, daß es sich lohnt, MIPI-Mitglied zu werden.

Und wegen der miserablen Dokumentationslage wird die Anzahl verfügbarer 
DSI-Displays sich kaum vergrößern, aus dem gleichen Grund ist die 
Schnittstelle für Bastelzwecke auch reichlich ungeeignet.

Obendrein ist es so, daß nicht jedes Display in Mobilgeräten ein 
DSI-Display ist; im iPad beispielsweise wird Embedded DisplayPort 
verwendet, und andere Geräte mit geringeren Auflösungen verwenden 
herkömmliche LVDS-Displays -- wie das, das Du da als eBay-Auktion 
gefunden hast.

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

> Nein. Das dürfte ein stinknormales LVDS-Display sein.
Okay Danke :-)
Die Information bringt mich zumindestens schonmal einen Pfad.
Aber nach kurzer Recherche hab ich erfahren das LVDS wohl nur die 
physikalische Schnittstelle standardisiert.
Das Protokoll kann wohl alles mögliche sein. Gibts hier auch ne Art 
Standardisierung bzw. Richtung des Protokoll für Displays (Laptop 
Display, das genannte etc...)

> Das ist damit auch der Displaycontroller; was stellst Du Dir darunter
> anderes vor?
Im Grunde genommen dass das Display per Kommandos angesprochen werden 
kann und nicht "nackt" ist und theoretisch jeder Pixel einzeln gesteuert 
werden muss (bzw. noch ein Controller für angeschafft werden).

Was ich mir NICHT unter einem Displaycontroller vorstelle ist eine 
komplette leistungsfähige GPU.

> Und wegen der miserablen Dokumentationslage
LVDS scheint mir da auch eher schlecht als recht dokumentiert zu sein.

Viele Grüße
Alex

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex schrieb:
> Das Protokoll kann wohl alles mögliche sein.

Da ist nicht viel Protokoll. Als Unterschiede gibt es die verwendete 
Farbtiefe (8 oder 6 Bit pro Grundfarbe) und einen oder zwei Datenkanäle, 
was sich in vier oder acht LVDS-Datenleitungspärchen niederschlägt.

> LVDS scheint mir da auch eher schlecht als recht dokumentiert zu sein.

Das ist es nicht; sieh Dir einfach mal ein Datenblatt eines 
entsprechenden Displays an, da steht alles drin.

> Im Grunde genommen dass das Display per Kommandos angesprochen werden
> kann

Das macht so ein Ding nicht, das macht aber auch ein DSI-Display nicht. 
So etwas ist ein Monitor, der ein zyklisch aktualisiertes Bild 
anzeigt.
Deswegen findest Du auch nichts über irgendwelche "Kommandos" in den 
Displaydatenblättern, die gibt es nämlich nicht.
Stattdessen wird mit üblicherweise 60 Hz das komplette Bild Pixel für 
Pixel an das Display übertragen.

Den Aufbau des Bildes, das Verwalten des Bildspeichers etc. muss eine 
separate Elektronik durchführen. Der Raspberry Pi macht das - und er 
gibt die Bilddaten entsprechend aufbereitet an seiner 
Monitorschnittstelle (HDMI) aus.

Autor: Alexander (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Abend,

> Da ist nicht viel Protokoll. Als Unterschiede gibt es die verwendete
> Farbtiefe (8 oder 6 Bit pro Grundfarbe) und einen oder zwei Datenkanäle,
> was sich in vier oder acht LVDS-Datenleitungspärchen niederschlägt.

Ich versteh das jetzt richtig?
LVDS spezifiziert nur eine phys. Schnittstelle.
Was man dadraus macht (Protokoll bzw. Ansteuerung) ist Sache der Display 
Hersteller, korrekt?

> Stattdessen wird mit üblicherweise 60 Hz das komplette Bild Pixel für
> Pixel an das Display übertragen.
Aber auch das ist nicht standardisiert, korrekt?
Das heißt jedes Display erhält seine Daten in (geringfügig) anderer 
Reihenfolge?
Und wie, das entnehme ich dann den Display Datenblättern?.

Wenn es so ist wie von mir beschrieben, wie kann es dann sein das dieses 
Konverter Board bei fast jedem (anderen) Display ebenfalls beiliegt wenn 
Ansteuerung verschieden ist?

Der Controller auf diesem verbreiteten Board ist ein RTD2660 (Realtek TV 
Controller).

Nach Internet Recherchen bin ich wohl dadrauf gekommen das der 
Controller RTD2660 mit verschiedenen Firmwares beschrieben werden kann 
(halt passend zu dem entsprechenden Display). Ist das richtig?

Und wenn das auch wieder stimmt, würde das doch heißen das ich auch beim 
Laptop zum Beispiel nicht einfach jedes Display anstecken kann wenn der 
GPU Controller im Laptop dieses Display nicht unterstützt oder?

Oder wurde hier doch etwas über die Display Ansteuerung standardisiert, 
nur das ich es nicht mitbekommen hab?

Fragen über Fragen, tut mir leid.
Aber ich versuche erstmal Fuß zu fassen in dem Display Gebiet.

Vielen Dank im Vorraus!
Viele Grüße
Alexander

Autor: Georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alexander schrieb:
> Nach Internet Recherchen bin ich wohl dadrauf gekommen das der
> Controller RTD2660 mit verschiedenen Firmwares beschrieben werden kann
> (halt passend zu dem entsprechenden Display). Ist das richtig?

Jap ist richtig. Die Firmware kann man über I2C auf den Chip flashen. Es 
gibt auch ein Tool, um die Firmware anzupassen an andere Displays:
http://tech.mattmillman.com/lcd/rovatools/

Es gibt auch noch weitere OS-Tools zum reinen Flashen:
https://github.com/juancgarcia/RTD-2660-Programmer-Python
https://github.com/ghent360/RTD-2660-Programmer

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alexander schrieb:
>> Stattdessen wird mit üblicherweise 60 Hz das komplette Bild Pixel für
>> Pixel an das Display übertragen.
> Aber auch das ist nicht standardisiert, korrekt?

Es gibt Ausnahmen mit anderer Bildwechselfrequenz. Die aber sind selten.

> Das heißt jedes Display erhält seine Daten in (geringfügig) anderer
> Reihenfolge?

Nö. Sofern es mit einem LVDS-Kanal* angesteuert wird, ist die 
Reihenfolge identisch.
Zeilenweise, von links nach rechts und von oben nach unten, so wie ein 
oller Röhrenkübel auch angesteuert wurde.
Das wird mit drei Taktsignalen gesteuert, Pixeltakt, Zeilentakt (Hsync) 
und Bildwechseltakt (Vsync). Die Namen können abweichen, die Funktion 
bleibt aber die gleiche.

Bei zwei** LVDS-Kanälen werden zwei Pixel gleichzeitig übertragen.

Dazu wird das Display üblicherweise horizontal geteilt, so daß es eine 
obere und untere Hälfte gibt, die gleichzeitig angesteuert werden.

(Manche Displays bieten Steuersignale an, mit denen sie das übertragene 
Bildsignal vertikal und/oder horizontal spiegeln können, das ist dann 
noch mal eine Sonderlocke).

> würde das doch heißen das ich auch beim Laptop zum Beispiel nicht
> einfach jedes Display anstecken kann wenn der GPU Controller im Laptop
> dieses Display nicht unterstützt oder?

Richtig. Allerdings ist es mittlerweile verbreitet, daß das Display ein 
EEPROM enthält, in dem die zur Ansteuerung wesentlichen Daten 
gespeichert sind und die Graphikhardware passt sich dem --innerhalb 
gewisser Grenzen-- an. Das muss natürlich nicht so sein, es gibt leider 
immer wieder Ausnahmen.

Ein Problem gibt es, wenn zwischen Ein- und Zweikanal-Displays 
gewechselt wird, da muss nämlich das Displaykabel passen; die 
Notebookhersteller sind hier gerne sparsam und lassen bei 
Einkanalbetrieb die unbenutzten Leitungen des zweiten Kanals weg.

Es gibt diese Displayansteuerungselektroniken auch in vom Benutzer 
konfigurierbaren Varianten, die Firma Pollin vertreibt so etwas. Da wird 
mit Jumpern ein Parametersatz aus einer Tabelle ausgewählt. Hat man ein 
Display, das in dieser Tabelle zu finden ist, kann man die Platine 
nutzen, sonst nicht.


Ein zweiter nicht standardisierter Punkt ist die Ansteuerung der 
Hintergrundbeleuchtung. Es gibt Displays mit LED-Beleuchtung, bei denen 
die Ansteuerung über das selbe Kabel erfolgt wie auch die restliche 
Ansteuerung (das in Deinem eBay-Link ist so eines), aber es gibt auch 
Displays, bei denen dafür ein separater Anschluss verwendet wird - und 
bei Displays mit CCFL-Beleuchtung ist das sowieso der Fall. Hier gibt es 
noch je nach Größe des Displays und je nach Verwendungszweck 
unterschiedlich viele CCFL-Röhren, in Notebooks ist eine einzelne 
üblich, bei Desktopmonitoren können auch deutlich mehr auftreten.

Die benötigen dann eine passende Hochspannungserzeugung, den sogenannten 
"Inverter".


*) Das ist die Summe der Farb- und Takt-Informationen, also vier 
LVDS-Datenleitungspärchen.

**) Die werden i.d.R. als "even" und "odd" bezeichnet, so daß es die 
unter* erwähnten Datenleitungspärchen doppelt gibt.

: Bearbeitet durch Moderator
Autor: Alexander (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Abend,

Danke für die Antwort! :-)

Das klingt schonmal interessant.
Gibt es "einfach" ansteuerbare Grafikprozessoren für die Verwendung mit 
LVDS Displays?

Bzw. das ist 'ne doofe Frage. Selbstverständlich gibt es das (?).
Aber ich meine welche für "Einsteiger" (mit gewisser Verbreitung), mit 
entsprechender Dokumentation, vielleicht sogar Tutorials und 
zumindestens viel Lesestoff vom Hersteller bzw. im Internet den man 
wälzen kann wenn man auf ein Problem trifft?

Da an diesem Punkt bestimmt wichtig ist um welche Plattform es sich 
überhaupt dreht:
Es geht um ein Intel Edison (x86 Architektur - Yocto Linux).

Mir fehlt noch die Vorstellung für den Grafik Prozessor.
Flashe ich den mit einer eigenen Firmware und greife während der 
Entwicklung auf Bibliotheksfunktionen (für LVDS oder was auch immer) 
zurück?
Oder wird ein Grafik Prozessor bereits mit Firmware ausgeliefert und ich 
übergebe ihm z.B. ein Bitmap und er kümmert sich um die weitere 
Verarbeitung (Behält es im Speicher bis aktualisiertes Bild Material 
kommt, wiederholt es auf dem Display etc...)

Viele Fragen. Aber ich finde es gibt sehr wenig Lesestoff über die 
Grafikentwicklung im eingebetteten Bereich.

Vielen Dank für deine/eure Mühe! :-)

Viele Grüße
Alexander

Autor: Alexander (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Nachtrag:
Ich bin auf die nVidia Tegra Grafik Prozessoren gestoßen.
Ist das aber überhaupt das richtige für den Einstieg?

Grüße
Alexander

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alexander schrieb:
> Flashe ich den mit einer eigenen Firmware und greife während der
> Entwicklung auf Bibliotheksfunktionen (für LVDS oder was auch immer)
> zurück?

Dies System wird im normalen PC in der Startphase benutzt. Die 
Grafikkarte hat eine eigene rudimentäre Firmware ('BIOS') auf der Karte, 
die für simplere Sachen ausreicht, um bspw. Zeichen auf den Schirm zu 
bringen oder Speicherbereiche in den Bildspeicher zu kopieren.

Alexander schrieb:
> Oder wird ein Grafik Prozessor bereits mit Firmware ausgeliefert und ich
> übergebe ihm z.B. ein Bitmap und er kümmert sich um die weitere
> Verarbeitung (Behält es im Speicher bis aktualisiertes Bild Material
> kommt, wiederholt es auf dem Display etc...)

Höhere Grafikaufgaben laufen so gut wie immer durch einen an die GPU 
angepassten Treiber. Das ist unter Linux genauso wie unter Mac OS oder 
Windows. Dazu 'übersetzt' der Treiber standardisierte Aufrufe wie OpenGL 
oder DirectX auf die 'Sprache' der GPU und nutzt dann deren Funktionen, 
um komplexere Bilder etc. zu generieren.

Das Problem beim Edison ist, das du gar keinen Datenbus hast, an den du 
eine GPU andocken könntest, zumindest nicht so schnell, das du deren 
Vorteile nutzen könntest. Es wäre allerdings denkbar, einen simplen 
Framebuffer Treiber zu schreiben, der mittels Timer und ganz schön 
Rechenleistung eine Teil des Hauptspeicher so über den 70-Pin Anschluss 
ausgibt, das man da ein recht dummes LCD anschliessen kann. Das ist aber 
eine Aufgabe für jemanden, der sich sowohl mit LCD als auch mit der 
Architektur des Atom gut auskennt.
Hier sind zwei solcher Projekte, die kleine Displays am Edison 
betreiben:
https://blog.adafruit.com/2016/05/03/framebuffer-f...

http://hackaday.com/2015/01/10/running-doom-on-the...

Letzteres benutzt den Arduino Shield für den Edison.

: Bearbeitet durch User
Autor: Alexander (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

> keinen Datenbus hast, an den du eine GPU andocken könntest, zumindest
> nicht so schnell
Oh weia. Das vermiest mir jetzt aber ziemlich den Tag :-(

Also:

Display's in meiner gesuchten Größe (7" - 12") gibts eigentlich nur mit 
LVDS (kein SPI o.ä.).

Für eine vernünftiges Bild brauche ich eine GPU (bei LVDS).

Es gibt keine GPU die mit dem Intel Edison verbunden werden kann.

Da lässt sich auch wirklich nichts dran machen?
Eherlich gesagt tut mir das schon etwas weh.
Der Edison ist für mich quasi perfekt und gefiel mir auch viel besser 
als der Raspberry. Aber wenn es rein garkeine Lösung gibt werd ich wohl 
doch wieder zum Raspberry (diesmal Compute Module) wechseln.

Grüße
Alexander

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alexander schrieb:
> Der Edison ist für mich quasi perfekt

Ist ja auch ein nettes Dingelchen, aber eben nicht für Bildschirme 
gedacht, sondern eher als 'Embedded Atom'. Im 'Doom on Edison' Projekt 
sagt der Entwickler ja auch, das die Leistung mit Bildschirm dann eher 
auf 486er Niveau ankommt und gerade mal 15 fps schafft. Mit einem 
grösseren Display wird das dann noch weniger.

Autor: Alexander (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias S. schrieb:
> Alexander schrieb:
>> Der Edison ist für mich quasi perfekt
>
> Ist ja auch ein nettes Dingelchen, aber eben nicht für Bildschirme
> gedacht, sondern eher als 'Embedded Atom'. Im 'Doom on Edison' Projekt
> sagt der Entwickler ja auch, das die Leistung mit Bildschirm dann eher
> auf 486er Niveau ankommt und gerade mal 15 fps schafft. Mit einem
> grösseren Display wird das dann noch weniger.

Ja. :-D

Die ganze Fragerei stammt daher weil ich den Edison später evtl. im 
Automobilbereich verwenden wollte. Aber wie es aussieht: Nicht grafisch.

Ist jetzt auf alle Fälle nicht weiter tragisch.
Wenn ich dann später auf Grafikfunktionen zurückgreifen muss, werd ich 
mich nochmal mit dem Thread hier beschäftigen und mir evtl. den Intel 
Joule angucken.

Bin auf alle Fälle erstmal mit dem Edison beschäftigt und vollkommen 
zufrieden.

Hab halt nur schonmal in die nähere Zukunft geschaut, da ich mit offenen 
Fragen nicht gut schlafen kann :-)

Vielen Dank Allen Zusammen und Viele Grüße
Alexander

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.