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.
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
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.
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
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.
