Hallo zusammen, hat jemand das Display MC28G03A (Pollin Nr. 120 817) schon mal ausprobiert? Link: http://www.pollin.de/shop/dt/MjgxOTc4OTk-/Bauelemente_Bauteile/Aktive_Bauelemente/Displays/LCD_Modul_mit_Touch_und_LED_Beleuchtung_MC28G03A.html Datenblatt: http://www.pollin.de/shop/downloads/D120817D.PDF - 320 x 240 Pixel, Farbe - LED-Hintergrundbeleuchtung - Touch-Panel 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?
>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.
Hat jemand von euch Ahnung ob man das Ding an nem Raspberry zum Laufen kriegt?
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.
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.