Hallo zusammen,
ich bin grad auf der Recherche zur Ansteuerung eines 320x240
TFT-Displays. Dazu bin ich bei ST fündig geworden und möchte einen
STM32F103 einsetzen.
In meiner Anwendung muss ich ein Menü realisieren und darin wenige
kleine Grafiken anzeigen.
Jetzt habe ich dazu eine grundsätzliche Frage. Ich habe gesehen, dass
man das TFT direkt ansteuern kann.
Dazu habe ich mir die vorgehensweise mal angeschaut.
Darin ist bei einem TFT immer von Frame-Buffer die Rede und von
Refresh-Zeiten.
Ich möchte das Display im 565-RGB-Modus ansteuern, das heißt ich brauche
320x240x2Byte Framebuffer also 153.6kByte.
In diesem Zusammenhang ist immer wieder beim TFT von refreshen die Rede.
Was bedeutet dieses refreshen? Heißt dass, ein stehendes Bild oder ein
stehender Menü-Eintrag muss zyklisch immer wieder in den Framebuffer
geschrieben werden oder gilt dies nur, wenn neue Daten in den Buffer
geschrieben werden müssen.
Oder muss vielleicht jedes Pixel immer wieder zyklisch geschrieben
werden? Oder hat das Display eine Art Speicher, der die Bilddaten nach
einmaligem Senden hält?
Wenn ich nur neue Daten schreiben muss, wenn ich was neues Darstellen
will, dann hält sich die Arbeit ja in Grenzen, was das Beschreiben des
Framebuffers betrifft.
Weil der Framebuffer ja 153.6 kByte groß sein muss, reicht das interne
RAM ja nicht aus, d.h. ich muss extern ein beispielsweise ein SRAM
anschließen und wenn ich Grafiken habe, diese in einem weiteren Speicher
(Flash-Speicher oder micro-SD) ablegen. Ist dies Ausführung soweit
richtig?
Würde mich über eure Unterstützung freuen.
Grüße
TFT-Newbie
Hallo,
> In diesem Zusammenhang ist immer wieder beim TFT von refreshen die Rede.> Was bedeutet dieses refreshen?
Ein TFT merkt sich nichts. Du musst dem 60 Bilder pro Sekunde schicken,
ob die sich nun ändern oder nicht.
> Weil der Framebuffer ja 153.6 kByte groß sein muss, reicht das interne> RAM ja nicht aus, d.h. ich muss extern ein beispielsweise ein SRAM> anschließen und wenn ich Grafiken habe, diese in einem weiteren Speicher> (Flash-Speicher oder micro-SD) ablegen.
Ja. Im einfachsten Fall hältst du im Speicher eine Kopie des
darzustellenden Bildes und sendest das ständig ans TFT. Wenn du dadrin
rumschreibst, während du es ausliest, bekommst du Tearing-Effekte - bei
Animationen möchtest du also zwei Kopien.
> Ist dies Ausführung soweit richtig?
Es ist auch möglich, den Framebuffer erst beim Auslesen aus Einzelteilen
zusammenzubauen ("compositing").
Grafikcontroller mit eigenem Framebuffer speichern meist eine oder zwei
Kopien selbst. Der Mikrocontroller braucht dann weder viel Speicher noch
viel Speicherbandbreite.
Gruß,
Svenska
Hi TFT-Newbie,
wenn du keine schnellen bewegten Sachen anzeigen willst,
dann nimm ein Display mit internem Grafik-RAM
damit sparst du dir das RAM in der CPU (oder ein externes RAM)
das Display-RAM ist dann genausogroß wie das Display
(also z.B. 240x320x16bit) und speichert die Grafik-Daten
dann muss du nichts "refreshen" sondern das was du einmal ins
Display-RAM reinschreibst wird angezeigt, bis du was anderes
reinschreibst
anbieten würden sich da Displays mit ILI9341, SSD1289, ST7783 Chip
die arbeiten alle nach dem gleichen Prinzip
und zu den Bildern...wenn die nicht alzu groß sind,
passen sie vielleicht ins Flash der CPU
Gruss Uwe
Hi,
TFT-Newbie schrieb:> In diesem Zusammenhang ist immer wieder beim TFT von refreshen die Rede.> Was bedeutet dieses refreshen? Heißt dass, ein stehendes Bild oder ein> stehender Menü-Eintrag muss zyklisch immer wieder in den Framebuffer> geschrieben werden oder gilt dies nur, wenn neue Daten in den Buffer> geschrieben werden müssen.
Also ich fang am besten mal von vorn an. Du musst 320 Pixel pro Zeile
und 240 Pixel pro Frame in einen reserierten Speicherbereich schreiben.
Dieser reservierte Speicher ist der Framebuffer. Ein Frame ist
gleichbedeutend mit einem Bild (Frame=Bilderrahmen ;-) ) Die Größe eines
Frames hast du schon richtig berechnet. Da ein Frame meistens nicht in
den internen Speicher passt, wird ein externer Speicher für diese
Aufgabe verwendet. Üblicherweise werden dafür SDRAM benutzt. Um ein
flüssigeres Bild oder Menü auf dem TFT darzustellen, können auch mehrere
(üblicherweise 3) Bereiche im Framebuffer für je einen Frame reserviert
werden. Diese Bereiche werden dann bei jedem refreshen abwechselnd dem
LCD Controller mitgeteilt. Stichwort: Multibuffering.
Bei einem TFT ist im Datenblatt eine Refreshrate angegeben -
üblicherweise 60Hz, das bedeutet, dass 60 mal in der Sekunde ein neuer
Frame vom LCD Controller zum Display geladen werden muss. Bei den ARM
µCs braucht man lediglich das Bild in den reservierten Speicherbereich
im Framebuffer zu schreiben und der LCD Controller holt dann
selbstständig über DMA die Daten automatisch ab und schiebt sie über die
RGB Leitungen zum TFT.
Auch wenn du das selbe Bild ein paar Minuten oder länger im TFT anzeigen
willst, dann musst du den selben Inhalt 60 mal die Sekunde immer wieder
refreshen.
Man nimmt SDRAM für den Framebuffer, da dieser billiger ist als SRAM.
Für die Bilddateien nimmt man in der Tat Flash-Speicher oder SD-Karten
mit FAT-Filesystem.
Viele Grüße
Martin
TFT-Newbie schrieb:> ich bin grad auf der Recherche zur Ansteuerung eines 320x240> TFT-Displays.
Kann es auch ein 4,3" 480x272 sein? Dafür findet man viele preiswerte
Angebote, die den Bildspeicher/Controller schon integriert haben.
Fertig mit Einbaurahmen gibt es auch welche:
http://www.digikey.de/product-search/de/optoelectronics/display-modules-lcd-oled-graphic/524918?k=ftdi%20eve> Dazu bin ich bei ST fündig geworden und möchte einen> STM32F103 einsetzen.
Es gibt zwar eine Applikation von STM (AN2790) für diesen µC +
TFT-Ansteuerung, wobei die Gesamtleistung m.E. nicht berauschend ist.
Für die Ansteuerung eines Displays mit eigenem Controller/Bildspeicher
reicht seine Leistung aber aus (s.o.).
> In meiner Anwendung muss ich ein Menü realisieren und darin wenige> kleine Grafiken anzeigen.
Wenn Du Deine Anforderungen auf 8 Bit/Pixel reduzieren könntest, hätte
ein STM32F407 genügend internes RAM fürs TFT und jede Menge
Prozessorleistung für einen schnellen Bildaufbau. Alternativ sind
STM32F427 mit 256kB RAM schon erhältlich, mit denen man auch ein QVGA
per DMA im 565-RGB-Modus betreiben kann.
Die Wiederholfrequenz von 60Hz ist ein Relikt aus Zeiten mit
FBAS-Signalen. Daher kommt auch das aus heutiger Sicht ungewöhnliche
Hsync/Vsync-Timing. Ab ca. 30Hz werden die Bilder flimmerfrei, wobei die
Displays auch noch mit 10 frames/s funktionieren könnten. Eine schnelle
Textausgabe wird dabei sehr ruckelig. Eher etwas zum Spielen - oder
große Kunst!
Hallo Sxenska, Uwe, Martin,
vielen Dank für eure guten und langen Erklärungen :-).
Jetzt habe ich das ganze schon viel besser verstanden.
Ich habe mir in der Zwischenzeit mal ein Datenblatt eines TFT-Displays
und ein paar Application Notes von ST angeschaut.
Es gibt da eine AppNote (AN3241, STM32 QVGA TFT-LCD drive
Implementation) diese beschreibt die Ansteuerung wie ich sie vorhin mit
SRAM usw. beschrieben habe.
Darin werden die Signale VSYNC, HSYNC, DCLK + zusätzlicher SPI
verwendet. Das Display (CT05350dw0000t) hat einen HX8238 (TFT LCD Single
Chip Digital Driver) dieser besitzt kein RAM soweit ich erkennen kann,
das wäre dann der Fall, dass ich ständig refreshen müsste, richtig?
Wenn ich aber eine anderes Display nehmen würde, z.B. AM-240320MDTNQW
dieses besitzt einen ILI9320 (a-Si TFT LCD Single Chip Driver
240RGBx320 Resolution and 262K color) dann reicht es wenn ich die Daten
ins RAM des LCD-Controllers schreibe, ich hoffe auch richtig?
Dieses Interface mit den SYNC, CLK und SPI brauche ich das dann
überhaupt oder würde mir ein einfaches Interface mit RD, WR, CS, RS
reichen?
Ich hab mal bei dem ILI9320 nachgeschaut, der kann unterschiedlichst
angesprochen werden.
Soweit ich gelesen habe, nennt man das eine Interface RGB-Interface,
wann benutzt man dieses dann, bei bewegten Bildern?
Ich hab mir überlegt eher das mit GRAM zu nehmen und die benötigten
Bilder dann extern zu speichern und diese dann per DMA in den
LCD-Controller zu schieben. Dann habe ich relativ wenig Belastung, einen
Framebuffer brauche ich dann ja nicht (keine bewegten Bilder, nur andere
Menüebene oder einzelne Grafiken).
Ich hoffe ihr helft mir nochmal ein bischen :-).
Viele Grüße
TFT-Newbie
Du kannst aber auch ein BeagleBone Black mit dem aufsteckbaren
TFT-Displaymodul verwenden, wenns ein ARM von Texas Instruments sein
darf.
Da ist embedded Linux drauf.
TFT-Newbie schrieb:> Jetzt habe ich dazu eine grundsätzliche Frage. Ich habe gesehen, dass> man das TFT direkt ansteuern kann.
Frage dich doch zu allererst, was für einen µC du benutzen willst. Mein
Tip wären die ARM/Cortex-teile von NXP, die eine TFT-Ansteuerung bereits
auf dem Chip haben. Dazu noch ein einfaches SDRAM, 32 Bit breit und du
hast ne Hardware zusammen, die sowohl preisgünstig ist als auch
leistungsmäßig alle anderen Lösungen in den Schatten stellt, denn zum
"Grafik machen" kann man den Bildspeicher direkt ansprechen ohne
jegliche Verrenkungen.
W.S.
Hallo Martin,
ja, das mit der ST-Welt ist schon ganz in Ordnung ;-), weil ich da ne
gute Auswahl habe und preislich noch nichts besseres gefunden habe bei
größeren Stückzahlen.
Aber da hat ja jeder so sein eigenes Steckenpferd.
Hast du mir noch ne Aussage zum RGB-Interface oder eben dem einfachen
RD/WR-Interface, was bei welcher Anwendung eingesetzt wird?
Vielen Dank nochmal!
Gruß
TFT-Newbie
Hi W.S.,
den Controller hab ich schon rausgesucht STM32F103VE (Cortex-M3), die
neuen Cortex-M4 mit TFT-Controller sind doch eine Ecke teurer.
Für die Menüstruktur und einfache Grafiken wird es denke ich reichen.
Dann noch externen Speicher für die Grafiken, dann bin ich flexibel.
SDRAM kostet auch wieder was, möcht ich vermeiden.
Gruß
TFT-Newbie
Ok TFT Newbie,
gut wenn du dir schon genug Gedanken zu ST gemacht hast, dann will ich
da auch nicht reinreden. Zu W.S. seinem Vorschlag fällt mir auch nur
wieder das LPC4357-K43WQA ein. Das Ding ist für den Preis echt genial,
um in die ARM Cortex M4 Welt einzusteigen :-)
RGB Interface ist schneller da ein Pixel parallel und somit mit einem
Takt übertragen werden kann. Bei 32-Bit Übertragung und LCD-Controller
sind es sogar 2 Pixel pro Takt, die der LCD Controller ohne die MCU zu
belasten zum Display schiebt. Ich würde bei normalen Anwendungen
(Steuerungen und Menüdarstellung)immer auf RGB Interface setzen. Bei den
anderen seriellen Lösungen (mit den SPI-Controllern auf dem
Displaymodul) werden die einzelnen Bits hintereinander übertragen, was
ja grundsätzlich schon langsamer sein muss. Und das wichtigste bei
solchen Anwendungen ist die flüssige Darstellung ohne Ruckler.
Du könntest dir noch Gedanken machen, ob du eine LVDS Schnittstelle
verwenden willst, aber das sollte dich teurer kommen, da du
LVDS-Transmitter brauchst (ist nur von Vorteil, wenn du eine lange
Display-Zuleitung bis zum µC hast).
Was heißt denn bei dir "größere Stückzahlen" ? Bei größeren Stückzahlen
lohnt sich der Eigenbau.
RD/WR-Interface ist sch... für TFT ;-) Nimm RGB!
Falls du günstige Displays mit touch suchst, dann empfehle ich dir
www.orientlcd.com
die sind richtig günstig. Oder bei E*ay die günstigen SPI Displaymodule
(die werden aber nicht die schnellsten sein).
Vielleicht kann ja jemand an dieser Stelle seine Erfahrungen mit den
E*ay Modulen bekannt geben ;-) Würde mich brennend interessieren ;-)
Ein Cortex-M3 sollte für eine normale TFT Anwendung ausreichen.
DER VORTEIL bei NXP ARM-Controllern ist, dass sie die
emWin-Grafikbibliothek KOSTENLOS unterstützen :-) Diese Bibliothek ist
richtig genial. Ich weiß aber nich wie das bei ST läuft.
Ich beschäftige mich seit einer Weile mit NXP ARM Controllern und muss
sagen, dass ich begeistert bin. Aber ich höre mir auch gern Meinungen
und Erfahrungen von anderen an :-)
Nimm NXP und du hast alles was du brauchst :-) (die Grafikbibliothek ist
richtig einfach zu handhaben)
Hi Martin,
super Infos :-).
Ich hab noch zu wenig Erfahrung mit Displays bei ST-Controllern aber
wenn ich mich richtig eingearbeitet habe und ich vielleicht auch schon
etwas mehr weiß, sag ich dir Bescheid wegen der emWin-Bibliothek.
Ich bin bislang mit den ST-Cortex sehr zufrieden, hab auch schon kleine
Sachen mit dem STM8S gemacht und bin sehr gut gefahren mit der
Standardbibliothek und den günstigen Eval-Boards.
Bei den Seminaren kannst du sogar mehrere umsonst mitnehmen
(Discovery-Boards).
Ich wünsch dir ein schönes Wochenende und Danke nochmal für die Infos.
Grüße
TFT-Newbie
Guten Morgen,
ja stimmt. Die Discovery Dinger sind richtig günstig. Vielleicht
beschäftige ich mich auch mal mit denen, falls ich mal wieder Zeit habe
;-)
Wie willst du denn das TFT hardwareseitig anstecken? Frei verdrahten?
oder willst du ein Baseboard entwickeln und das Discovery drauf stecken?
Es gab hier im Forum (suche mal im "Markt") vor ein paar Wochen eine
Sammelbestellung für Discovery Boards, die ein 2,x"-TFT Display on-board
haben. Das ist vielleicht interessant für dich.
Viele Grüße
Martin
Hi Martin,
nein, ich werde das Display über einen entsprechenden Steckverbinder Zif
auf der Platine anbinden (eigene Hardware), muss ja auch noch das
Backlight mit Spannung versorgt werden.
Ein Touch-Controller mit 4 Touch-Tasten kommt auch noch drauf, den ich
seriell ansteuere.
Das Board sieht aber interessant aus, das bestellt ich mir vielleicht
trotzdem ;-).
Gruß
TFT-Newbie
Ich habe ein 240x320 TFT aus der Bucht:
Artikel: 190451748066
Das hat einen Controller und Touch-Controller mit drauf.
du musst das Bild also nur einmal ans Display schicken und dann nur noch
Änderungen vornehmen. Die Inbetriebnahme war ziemlich problemlos.
Ach ja, ich verwende lediglich einen Atmega64 für die Ansteuerung. Für
Text und Menü reicht der eigentlich, nur wenn man verschiedene
Schriftarten oder Bilder benutzen will wird der Flash-Speicher sehr
schnell zu klein.
Thomas
