>Sieht für 3,95 € ganz gut aus, oder gibt es irgendeinen Grund, warum man>hier nichts dazu findet? Ist es noch so neu im Angebot von Pollin?
Ja, geil net.
Display ohne Controller is Müll. Deswegen will das keiner.
Stefan K. hat eine simple Ansteuerung für solche Displays gebaut,
basierend auf Code von Benedikt:
Beitrag "Ultra-einfacher Lowcost LCD Controller 320x240 im Textmodus"
Grössere Controller wie der Dragonball von Freescale, der z.B. in
älteren Palms verbaut ist (und auf dem uCSimm), haben Ansteuerung für
solche LCDs oft onboard.
Matthias Sch. schrieb:> Stefan K. hat eine simple Ansteuerung für solche Displays gebaut,> basierend auf Code von Benedikt:
Was nur leider für dieses LCD von Pollin gar nix bringt, weil das
farbig ist und RGB-Daten erwartet. Da kommt bei einer Spar-Ansteuerung
nur noch bunter Pixelbrei raus.
XL
Richtig, die RGB Codierung in drei aufeinanderfolgenden Bytes für ein
Pixeltriplett ist das große Problem. Ich bin mir nicht sicher, wie man
diesen Modus nennt, aber nach meinen bisherigen Recherchen ist dies ein
selten unterstützter Modus - selbst Mikros mit integriertem
Displaycontroller wie z.B. der i.Mx23 (Freescale) scheinen ihn nicht zu
beherrschen. Ein ATMega ist wahrscheinlich zu schwach, wenn er auch noch
diese Vorsortierung der Daten übernehmen soll.
Bleibt eigentlich nur noch ein FPGA, oder ein dedizierter
Displaycontroller von Seiko Epson. Beide Lösungen machen das
Gesamtsystem dann allerdings preislich unattraktiv.
Mit dem Timing Diagramm kann ich nichts anfangen. Habe ich so noch nicht
gesehen.
Nach einem kurzen Blick auf "Contrast Ratio" und "Brightness" habe ich
den PDF-Betrachter dann auch wieder geschlossen. Blickwinkelabhängigkeit
geht noch halbwegs aber CR=15 und Helligkeit von 45 cd/m^2 sind
unterirdische Werte. Schade um die Rohstoffe.
Sebastian schrieb:> Richtig, die RGB Codierung in drei aufeinanderfolgenden Bytes für ein> Pixeltriplett ist das große Problem.
Nein nein, es sind drei aufeinander folgende Bytes für ein Pixel-OKTETT.
Das macht die Sache doch schonmal deutlich einfacher. ;o)
> Ich bin mir nicht sicher, wie man> diesen Modus nennt
Vermutlich irgendwas mit "packed" im Namen.
> Ein ATMega ist wahrscheinlich zu schwach
Naja, das kommt natürlich darauf an, was man erreichen will und wie man
es erreichen will. Grundsätzlich hilft Speicher, sowohl RAM als auch
Flash, um möglichst viel Zeug in vorberechneten Tabellen halten zu
können, desto weniger muß der eigentliche Framebuffer rechnen.
Nehmen wir mal an, wir wollen eine Textausgabe mit 8x8 Zeichensatz und
jeweils Vorder- und Hintergrundfarbattribut pro Zeichenposition, wobei
wir der Einfachheit halber mal die Farbattribute in einem Byte
speichern, obwohl dabei zwei Bits unbenutzt bleiben, wir also insgesamt
ein Achtel des Bildwiederholspeichers ungenutzt verschwenden. Macht für
den Bildwiederholspeicher erstmal (320*240*2)/(8*8)=2400 Bytes RAM. Geht
schonmal, ab Mega644 aufwärts.
Aus diesem Bildwiederholspeicher müssen wir also pro 8 Pixel erstmal
zwei Bytes (mit 14 relevanten Bits) lesen, daraus dann irgendwie drei
Bytes machen und die dann ausgeben. Wir brauchen für das "irgendwie"
wohl zwei Tabellen, die erste ist der allseits beliebte 8x8 Zeichensatz
mit 2048 Bytes, dazu kommt dann noch eine kleine Tabelle mit
2^14*3=49152 Bytes Umfang, insgesamt also 51200 Bytes. Ja warte mal, das
paßt ja auch ab Mega644 aufwärts, die 6 restlichen k sollten für den
Code eines Framebuffers und eines einfachen Textterminals wohl reichen.
Also lohnt es, über das Timing nachzudenken. Also tun wir das mal, der
Code für ein Pixeloktett muß nach obigem Ansatz mindestens folgendes
machen:
loop:
mov ZH,CSLB ; 1 untere drei Bits des Zeilenzählers+OffsetH Zeichensatz
ld ZL,X+ ; 2 Zeichencode aus Framebuffer holen
lpm ZL,Z ; 3 Pixeldaten aus Zeichensatz holen
ld ZH,X+ ; 2 Farbattribute aus Framebuffer holen
lpm TMP,Z+ ; 3 erstes Byte zur Ausgabe aus der Tabelle holen
out PORT,TMP ; 1 ausgeben
lpm TMP,Z+ ; 3 dasselbe noch zweimal
out PORT,TMP ; 1
lpm TMP,Z+ ; 3
out PORT,TMP ; 1
dec CCNT ; 1 Zeichenzähler behandeln
brne loop ; 2 Schleife schließen
;--
;23
Unter 23 Takte für 8 Pixel geht also (ohne loop unrolling) garnix. Sagen
wir mal, wir rollen die Schleife einmal aus und runden etwas auf, damit
wir genug Spielraum für die restlichen Aufgaben haben (Alignment der
Ausgabe zu CL2 aus einem Timer und das Handling von CL1,FLM und M), dann
sind wir bei 48 Takte für 16 Pixel. Dazu kommt dann der Overhead für die
Zeilengeschichte im Interrupt, sagen wir mal großzügige 150 Takte dafür.
Naja, der Rest ist Klippschulmathetik:
Eine Zeile sind (320*48)/16+150=1110 Takte, bei 20MHz Takt maximale
Zeilenfrequenz also irgendwas bei 18kHz. 240 Zeilen sind auszugeben,
kommen wir also etwa bei 75Hz maximale Framerate an.
Das ist weit unter der im Datenblatt angegebenen minimalen Framerate von
120Hz. Allerdings bin ich nicht sicher, wie ernst man diese Angabe
nehmen sollte, denn erstaunlicherweise gibt es keine adäquaten
Untergrenzen für CL1, CL2 oder M. Meiner Meinung nach ist es sehr gut
möglich, daß das Display auch mit 60Hz noch problemlos läuft.
Genau weiß man es aber natürlich erst, wenn man es ausprobiert hat.
Irgendeinen Grund gab es vielleicht doch dafür, die Framerate derart
nach unten zu begrenzen.
Sudo schrieb:> Hat jemand von euch Ahnung ob man das Ding an nem Raspberry zum Laufen> kriegt?
Ziemlich sicher nicht. Der Raspberry Pi hat eine HDMI- und eine
Composite-Video-Schnittstelle, an die Displays mit entsprechender
Signalaufbereitung angeschlossen werden können. Zusätzlich hat er eine
MIPI DSI-Schnittstelle, aber dafür bräuchte man einen DSI-Controller,
der DSI auf das Protokoll dieses Displays umsetzt (was nicht existieren
dürfte).
I/O-Leitungen, um irgendwas per Bitgewackel zu machen, hat der Raspberry
Pi praktisch keine, und damit ist er zur Ansteuerung so einer
Displaygurke also komplett unbrauchbar.
Möglicherweise unterstützt der neue, gerade angekündigte
Displaycontroller von FTDI das spezifische Protokoll des
Pollin-Displays, aber über den ist noch nicht allzuviel bekannt, und die
Serienproduktion wird auch erst irgendwann im Laufe des Jahres
angefahren, so daß das Ding wahrscheinlich erst in einem Jahr oder so
hierzulande erhältlich sein dürfte.
Rufus Τ. Firefly schrieb:> I/O-Leitungen, um irgendwas per Bitgewackel zu machen, hat der Raspberry> Pi praktisch keine, und damit ist er zur Ansteuerung so einer> Displaygurke also komplett unbrauchbar.
Hm, also er hat doch erstmal 8 GPIOs, dann noch 2 Pins für I2C und 5 für
ISP, die man z.B. mit wiringPi
(https://projects.drogon.net/raspberry-pi/wiringpi/) auch direkt
ansteuern können soll. Die 15 könnten doch reichen. Habs aber nur
gelesen und selber noch keine Erfahrungen damit gemacht.
Nach diesem Artikel:
http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/
wird wiringPi wohl zu langsam sein. Wenn man mit direkter C
Programmierung ungefähr 20 MHz Rechteck ausgeben kann, heißt das
allerdings noch nicht, daß es möglich ist, ein ganzes Datenwort aus dem
Speicher mit der gleichen Gewschwindigkeit auf mehrere Portleitungen zu
schreiben.
Selbst wenn es klappt, alle benötigten Portleitungen auf einmal mit ca.
20 MHz zu beschreiben, könnte mit höherer Prozessorauslastung das Timing
leiden. Und man will mit dem Board ja eigentlich mehr tun, als bloß ein
Display ansteuern.
Ein Versuch kann nicht schaden, Anwendbarkeit in der realen Welt ist
nicht garantiert.
c-hater schrieb:> Unter 23 Takte für 8 Pixel geht also (ohne loop unrolling) garnix...
Naja, wenn Du noch auf die LPMs verzichtest wird das schon noch
schneller, Du hast ja 32 Register :)
Was ich auf Anhieb problematischer finde sind die vielen
Versorgungsspannungen und das Flachbandkabeldings.
Philipp schrieb:> Hm, also er hat doch erstmal 8 GPIOs, dann noch 2 Pins für I2C und 5 für> ISP, die man z.B. mit wiringPi> (https://projects.drogon.net/raspberry-pi/wiringpi/) auch direkt
Das Timing des Displays erwartet alle 66ns ein Datenwort das aus den
Pixeln aus dem Speicher zusammengeschoben werden muss. Heißt 16MHz. Oder
man baut den Pixelspeicher gleich richtig auf, dann muss man nur mit
16MHz die Daten auf den Port zur Verfügung stellen und dann das Timing
auch noch richtig erzeugen. Nicht unkomplex, in SW sollte da ein
Vielfaches an 16MHz Instuktionszykluszeit zur Verfügung stehen.
rgds
Wenns etwas teurer sein darf, bekommst du für 10EUR und 10 Tage
Wartezeit ein 320x240 LCD mit netten SPI Interface + touch + 3,3 V reg:
Beitrag "ili9320 spi tft 320x240"
Da kann auch ein kleiner mega8 noch andere, wichtigere Dinge nebenbei
machen...
und wozu?
Leute, das hier sind alles ziemlich winzige Displays, nicht mal 3 Zoll
groß und dabei 320x240 Pixel. Nochwas: bei STN-Displays hat man nur
jeweils 1 Pixel für R, G und B. Das sind nur 3 Bit, also 8 Farben und
wenn man mehr haben will, muß man von Frame zu Frame quasi PWM machen.
Langer Rede kurzer Sinn: Solche Displays lohnen sich selbst für
fanatische Bastler NICHT. Da ist es wesentlich besser, sich ein 4.3" TFT
mit 480x272 zu kaufen (z.B. per ebay als Ersatzteil irgendwelcher
Playstations o.ä) und dafür 18 Euro für's TFT und nochmal 2.50 für den
Foliensteck zu blechen. Ansteuern kann man die dann mit nem LPC2478 o.ä.
oder mit nem CPLD nebst RAM, eines mit 128 MC sollte gerade ausreichen.
Ist ein besseres und lehrreicheres Bastelobjekt.
W.S.
