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
:
Bearbeitet durch User
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
Damit du auch mal was anderes siehst als STM ;-) https://hbe-shop.de/Art-2218565-NXP-LPC4357-K43WQA-KITEVALBOARD-LPC4357-LCD-K430WQA Das is super und hat alles dabei was du brauchst.
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.
http://de.mouser.com/ProductDetail/4D-Systems/4DCAPE-43/?qs=sGAEpiMZZMt%2fSAlJwb45898SBbqNw4b7 http://de.mouser.com/ProductDetail/BeagleBoard-by-CircuitCo/BB-BBLK-000/?qs=sGAEpiMZZMs022Iw%2foIyCxWBXUznn0zI
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
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.