mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Serielles TFEL-Display (GPIO) an RaspberryPi


Autor: Tim S. (freak_ts) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe ein paar Fragen zu einem Display.
http://lumineq.com/sites/default/files/product/fie...

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/fie...
Das macht im TestMode aber nichts.

Danke für Tipps und Anregungen.
tsx

: Bearbeitet durch User
Autor: Tim S. (freak_ts) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?
3.6 Signal inputs
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...

Autor: Tim S. (freak_ts) Benutzerseite
Datum:

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

Autor: Tim S. (freak_ts) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Tim S. (freak_ts) Benutzerseite
Datum:

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

Autor: Tim S. (freak_ts) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Tim S. (freak_ts) Benutzerseite
Datum:

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

Autor: Arduinoquäler (Gast)
Datum:

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

Autor: Klugscheisser (Gast)
Datum:

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

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

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Tim S. (freak_ts) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
        -FRAGE-                |       -Ziel-
                               |
Source       Raspberry         |       Display
RS232  ----> DisplayController | ----> Passiv
GPIO         AVR Framebuffer   |       Seriell
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.
Table 8. 640 columns x 400 rows (NORMAL mode)
Description                  Min         typ        Max       Unit
Vertical Front Porch         60          ---        ---        µs
VS HIGH/LOW time             1           ---        ---       tVCLK
Vertical Blank               40          ---        ---        µs
VS frequency                 ---          70         80        Hz

HS setup to VS                9          ---        ---       tVCLK
Vertical Back Porch           2          ---        ---        µs
HS Low Time                   4          ---        ---       tVCLK
HS High Time                 640         640        ---       tVCLK
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
Autor: Tim S. (freak_ts) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Tim S. (freak_ts) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

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

Autor: Tim S. (freak_ts) Benutzerseite
Datum:

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

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.