Hallo! Wer kann mich mal aufklären? :) Und zwar geht es um LCDs. ______________________ 1. Es gibt uC mit integriertem "LCD Controller" Als Beispiel STM32F429. Dazu ein passender LCD mit ebenfalls einem Controller. Ich verstehe das so, dass die beiden Controller (uC und LCD Contr.) quasi eine gemeinsame Schnittstelle bilden. Aber man könnte ja den LCD Controller vin uC weglassen, und das LCD über normale IO Pins verbinden. Richtig? Wenn ja, warum macht gibt es uC mit LCD Controllern? _______________________ _______________________ 2. Es gibt ja noch die "industrie" LCDs. Die haben keinen Controller drauf. Ich habe hier z.B. ein von Hitachi. 7" 800x600. Kein Datenblatt, kein nix zu finden. Außer Ersatzdisplays bei alibaba.com :) Wie wird mit diesen LCDs umgegengen? (Vorausgesetzt Dattenblatt ist vorhanden). Kann man diesen auch mit den IO Pins des STM32 verbinden? ________________________ ________________________ 3. Bezieht sich auf 2: Ich habe schon oft die "dicken" Graphics Controller gesehen. Gleich daneben der Flash und SD- oder DDR-RAM. Warum nimmt man die Graph. Controller? Ich meine für welche Anwendungen? _________________________ Danke schön
Von welchem LCD redenb wir überhaupt? Es gibt die LCD, wie sie zb in einfachen Armbanduhren oder als Voltmeter verbaut werden, oder auch als Anzeigeelement zb im Aufzug. Im Grunde einfach nur ein LCD als Ersatz für 1 bis n 7-Segment-Anzeigen. Dann gibt es die Text-LCD. 1 bis 4 Zeilen. 16 bis 80 Spalten. Zb als Anzeigeelement im Kaffeeautomaten, damit der 'Bitte Geld einwerfen' hin schreiben kann. Und dann gibt es noch die dicken Brummer: grafische LCD, an denen jedes Pixel einzeln ein/aus schaltbar ist. Ja nach konkretem LCD reicht ein LCD-Kontroller von der Steuerung der Backplanes, über Textausgabe bis hin zu richtigen grafischen Prozessoren, die Linien und Kreise(Bögen) oder noch weiter gehende Funktionen im Controller anbieten. Und je nachdem, was du da hast, willst du die eine oder andere Aufgabe aus dem µC zum Controller hin auslagern.
:
Bearbeitet durch User
Danke für die Antwort. Es geht um die Grafik LCDs. Habe auch kein bestimmtes Beispiel, wollte mich nur mal informieren. Ich Datenblatt vom STM32F429I steht: "2.2.10 LCD-TFT controller The LCD-TFT display controller provides a 24-bit parallel digital RGB (Red, Green, Blue) and delivers all signals to interface directly to a broad range of LCD and TFT panels up to SVGA (800x600) resolution... " Was kann man damit also machen? Ein Video von der SD Karte abspielen geht wahrscheinlich schon gut. Aber wenn man eigene Grafiken, Kreise, Linien, flüßige Animationen haben will, dann braucht mal einen externen Grafikprozessor? Verstehe ich das richtig? Gruß
Wenn du 800x600 mit 16 Bit Farbtiefe und 25 fps darstellen möchtest, landest du bei etwa 23 MB/s, die du ununterbrochen in das Display pumpen musst. Das Timing muss exakt sein, Zugriffe auf den Bildschirmspeicher sollten nur zu bestimmten Zeiten erfolgen, etc. Mach das mal in Software auf einem Controller, der nebenher noch irgendwelche Regelkreise in Echtzeit ansteuern soll. Ein LCD-Controller nimmt dir diese Arbeit mehr oder weniger gut ab. Entweder, indem er das Display-Timing generiert und die Bilddaten (z.B. mit DMA) aus dem Speicher holt, oder indem er eine Kopie des Bildschirmspeichers bereithält. Animationen solltest du flüssig auch in Software erzeugen können, bei Bildern hängt das dann konkret davon ab, was du wie darstellen möchtest. Wenn ein 486er in der Lage ist, kleine AVIs ruckelfrei abzuspielen, dann sollte das ein moderner uC mit zehnfacher Geschwindigkeit auch hinkriegen können - falls er nicht schon damit beschäftigt ist, an den Displaypins zu wackeln.
Generell gilt: Wenn das LCD keinen Controller hat, brauchst du trotzdem einen. Ob es ein externer Chip, oder ein dedizierter Bereich innerhalb deines µC, oder auch ein einzelner µC ist, ist wurscht. Der Controller macht nix anderes, als dir die Möglichkeit zu geben, konfortabel das Display anzusteuern. Also anstatt (800x600) 480000 Pixeln eigene Werte zu geben, einfach zu sagen: mal mir einen grünen Kreis da hin. Schreib mir "abc" da hin. Welche Funktionen der Controller übernimmt, sagt du ihm entweder durch die programmierung, oder erfährst du aus dem Datenblatt des diskreten Controllers. Einen integrierten LCD-Controller wie im STM32F4 zum ansteuern eines Displays mit Controller zu benutzen macht wenig oder nur selten Sinn.
Die Bezeichnung "Controller" ist in diesem Kontext nicht eindeutig. Simple LCD-Gläser wie bspw. in Multimetern oder Taschenrechnern verbaut, brauchen im wesentlichen einen Treiber, der die 1-4 Backplanes und 1..n Segmente mit entsprechend abgestuften Spannungen versorgt. Diese Art LCD-Controller haben manche AVRs und PICs eingebaut. Grafik-LCD kommen dann in mindestens zwei Varianten: nur mit Treiber. Oder mit Treiber und Controller. Die Treiber sorgen dafür daß das Elektrodengitter mit den notwendigen Spannungen versorgt wird. Die Treiber selber werden seriell gespeist (im wesentlichen zur Verringerung der Leitungszahl) und müssen regelmäßig (50-60Hz) mit dem aktuellen Bildinhalt aufgefrischt werden. Displays dieser Kategorie erkennt man an Signalbezeichnungen wie FLM, CP, LOAD, PLINE, PFRAME etc. Diese Displays sind im Datenblatt des STM32F429 gemeint. Die zweite Sorte Displays hat zusätzlich zu den Treibern noch einen Controller an Board. Dazu zählen z.B. die HD44780 Textdisplays aber auch Grafikdisplays z.B. auf Basis des KS0108. Hier macht der Controller alles selber und der µC muß nur dann etwas tun, wenn er den Bildschirminhalt verändern will. Eine andere Art der letztgenannten Controller nimmt z.B. analoges Video (FBAS, RGB) entgegen. XL
Aha, ok. Dann ist dieses Display von dem zweiten Type, richtig? https://www.glynshop.com/erp/owweb/Daten/DSS/KOE/Products/Specifications/Active%20Displays/TX18D35VM0AAA-3%20-%20GLYN.pdf Wie realistisch wäre es, diesen direkt an STM32 anzuschließen, damit der uC noch was anderes nebenbei machen kann? Gruß
Marc schrieb: > Dann ist dieses Display von dem zweiten Type, richtig? > https://www.glynshop.com/erp/owweb/Daten/DSS/KOE/Products/Specifications/Active%20Displays/TX18D35VM0AAA-3%20-%20GLYN.pdf Ja. Wobei es etwas merkwürdig ist, daß im Timingdiagramm HSYNC und VSYNC gezeigt werden, die aber keinem Pin des Connectors zugeordnet sind. > Wie realistisch wäre es, diesen direkt an STM32 anzuschließen, damit der > uC noch was anderes nebenbei machen kann? Ich kenne den STM32F4 nicht. Aber typischerweise erfolgt die Displayansteuerung komplett im Hintergrund. Man widmet einfach einen Teil des RAM als Framebuffer und der LCD-Controller sorgt dafür, daß der RAM-Inhalt mit korrektem Timing auf das Display kommt. Beim Zugriff auf den Framebuffer-RAM durch die CPU kann es dann zu Kollisionen kommen, was sich in sporadisch längeren Zugriffszeiten bemerkbar macht. Jegliche Zeichenfunktionalität (male eine Linie von (x1,y2) nach (x2,y2) etc.) wirst du aber wohl in Software machen müssen. XL
Das Display von GLYN ist ein klassisches WVGA, also 800x480. Mit einem im µC eingebauten TFT-Controller kann man damit sehr wohl ne Menge anstellen. Allerdings ist es von seiner Pixelzahl her auch das größte, was man einem hier üblichen µC zumuten sollte. Mach dir mal die Rechnung: 800x480x ca. 40..50 Hz und pro Pixel 2 Byte, denn man will ja nicht mit 256 palettierten Farben herumeiern. Das muß über den Systembus und dabei sollte auch noch etwas für den normalen Datenverkehr übrigbleiben. Was die schwammige Formulierung "STM32" betrifft, so hab ich da ne klare Antwort: Vergiß es, solange du den bislang einzigen TFT-fähigen Typ nicht selbst kennst. Ja, mittlerweile ist ein STM32F4??? oder so angekündigt, quasi das künftige Flaggschiff von ST, der einen passenden Controller drin hat. Mit den kleineren STM's brauchst du es erst garnicht zu versuchen. Zweitens: Bei NXP gibt's schon seit Jahren entsprechende Controller. Angefangen hatte vor Jahren der LPC2478 und inzwischen geht es weiter mit pinkompatiblen Cortex M3 und M4 Typen. Deswegen verstehe ich es wirklich nicht, daß hier alle möglichen Leute immerzu nur auf den STM32 herumreiten. Drittens: Ohne schnellen und großen RAM hat alles keinen Zweck. Die einzige Lösung, die man bei den hier üblichen µC sinnvoll dafür nehmen kann, ist SDRAM und zwar 32 bittig, damit der Systembus nicht völlig verstopft wird. Sinnvolle Größe ist 8 oder 16 MB, weil sich kleiner Chips nicht lohnen und man sie inzwischen kaum noch bekommt und weil größere Typen mit 32 Bit Datenbreite kaum zu kriegen sind. Auch für SDRAM gibt es bei den NXP-Typen den passenden externen Busanschluß. Bei den STM32 Typen findet man sowas nur bei den allerneuesten Versionen. DDR-RAM und insbesonder mobile DDR wäre ja recht nett, wird hardwareseitig aber von µC im hier gehandhabten Bereich (unter 200..300 MHz) nicht unterstützt. So. alles Klaro? W.S.
Darf ich meine Frage zum Thema hier auch stellen? ;-) Ich mache gerade etwas Änhliches, bzw. versuche mich erst in das Thema reinzufuchsen. Ich habe schon viel mit den uC gemacht, auch GrafikLCDs schon angesteuert, aber die etwas einfacheren. Programmierkenntnise sind natürlich auch ordentlich vorhanden. Was mir fehlt, ist halt der Grundwissen auf dem neuen Thema. Und zwar: Ich habe hier ein fertiges Gerät, das u.A. auch einen (scheinbar) Indunstrie LCD beinhaltet. Die Elektronik für das Gerät möchte ich selbst machen, aber das kommt noch viel später. Erst mal muss ich ein paar Fragen klären, um komplexibilität etwas genauer einzuschätzen. Hardware werde ich selbst machen, desswegen muss ich wissen wie alles funktioniert. Dann kann ich mich an die programmierung dran machen. Erste Frage: SDRAM Wie wird das benutzt und wozu? - Über 8,16,32 Bit breite Leitung. Dort werden die Displaydaten zwischengelagert. Soviel kann ich auch selber beantworten, aber das reicht mir noch nicht. Ich brauche mehr technische infos. Die Grafik (Zeichen, Kreise, Linien usw.) wird beim Programmstart vom uC generiert und dann im SDRAM gespeichert und bei Bedarf aus dem SDRAM herausgeholt? Oder werden die Daten unmittelbar vor der Benutzung generiert, ins SDRAM geschrieben und gehen dann quasi sofort zum LCD? Danke Grüße Alex S.
Alex S. schrieb: > und bei Bedarf aus dem SDRAM > herausgeholt? Nein, nicht bei Bedarf, sondern ständig. 'Dumme' Displays, wie das o.a. brauchen einen kontinuierlichen Strom von Daten, die aus einem Framebuffer, also deinem SDRAM gelesen und ans Display geleitet werden. Das Signal wird dann mit Pixelclock an die R,G, und B Datenleitungen gelegt. Es gibt Displays, bei denen Signale wie HSync (SOL = Start of Line) und VSync (FLM = First Line Marker) extra benötigt werden und andere, die eine Kombination daraus brauchen, wie das DTMG Signal des LCD hier im Thread. Einige ältere LCD benötigen auch noch ein AC Signal, das für ein internes Refresh oder obere und untere Bildhälfte benutzt wird. Ein MC wie z.B. der Freescale Dragonball (oder viele grössere LPC) hat dazu ein konfigurierbares LCD Interface, indem Dimensionen, Polarität der Signale, Anfang des Framebuffers, Bittiefe usw. festgelegt werden und dann an den dazu vorgesehenen Ports die Signale erscheinen. Wenn dein MC ein solches Modul hat, kannst du ein 'dummes' Display anschliessen. Wenn nicht, bleibt dir nur eines mit internen 'klugen' Controller, wie z.B. der HD44780 Standard. Auch die meisten LCD mit I2C Bus oder SPI haben einen 'klugen' Kontroller und verwalten das LCD selber bzgl. Refresh, Display RAM usw.
:
Bearbeitet durch User
Alex S. schrieb: > Die Grafik (Zeichen, Kreise, Linien usw.) wird beim Programmstart vom uC > generiert und dann im SDRAM gespeichert und bei Bedarf aus dem SDRAM > herausgeholt? > Oder werden die Daten unmittelbar vor der Benutzung generiert, ins SDRAM > geschrieben und gehen dann quasi sofort zum LCD? Stell es dir so vor, wie bei den alten Röhren-Fensehern. Ein Elektronenstrahl wandert von links nach rechts, von oben nach unten. Und während er das tut muss ständig und laufend zum richtigen Zeitpunkt der Strahl moduliert werden, so dass die richtigen Pixel auch die richtigen Farben haben. Auch wenn das technisch mit LCD ein wenig anders funktioniert und es den klassischen Elektronenstrahl nicht mehr gibt, am Prinzip hat sich nichts verändert. Genau dazu braucht man den Controller: damit er sich um diese Timing-Sache kümmert. Was dann im SDRAM steht, welches laufend und kontinuierlich ausgelesen wird, um die richtigen Pixel am LCD in der richtigen Farbe aufleuchten zu lassen, das ist eine weitere Geschichte, die aber unmittelbar nichts damit zu tun hat. Kurz gesagt: Für dein Programm ist dann dieses SDRAM die 'Anzeige-Fläche'. Wenn ein bestimmtes Pixel rot aufleuchten soll, dann wird im SDRAM das entsprechende Bit/Byte auf den zugehörigen Wert gesetzt. Beim nächsten 'Strahldurchlauf', leuchtet das dann auch durch den ständigen Ausgabemechanismus am LCD entsprechend auf.
Alex S. schrieb: > Die Grafik (Zeichen, Kreise, Linien usw.) wird beim Programmstart vom uC > generiert und dann im SDRAM gespeichert und bei Bedarf aus dem SDRAM > herausgeholt? Beim initialen Programmstart muß der µC vor allem erstmal den LCD- Controller konfigurieren. Also wieviel Zeilen/Spalten das LCD hat, wie Zeilen- und Bildwechsel zu signalisieren sind etc. Aber auch wie die Pixeldaten auf RAM-Adressen abgebildet werden. Das o.g. Display hat 5 Bit je Farbe, also 15 Bit pro Pixel. Die kann man jetzt wahlweise gepackt in 2 Byte RAM ablegen. Oder man nimmt 3 Bytes (je eins für R,G,B) und läßt jeweils 3 Bits ungenutzt. Evtl. läßt man sogar ein 4. ungenutztes Byte zu, so daß jetzt jedes Pixel 4 Byte groß ist. Das mag wie Verschwendung aussehen, aber es erleichtert erheblich die Umrechnung von (x,y) Pixelkoordinaten in die zugehörige Adresse im Framebuffer (Disclaimer: ich weiß nicht ob der STM32F4 LCD-Controller diese Auswahl bietet, aber andere LCD-Controller tun das) > Oder werden die Daten unmittelbar vor der Benutzung generiert, ins SDRAM > geschrieben und gehen dann quasi sofort zum LCD? Der Framebuffer ist permanent. Aus Sicht des µC ist der Framebuffer das Display. Der LCD-Controller liest den Framebuffer ständig und ca. 50 Mal pro Sekunde aus und schiebt die Daten aufs Display. Wenn der µC den Framebuffer nicht verändert, dann zeigt das Display ein statisches Bild. Für eine Animation muß der µC den Framebuffer (oder zumindest einen Teil davon) regelmäßig verändern. XL
Kennt jemand einen gut erhältlichen Displaycontroller für solch ein 800x480 Display (18/24 Bit RGB)? Danke
Schließe mich der Frage gerne an. Diesen habe ich schon mal als Option: MB91590 von Spansion. Gibt natürlich noch dutzend andere. Grüße Alex S.
Alex S. schrieb: > MB91590 von Spansion. Das ist doch ein 32Bit µC mit integrierten GDC, oder? Ich dachte eigentlich eher an etwas wie den SSD1963.
Jürgen F. schrieb: > Kennt jemand einen gut erhältlichen Displaycontroller für solch ein > 800x480 Display (18/24 Bit RGB)? Nein und Ja: Wenn du unbedingt einen dedizierten Grafikcontroller haben willst, dann schau dich bei den Grafikcontrollern von Fujitsu um - jaja MBxxxx oder lyrischer mit Blumen-namen wie Lime, Orchid und so. Aber ICH kann dir von sowas nur abraten, diese Dinger sind zu komplex. Stattdessen kan ich dir nur zu der schon weiter oben von mir genannten Lösung raten. Das ist das Zweckmäßigste und man kann es auch als Bastler noch stemmen. Axel Schwenke schrieb: > Das o.g. Display hat 5 > Bit je Farbe, also 15 Bit pro Pixel. Die kann man jetzt wahlweise > gepackt in 2 Byte RAM ablegen. Oder man nimmt 3 Bytes (je eins für > R,G,B) und läßt jeweils 3 Bits ungenutzt. Nein. Dieses Display gehört zu der Standard-Linie von Glyn mit vereinheitlichter Schnittstelle und es hat 18 Farbbits, also 256K Farben. Für einen µC ist das zuviel, da sollte man auf 65K Farben reduzieren, was die TFT-Controller in den LPCxxx auch ermöglichen. Üblich ist das microsoftsche 565 Format: 5 blau, 6 grün, 5 rot. Die jeweils übrigbleibenden LSB's legt man entweder auf GND oder schließt sie parallel zu den MSB's der jeweiligen Farbe an. Insgesamt macht das 2 Bytes pro Pixel, die dann parallel als 16 Bit Muster zum Display geschickt werden. Eine 3 Byte Option gibt es m.W. bei keinem µC. Allenfalls eine 4 Byte Variante, die aber auf dem Systembus einen derart hohen Traffic erzeugt, daß kaum einer sie benutzt. Von dem palettierten 8 Bit Kram kann man nur dann was haben, wenn man sowas wie ein Navi programmiert, bei dem nur Landkarten dargestellt werden. Die kommen nämlich mit 40..50 Farben aus und der Rest ist dann fakultativ. Alex S. schrieb: > Erste Frage: > SDRAM Wie wird das benutzt und wozu? > - Über 8,16,32 Bit breite Leitung. Dort werden die Displaydaten > zwischengelagert. Sinnvollerweise NUR 32 bittig. Denke dran, daß der Video-RAM im Hauptspeichervolumen liegt und über den externen Busanschluß gelesen werden muß, bevor die Daten über das Display-Interface zum TFT gehen. Der TFT-Controller versucht ja schon, die Sache so effektiv wie möglich zu machen, also 32 bittig im Burst lesen, zwischenspeichern und dann zur rechten Zeit 16 bittig zum Display zu schicken. Trotzdem ist das eine ziemliche Buslast und nur durch einigermaßen schnelle SDRAM's zu packen. Mit statischen CMOS-RAM's wird es viel schwieriger, es gibt zwar "schnelle" mit 10 ns Zugriffszeit, aber das ist insgesamt lahm ggü. SDRAM. > Soviel kann ich auch selber beantworten, aber das reicht mir noch nicht. > Ich brauche mehr technische infos. Lies die Doku zu den Controllern, die für dich in Frage kommen und die Doku zu dazu passenden SDRAM's. Wenn du damit ernsthaft anfangen willst, dann schreib das in aller Deutlichkeit hier. Ich könnte dir die Schaltung meines Eval-Boardes zum LPC2478 heraussuchen. Das ist zwar schon ein paar Jahre alt, aber Footprint und damit Schaltung zum SDRRAM hin sind gleich zu den neueren µC von NXP. > Die Grafik (Zeichen, Kreise, Linien usw.) wird beim Programmstart vom uC > generiert und dann im SDRAM gespeichert und bei Bedarf aus dem SDRAM > herausgeholt? Was auf dem Bildschirm erscheinen soll, muß dein µC schon selber malen. Dazu braucht man Programmteile, die Pixel setzen, Linien ziehen, Bereiche füllen, Texte darstellen, Bilder anzeigen usw. können. Sowas kann man ein GDI nennen. Wie sowas im einfachsten Falle aussieht, kannst du hier in der Lernbetty nachschauen. Dort hat es ein einfaches GDI für ein fast monochromes Display (4 graustufen), aber das Prinzip ist natürlich auf 65K Farben auch anwendbar. Und nochwas: So ein SDRAM ist ausreichend groß, um ihn nicht nur als Video-RAM zu gebrauchen. Man kann dort auch Programme hineinladen und ausführen, sonstige Daten speichern, den Heap anordnen usw. 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.