Hallo, ich habe ein paar Fragen zu einem Display. http://lumineq.com/sites/default/files/product/fields/field_operating_manual/operation_manual_el640.400-c2-c3-cd3_2_0.pdf Derzeit läuft es im TestMode und alle Pixel sind an. Es ist einfarbig, und hat 640x400 Pixel. Ich würde es gerne an den Raspberry anschließen, um Textausgaben der Shell (Kompilierungen etc) zu machen. Weiß jemand ob es technisch machbar ist? Also ob der Pi da mithalten kann? Und ob es eine Art Modul oder Lib gibt, mit der ich das machen kann, ohne das ich erst einen Framebuffer usw (AVR) brauche, um das Display direkt an die GPIOs zu hängen? Framerate, endgültige Auflösung der Ausgabe usw sollte erstmal keine große Rolle spielen. Zunächst würde ich die Pixel und Zeilen Verdoppelt ausgeben, wenn der Pi das nicht schafft. Ich habe das zuvor noch nicht gemacht. Ich kann also nicht ausrechnen oder Überschlagen, welche Datenraten oder PixelClocks ich brauchen werde. Eventuell kann mir jemand unter die Arme greifen, und mir ein paar Tipps geben. Die 400px (V) lassen sich noch halbieren, und man kann zwei Linien(H) parallel "einspeisen". So bräuchte ich weniger "Zyklen" pro Frame. Ich versuchs mal auszurechnen: 640x400 Pixel normal. V-Lines Doppeln = 640x200. H-Lines Dual ausgeben = 320x200 Clocks pro Frame = 64000 GPIO "Umschaltungen" pro Frame. Bei 10 Frames/s sind das 640000 Hz?? 640 kHz? Kann das stimmen? Ich habe noch ein kleineres mit 512x256 Pixel http://lumineq.com/sites/default/files/product/fields/field_operating_manual/operation_manual_el512.256-h.pdf Das macht im TestMode aber nichts. Danke für Tipps und Anregungen. tsx
:
Bearbeitet durch User
Noch eine Frage; Um das Display mit VGA zu betreiben, brauche ich wahrscheinlich noch etwas um das Video Clock "VCLK" Signal zu erzeugen?? Oder kann ich das direkt an VGA anschließen?
1 | 3.6 Signal inputs |
2 | For easy interfacing with VGA display controllers, the video input signals are VGA feature connector compatible. The display automatically determines the mode of operation. |
Also bräuchte ich wohl noch dieses "VGA feature" !?!? Danke nochmal...
Mit etwas "Tricksen" gehts ja vielleicht mit SPI? SPI-Clock auf die H-Clock Leitung, und nach 80 Bytes Daten einer Zeile, dann die V-Clock Leitung Pulsen? Wie gesagt, ich habe keine Erfahrung.
Okay habe einen Rechenfehler oben. 640x400 Pixel normal. H-Lines Doppeln = 640x200. H-Lines Dual ausgeben = 640x100 Clocks pro Frame = 64000 GPIO "Umschaltungen" pro Frame. Ändert aber eigentlich nichts an der "Datenmenge". Wenn jemand eine Lib für nen AVR kennt, wäre das natürlich auch super. AVRs, SRAM, Programmer usw habe ich alles da. Direkt am Raspberry wäre es natürlich einfacher gewesen... Der DSI-Connector ist leider keine Option. Ich bräuchte nur ein Paar Tipps, wie ich mit dem Display weiterkomme, da ich es wirklich noch verwenden möchte, und es zu schade zum Wegschmeißen ist.
:
Bearbeitet durch User
Ich habe den Thread von Benedikt K. (wieder) gefunden. Dort wurde öfter nach einem ähnlichen Display gefragt. Es ist aber keine passende Lib oder Vorschläge vorhanden, und ich finde nichts weiter dazu. Auszug: > Dieses Display lässt sich prinzipiell ansteuern, allerdings nur mit > etwas zusätzlichem Aufwand. Man müsste die Software, und die Hardware > so anpassen, dass sie die Daten Pixel für Pixel anstelle von 8 Pixel > auf einmal ausgibt. Soweit so gut, liegt in dem Fall ja dran, dass diese Displays "Anders" angesteuert werden, eben mehrere Bits Parallel für Pixeldaten "Hintereinander" (Wenn ich das richtig verstanden habe), Ein Umbau wäre ja nur ein "Downgrade" im Endeffekt, auf nur 2 Pixeldaten, und hald eben "Untereinander" für "Two-bit data" auf zwei Rows. > Das Problem ist: Man muss irgendwie einen Takt erzeugen, der 8x so > hoch ist und einen Schaltungsteil der 8bit annimmt, und die Daten Bit > für Bit ausgibt, daber 8x so schnell. Wie man das ohne viel Aufwand > machen kann, dafür fällt mir spontan keine gute Lösung ein. Kann ich stattdessen nicht einfach eine langsamere Framerate haben? Ist das diesem seriellen Display nicht eigentlich wurscht? Kann sich evtl jemand äußern und mich korrigieren?
Lohnt es sich, die Methode mit SPI auszuprobieren? Der ist am Raspberry doch relativ "schnell" und läuft in Hardware !? Damit könnte man doch fix eine Row raus schieben? Und nach einer Zeile, dann den V-Puls erzeugen. Dann die nächsten 80 Bytes über SPI raus schieben. Mit der "Zeilenverdopplung" wären dann nur noch 200x V-Pulse pro Frame nötig. Die Schriftart wäre dann auf jeden Fall 8 Pixel breit, und ich kann pro Char-Zeile ein Byte in Hardware(?) raus schieben. 64 Zeichen pro Zeile. Edit: Und wenn das geht mit zwei synchronen SPIs (falls es das überhaupt gibt) gleich zwei Rows auf einmal raus zu hauen wär´s natürlich noch schöner und ggf schneller. Kann das funktionieren!? Edit2: Ist da draußen jemand?
:
Bearbeitet durch User
Kann mir jemand sagen warum trotz konkreter Fragestellung, gutem Satzbau, einigermaßen korrekter Schreibweise, einem technischem Thema in einem Technik Forum in der passenden Kategorie, zu einfachst formulierten Fragen, und trotz bereits erfolgtem Nutzen der Suchfunktion, einfach niemand eine Antwort geben kann? Ist es möglich, das jemand kommunikationsfähig ist oder wird? Vielleicht antwortet jemand, wenn ich doch den AVR als Framebuffer einsetze? Ist ja letztendlich auch mein Ziel. Das Display nimmt pro H-Puls einen Pixel an, und nach 640 H-Pulsen kommt ein V-Puls. Kann ich den H-Synch mit über die SPI-Clock fahren? Kann mir jemand Schlagwörter nennen, mit denen ich Suchen kann? Oder gar eine Lib für den AVR ganz egal ob C oder ASM oder Bascom!??? Wie heißt diese Art der Ansteuerung des Displays? Wenns mit Raspberry und AVR und einigen Bastlern, die bereits Erfahrungen damit haben nicht läuft, und keiner antwortet, muss ich eventuell nach einem Fertig-Controller (IC-Typ) für dieses Display fragen, damit es dem angestrebten kommunikativen Niveau dieses Forums würdig(er) wird?? - dem nichts? Klar suche ich ne halbwegs fertige Lib, da ich momentan anderes mache, und anderweitig Beschäftigt bin. Das nebenher noch anzupassen, zusammenzustecken, und zu testen reicht mir schon. Kennt denn keiner solch eine AVR-Lib, die H/V und einen Pixel seriell ausgeben kann, ggf mit UART Eingang? Weil ja auch andere Mitglieder daran interessiert sind, wollte ich das Rad nicht zum (gefühlt) Hunderttausendsten mal neu erfinden, und dachte, ich kann hier mehr erwarten als nur Alsheimer. Aber scheinbar gibt es nicht mal mehr die Zeit für die üblichen Antworten, wie z.B "Geht nur mit FPGA". Kann hier mal jemand "funktionieren"? Was mach ich denn falsch? Sagt wenigstens bitte mal einer, ob das mit dem SPI so funktionieren kann! Danke
Tim S. schrieb: > Was mach ich denn falsch? Das liegt vielleicht daran dass du ein sehr spezielles Anliegen hast, die Leute dafür gerade im Urlaub sind und es (mir und vielleicht anderen Leuten auch) an Vorstellungskraft mangelt was du eigentlich genau willst. Ein Blockschaltbild oder so etwas ähnliches wie ein Schaltplan wäre wünschenswert damit deine Pläne etwas konkreter dargestellt werden ....
Tim S. schrieb: > Weiß jemand ob es technisch machbar ist? Ja. > Also ob der Pi da mithalten > kann? Ohne Hardwarehilfe eher nicht. > Und ob es eine Art Modul oder Lib gibt, mit der ich das machen > kann, ohne das ich erst einen Framebuffer usw (AVR) brauche, um das > Display direkt an die GPIOs zu hängen? Du brauchst einen Displaycontroller, der das Bild continuierlich aufbaut wie bei den meisten anderen Displays auch. Ob das ein spezieller Controller, ein FPGA oder ein TTL-Grab (oder ...) ist, spielt hierfür keine Rolle. Wenn ich nichts entscheidendes übersehe, ist das ein ganz normales monochromes Display. Tim S. schrieb: > Thread von Benedikt K. Das sollte eigentlich ausreichen.
Tim S. schrieb: > Ich würde es gerne an den > Raspberry anschließen, um Textausgaben der Shell (Kompilierungen etc) zu > machen. Dazu brauchst du einen Framebuffer Treiber. Tim S. schrieb: > Weiß jemand ob es technisch machbar ist? Also ob der Pi da mithalten > kann? Dann rechne doch mal ein wenig. Lass uns mal vom Grafik Mode 640*400 ausgehen, bei 70 Hz Framerate und Ausnutzen das Double Data Feature, damit die arme RPi Kiste nicht ganz so viel ackern muss. Also, Hsync liegt dann bei (70Hz * 400Zeilen) = 28000 Hz und die Video Clock bei 28000 Hz * 640 Pixel = 17,92 Mhz. Da wir Double Data nutzen wollen, halbiert sich das glücklicherweise auf 8,96 Mhz. Du siehst vermutlich schon, das ohne unterstützende Hardware das nicht zu machen ist, zumal du ja im 8,96 Mhz Takt auch noch Videodaten an irgendwelche GPIOs legen müsstest. Gut, das ganze kann man natürlich auch mit niedrigerer Framerate machen, aber das grundsätzliche Problem der Pixel(Video)Clock bleibt und auch die Rate der Daten. Du brauchst also eine Hardware, die z.B. den HDMI Ausgang des RPi aufs Display umschnurzelt - der o.a. FPGA könnte sowas vermutlich. HDMI liefert dir schon eine Pixelclock, der Job des HSync und VSync rausfusselns aus HDMI ist aber trotzdem eine schöne Aufgabe.
:
Bearbeitet durch User
Sorry dass ich anstößig war... ;-) Tim S. schrieb: > Es ist einfarbig, und hat 640x400 Pixel. Klugscheisser schrieb: > Wenn ich nichts entscheidendes übersehe, ist das ein ganz > normales monochromes Display. Es wäre wirklich sehr nett wenn mal jemand kurz über das Datasheet fliegt. Ohne "200 lines mode", und ohne "two-bits-parallel" mode. Die ganz normale Serielle ansteuerung hald. Bei jedem "Tackt" kann ich einen Pixel Setzen - einfach An / Aus. Dafür brauch ich lediglich die Pins "HorizontalSync" und die "Video Data" - also 2 IOs. Diese "argieren" doch fast wie ein SPI? Nach jedem Tackt ein Bit. Nach 640 Pixeln, kommt der "VerticalSync", für eine weitere Row mit neuen 640 Pixeln. Nach 400 Rows ein neuer Frame. Also braucht mein Controller 3 Ausgänge. ohne die "special modes". Blockschaltbild:
1 | -FRAGE- | -Ziel- |
2 | | |
3 | Source Raspberry | Display |
4 | RS232 ----> DisplayController | ----> Passiv |
5 | GPIO AVR Framebuffer | Seriell |
6 | ETC Char-Generator | |
...aber das ist ja eindeutig. Matthias S. schrieb: > Hsync liegt dann bei (70Hz * 400Zeilen) = 28000 Hz und die Video > Clock bei 28000 Hz * 640 Pixel = 17,92 Mhz. Kannst du mir verraten wie du auf die Werte kommst, und von 70Hz ausgehst? Also ich verstehe die Rechnung, klar - Mit einer niedrigeren Framerate meinte ich natürlich, das das gesamte Bild "langsamer" aufgebaut wird. Daher habe ich zuerst die Datenmenge (640x400) mal Framerate (10Hz) genommen, um auf die maximale "Pixel / Video-Clock" zu kommen. Mir fehlen die richtigen Worte dafür. Ich komme damit nun auf etwa 2,56Mhz bei voller Auflösung, und ohne diese "reduzierten Modis". Wenn ich mich nicht Irre, kann das ein SPI schaffen. Matthias S. schrieb: > zumal du ja im 8,96 Mhz Takt auch noch Videodaten an > irgendwelche GPIOs legen müsstest. Es ist genau ein Pin. Daher kam mir die Idee, diese H-Clock und Pixel-Daten theoretisch über SPI füttern zu können. Nach einer Zeile dann den V-Puls loß lassen - Ich weiß aber nicht ob das so gehen kann, bzw ob das "SPI-Protokoll" nicht noch irgendwelche "Handshake/Null-Bits" zwischen drin raus lässt. (Habe noch keine Erfahrung damit gemacht) Tim S. schrieb: > Und wenn das geht mit zwei synchronen SPIs (falls es das > überhaupt gibt) gleich zwei Rows auf einmal raus zu hauen wär´s > natürlich noch schöner und ggf schneller. Zwei synchrone SPIs wäre für den "two-bits-parallel mode" gedacht. Dort benutzt man zwei Video-Daten Pins. (einfach an / aus). Der eine für die "geraden Zeilen-Nummern", und der andere für "ungerade Zeilen-Nummern". Diese werden beim selben Tackt gespeißt (synchron). Ist klar was ich meinte? ;-) Die 70Hz sind das Maximum, bzw. die "minimalen Timings" - und worauf ich hinaus will ist, dass es im Datasheet keine "maximum times" gibt, und es dem Display daher anscheinend egal ist, wenn ich bloß mit paar Khz/1MHz da ran gehe. Was mir fehlt ist eine Bestätigung dieser Aussage, und ob das mit SPI (und nem AVR) nun auch geht.
1 | Table 8. 640 columns x 400 rows (NORMAL mode) |
2 | Description Min typ Max Unit |
3 | Vertical Front Porch 60 --- --- µs |
4 | VS HIGH/LOW time 1 --- --- tVCLK |
5 | Vertical Blank 40 --- --- µs |
6 | VS frequency --- 70 80 Hz |
7 | |
8 | HS setup to VS 9 --- --- tVCLK |
9 | Vertical Back Porch 2 --- --- µs |
10 | HS Low Time 4 --- --- tVCLK |
11 | HS High Time 640 640 --- tVCLK |
12 | HS period 31 --- --- µs |
Demnach kann ich das nächste Pixel auch erst 3 Tage Später setzen. Natürlich sieht man dann nichts - ich weiß, dass es nicht selber refresht usw. Das ist alles klar. Die Rechnung wäre dann: [Zeit, für 80 Bytes SPI-Daten (also 640 px)] plus [Neuen V-Puls setzen] mal [400 Zeilen] Und der Rest ergibt sich von alleine! Geht das? Und wenn das Bild noch so langsam ist, wäre mir das erstmal egal. Optimieren kann man immer noch. Wenn ich mich richtig erinnere, wurde das "vorher" anscheinend auch so gemacht - der Bildaufbau war mega-langsam, und man konnte neue Seiten bzw den "Frame" bei Sonnenlicht gut aufbauen oder refreshen sehen... Und nur aus dem Grund habe ich diese Displays behalten - weil die relativ einfach aussahen. Vermutlich werde ich es einfach mal ausprobieren. Eine kleine Bestätigung, Informationen oder Tipps wären dennoch ganz nett.
:
Bearbeitet durch User
Ich bin jetzt so weit, dass ich mit Atmel Studio 7 direkt über den Raspberry und / oder dem AVR-ISP-MK2 + Pollin Evalboard die AVRs Flashen kann. Das hatte ich alles zuvor nur in ner Kiste liegen. Eigentlich wollte ich zuerst direkt den Raspberry zur Ansteuerung des Displays nehmen, um nicht erst Controller flashen zu müssen. Den C Code hätte ich hald für nen AVR portiert und übertragen, wenn es läuft. Aber es kommt ja einfach keine Antwort ob es funktionieren kann zurück. Also keine Ahnung ob es grundsätzlich am Raspberry geht, und ob die Theorie mit den Timings von mir stimmt, oder ob das mit SPI läuft. Und daher versuche ich es lieber gleich am AVR. (So, wie es dann auch "fertig" laufen soll) Da das mein aller erstes Programm für AVR ist, und quasi mein "Einstiegs-Projekt", denke ich, dass erstmal überhaupt nichts passt oder passiert. ALLES NUR THEORIE. Ich versuche erstmal alle Pixel mit SPI ein zu schalten, wie im Testmode. Dann geb ich nacheinander 0-255 über SPI aus - Es wird ein lustiges Muster ergeben, wenns denn klappt. Wenn´s nicht geht, werde ich das Display hald auf die IOs umhängen, und "konventionell" weiterversuchen. Bis dahin... Frohes nicht-antworten
:
Bearbeitet durch User
Habe das Datenblatt überhaupt nicht richtig verstanden. Eigentlich alles daneben ^^ Ich brauche min. 4 Pins, nicht 3.. Es geht doch nicht so einfach, wie erhofft. Matthias S. schrieb: > Dann rechne doch mal ein wenig. Lass uns mal vom Grafik Mode 640*400 > ausgehen, bei 70 Hz Framerate und Ausnutzen das Double Data Feature, > damit die arme RPi Kiste nicht ganz so viel ackern muss. > Also, Hsync liegt dann bei (70Hz * 400Zeilen) = 28000 Hz und die Video > Clock bei 28000 Hz * 640 Pixel = 17,92 Mhz. Da wir Double Data nutzen > wollen, halbiert sich das glücklicherweise auf 8,96 Mhz. Ich verstehe die Rechnung und den Zusammenhang usw. Aber warum MUSS ich von 70Hz ausgehen??
:
Bearbeitet durch User
Tim S. schrieb: > Aber warum MUSS > ich von 70Hz ausgehen?? Weils so im Datenblatt steht. Das Display sei kompatibel zu den VGA Modes, so steht es da, und das bedeutet erstmal nur, das es bei den angegebenen Refreshraten funktioniert. Es kann auch bei niedrigeren Raten funktionieren, muss es aber nicht, denn davon steht nix im DB. Beachte auch, das die Zeilendauer da fest auf 31,8µs festgelegt ist (Tabelle 6), das entspricht der guten alten VGA Frequenz mit etwa 31,4 kHz. Die Differenz zu den 28kHz, die ich oben angab, liegt daran, das es im 'richtigen' VGA Signal noch ein H-Sync und eine vordere und hintere Schwarzschulter gibt.
Tim S. schrieb: > Mit etwas "Tricksen" Klugscheisser schrieb: > Ohne Hardwarehilfe eher nicht. Okay jetzt ist alles schlüssig - Habe zuvor eigentlich alles falsch gemacht (die grundsätzliche H/V Ansteuerung usw) ;-) - Aber hab´s jetzt (endlich) verstanden. Mein Controller ist dafür zu langsam usw. Ich werde eine PCI-Grafikkarte mit "Feature Connector" auftreiben (müssen). Trotzdem danke für die Hilfe, und die gute Erklärung.
Bitte 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.