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: http://www.ebay.de/itm/10-1-Inch-TFT-LCD-Display-Module-HDMI-VGA-Video-Driver-Board-fur-Raspberry-Pi-/262473174562?hash=item3d1c9ece22:g:6oEAAOSwUuFWztZ1 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 ;-)
Hat jetzt nix mit der Frage zutun aber hast du gesehen das der Versand mit 30€ angegeben ist?.
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.
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.
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
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.
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
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
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 User
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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Nachtrag: Ich bin auf die nVidia Tegra Grafik Prozessoren gestoßen. Ist das aber überhaupt das richtige für den Einstieg? Grüße Alexander
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-fbtft-for-intel-edison-ssd1322-oled-display-linux-yoctoproject/ http://hackaday.com/2015/01/10/running-doom-on-the-intel-edison/ Letzteres benutzt den Arduino Shield für den Edison.
:
Bearbeitet durch User
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
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.
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
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.