Das angehängte Programm 'main.c' zeigt die Ansteuerung eines WQVGA-TFT-Displays mit 480x270 und 64 Farben/Pixel. Es wurde mit einer IAR-Kickstart Version für ARM auf einem STM32F4-Discovery-Board entwickelt. Als Display dient ein ET0430G0DH6. Die Anschlußbelegung findet sich hier: http://www.mino-elektronik.de/TFT-direct-drive/TFT-direct-drive.htm#tft-b Es soll kein "digitaler Bilderrahmen" neu erfunden, sondern gezeigt werden, wie mit wenig Aufwand und höchster Schreibgeschwindigkeit eine einfache Bedieneinheit beim STM32F4 implementiert werden kann. Die gezeigten Routinen können erheblich (>Faktor 2) optimiert werden. Um die Übersichtlichkeit nicht zu vermindern, ist auch die Abfrage des touch-screen entfallen. Für eigene Anwendungen muß sichergestellt sein, dass der Prozessor initialisiert ist und mit 168MHz läuft. Da bis auf ca. 1kB der zusammenhängende Speicher von 128kB belegt ist, sollte für den Stack und weitere Variablen das 64kB große CCM verwendet werden. Wenn nur ein QVGA-TFT verwendet wird, bleibt erheblich mehr RAM frei. Die Ausgabe zum Display erfolgt freilaufend ohne Timer über das FSMC-Interface, was mit der einfachen Beschaltung für weitere Verwendung blockiert ist. Mit ein bißchen Logik und einem 74VHC573 Latch, können per FSMC-Bus auch weitere Speicherbausteine (o.ä.) ext. angeschlossen werden. Mit der angehängten .hex-Datei kann man ohne großen Aufwand und ohne TFT die Beine vom µC wackeln lassen. Vsync (PD11) und Hsync (PD12) zeigen das Timing. Viel Erfolg!
Angehängte Dateien:
-
STM32F4-WVGA_TFT.JPG
140 KB
Sehr nett! Hast du eine gute und günstige Bezugsquelle? Weil 60€ bei reichelt is reichlich viel!
Im Prinzip müßte jedes 4,3" Display verwendbar sein; unter Umständen muß das Timing für Vsync und Hsync angepaßt werden. Meine Quelle für TFTs ist Glyn. Der Einzelpreis liegt derzeit bei ca. 35 € netto. Die EDT-Serie dort hat einheitliche 40-pol. Steckverbinder, weshalb QVGA und WQVGA einfach auszutauschen sind. Sicherlich gibt es hier auch Profis, die Dir genau sagen können, dass und wo in China alles nur max. die Hälfte kostet :-)
http://item.mobileweb.ebay.com/viewitem?itemId=251173169883&cmd=VIDESC würde dieses Display auch Funktionieren?
@m.n. Tolle Info!!! Seit einiger Zeit überlege ich mir, ob es Sinn macht einen einfachen Applikations-Kontroller für TFT zu entwickeln. Hintergrund: Zur Zeit arbeite ich noch mit S65-Displays Beitrag "The Siemens S65 132x176, 65536 color display with AVR" Der Vorteil des Display ist die einfache Ansteuerung über SPI, d.h. die Hardwareanforderungen sind sehr gering bzw. das Layouten sehr einfach. Mir ist klar, dass bei höherer Auflösung die Bildaufbauzeiten extrem ansteigen. Die Idee bzw. Lösung: Applications-Controller-TFT (ACTFT): Der Controller besitzt im einfachten Fall zwei Schnittstellen 1. eine serielle für die Applikation (SPI, I²C, RS232, CAN ...) 2. eine parallele für das Display (8Bit, 16bit, 24bit) Der ACTFT (z.B. ein STM32FXXXX) arbeit als Interpreter, der einfache Grafik Kommandos entgegennimmt (Init, SetPixel, ReadPixel, DrawLine, DrawCircle, DrawBitmap, Fill, etc.) oder sogar komplexe Kommandos ausführen kann (Menu, CheckBox, Animate, GUI...) Natürlich können die Befehle auch von einer PC-Simmulation ausgeführt werden (einfache Simulation, Entwicklung und Design) Ich denke, damit lassen sich alle Anwendungsfälle, die nicht extrem zeitkritisch sind erfüllen. Die Kommandos sind Hardware (TFT) unabhängig und somit universell einsetzbar. Einzig der ACTFT sollte die gängigen TFT-Ansteuerungen implementiert haben. Frage: Gibt es so was als preiswerte Lösung bereits (davon gehe ich aus)? Hat jemand interesse an so einem Projekt?
tft schrieb: > http://item.mobileweb.ebay.com/viewitem?itemId=251... > würde dieses Display auch Funktionieren? Das sieht gut aus und müßte ohne Programmänderung funktionieren. Und, wie oben schon vermutet, zum 'Profipreis' :-)
Wenn du mit 50 MHz oder so (weiss nicht mehr wo die Obergrenze war) in das s65 Display schiebst ist der Bildaufbau au h recht flott. Ein eigener Controller für größere displays? Dann lieber gleich einen Controller nehmen der displayinterface und m besten noch dram Interface hat. Dann ist man zwar schnell beim embedded PC, aber das wäre die professionelle lösung.
m.n. schrieb: > Es soll kein "digitaler Bilderrahmen" neu erfunden werden, Damit wollte ich ausdrücken, dass es mir nicht um die Eierlegendewollmilchsau geht, die langsam bunte Bilder zeichnet. Dafür reichen Papier und Buntstifte. Es geht auch nicht darum, einen 'embedded PC' nachzuempfinden. Mir geht es darum, an einen leistungsfähigen µC mit hinreichend RAM ein TFT-Display sozusagen als 'Abfallprodukt' anzuschließen, wobei weder Kosten noch Leistungseinbußen entstehen. Ein Beispiel hatte ich neulich gezeigt: Beitrag "reziproker Frequenzzähler mit STM32F4Discovery" Alternativ erlaubt der STM32F4 (wie auch RX610,RX62 +++) den Aufbau kompletter Steuerungen mit Schrittmotoren, Inkremenetaldekodern, ADCs, DACS, ... usw.. Das TFT ist dabei Mittel zum Zweck und nicht Selbstzweck!
@artjomka Danke für deinen Beitrag. Eigentlich geht es mir es nicht um die "Bildaufbaugeschwindigkeit" sondern um eine einheitliche Schnittstelle und darum, dass nicht jedesmal die Firmware wegen "Bildschirmroutinen" umgeschrieben werden muss. Beispiel: Ich habe eine Hardware und als Anzeige dient mir das Display XYZ, welches über SPI angebunden wird. Bei einem Displaywechsel möchte ich meine bestehende Hardware nicht ändern (z.B. parallel anstatt SPI). Auch möchte ich meine Firmware nicht anpassen müssen (z.B. anderer TFT-Controller). All dies soll der ACTFT übernehmen. Also: Fall 1: Das Display XYZ ist abgekündigt (zB. S65) Fall 2: Möchte ein anderes Display verwenden z.B. höhere Auflösung
Der Gedanke mit dem DMA und FSMC vom STM32F4 schwirrte mir auch vor kurzen durch den Kopf. Stört es beim STM32F4-Discovery nicht, daß FSMC_NWE auf der USB-Overcurrent-LED liegt ? Gruß Dennis
Dennis Heynlein schrieb: > Stört es beim STM32F4-Discovery nicht, daß FSMC_NWE auf der > USB-Overcurrent-LED liegt ? Eigentlich nicht! Dennoch hatte ich schon vor langer Zeit R50 durch auf 3k3 erhöht, um "Interessenskonflikten" vorzubeugen; OverCurrent kann bei mir allerdings nicht auftreten. Im Betrieb glimmt daher LED8 nur und LED4 (A17), LED5 (D0) und LED6 (D1) leuchten schön hell.
m.n. schrieb: > Dennis Heynlein schrieb: >> Stört es beim STM32F4-Discovery nicht, daß FSMC_NWE auf der >> USB-Overcurrent-LED liegt ? > > Eigentlich nicht! Dennoch hatte ich schon vor langer Zeit R50 durch auf > 3k3 erhöht, um "Interessenskonflikten" vorzubeugen; OverCurrent kann bei > mir allerdings nicht auftreten. > Im Betrieb glimmt daher LED8 nur und LED4 (A17), LED5 (D0) und LED6 (D1) > leuchten schön hell. Okay :) gute Idee.
tft schrieb: > http://item.mobileweb.ebay.com/viewitem?itemId=251... > würde dieses Display auch Funktionieren? Wie sieht es aus? Hast Du Dir mittlerweile solch ein Display besorgt?
Ich habe mir das WaveShare TFT besorgt und bin angenehm überrascht. Helligkeit und Blickwinkel finde ich für den Preis gut. Ein Problem gibt es allerdings mit dem Timing. Die Datenübernahme erfolgt laut Datenblatt (findet man unter http://www.wvshare.com/column/LCD_Module.htm) mit der negativen DCLK Flanke (siehe Seite P64 des HX8257-A Datasheets). Dieses Timing bekomme ich mit dem FSMC eines STM32F4 nicht hin. Trotzdem kommt am Display mit folgenden Einstellungen und angepasster Interuptroutine etwas ganz ansehnliches raus: #define THP 41 // Hsync pulse width #define THB 2 // Hsync back porch #define THF 2 // Hsync front porch #define TVP 10 // Vsync pulse width #define TVB 2 // Vsync back porch #define TVF 2 // Vsync front porch #define X_START_POS (THP+THB) // x-werte ab 43 #define Y_START_POS (TVP+TVB) // Zeilen ab 12 #define MAX_X (SIZE_X-1) #define MAX_Y (SIZE_Y-1) #define H_LINE_LEN (X_START_POS+SIZE_X+THF) // gesamte Zeile #define V_LEN (Y_START_POS+SIZE_Y+TVF) extern "C" void DMA2_Stream0_IRQHandler(void) { __enable_irq(); DMA2->LIFCR = 0xfd; //alle int-flags loeschen if(line_cnt >= V_LEN) { line_cnt = 0; line_adr = (uint32_t)&FrameBuf; } if(line_cnt < TVP) DMA2_Stream0->M0AR = (uint32_t)(TFT_ADR + HSYNC_ADR_MASKE - THP); else DMA2_Stream0->M0AR = (uint32_t)(TFT_ADR + HSYNC_ADR_MASKE + VSYNC_ADR_MASKE - THP); if(line_cnt < Y_START_POS || line_cnt >=V_LEN-TVF) { DMA2_Stream0->CR = 0x490; // 8bit-modus Adressmodus PINC=0 , MINC = 1 DMA2_Stream0->PAR = (uint32_t)&black_pixel; } else { DMA2_Stream0->CR = 0x690; // 8bit-modus Adressmodus PINC =1 , MINC = 1 DMA2_Stream0->PAR = ((uint32_t)line_adr)-(X_START_POS-1); line_adr += SIZE_X; } DMA2_Stream0->NDTR = H_LINE_LEN; line_cnt++; DMA2_Stream0->CR |= 0x1; } Solange das Display kalt ist, scheint es Probleme mit der Datenübernahme zu geben (Pixel flimmern). Den Touch habe ich noch nicht untersucht. Kennt jemand einen Workaround?
Peter Hegel schrieb: > Dieses Timing bekomme > ich mit dem FSMC eines STM32F4 nicht hin. Das ist auch garnicht notwendig. Wichtig sind die Zeiten tds und tdh (Seite P.67, tdf im Diagramm ist ein Druckfehler) in Bezug auf CLK, die jeweils minimal 10ns betragen. Das Timing der neg. Flanke des /WR Signals kann man recht gut per FSMC einstellen. > Kennt jemand einen Workaround? Wofür?
M. N. schrieb: > Das Timing der neg. Flanke des /WR > Signals kann man recht gut per FSMC einstellen. Es ist alles genau anders herum! Ich habe noch einmal nachgesehen und festgestellt, dass mein Display die pos. Flanke von /WR zur Datenübernahme erwartet. Damit habe ich ein völlig entspanntes Timing und Du die Niete gezogen. Du könntest das Signal invertieren oder um 15-20ns verzögern, um die tds einzuhalten. Aber Du weißt sicherlich selber, was zu tun ist. Dass der FSMC flexibel einstellbar ist, darf man wohl nicht wörtlich nehmen. Ich habe es mit den Möglichkeiten der Renesas RX verwechselt, wo man den Schreibimpuls nach Belieben positionieren kann.
Vielen Dank für die Infos.
Einen Inverter oder Verzögerung werde ich später einmal ausprobieren.
Jetzt bin ich erst einmal froh, dass das Display zuckt. Ich reiche die
Ergebnisse nach.
Die Seite P.67 habe ich übersehen (dachte gehört zum SPI Timing).
Da taucht aber schon die nächste Frage auf. Funktioniert denn das
Einhalten von tvhs zwischen den fallenden Flanken von VSYNC und HSYNC?
Gehen die nicht gleichzeitig Low wenn line_cnt == 0 ist:
DMA2_Stream0->M0AR = (uint32_t)(TFT_ADR + HSYNC_ADR_MASKE - THP);
Außerdem haben bei mir die ersten zwei Zeilen beim Display gefehlt. Ich
habe deinen Code etwas modifiziert, um alle 272 Zeilen zu bekommen.
Den Vertical Front Porch habe ich auch etwas anders implementiert:
if(line_cnt < Y_START_POS || line_cnt >= V_LEN-TVF)
...BlackPixel
Die Adressleitungen A16/A17 habe ich auf A20/A21 verschoben, um kurze
Verbindungen vom Discovery Stecker P2 zum TFT Stecker zu ermöglichen.
Auf jeden Fall hat mir deine Implementierung eine Menge Arbeit gespart.
Danke!
Peter Hegel schrieb: > Außerdem haben bei mir die ersten zwei Zeilen beim Display gefehlt. Ich > habe deinen Code etwas modifiziert, um alle 272 Zeilen zu bekommen. Das habe ich gemerkt! :-) Die zwei Zeilen hatte ich nicht aktiviert, um etwas mehr 'normales' RAM zu erhalten. Wenn man das RAM sorgsam verwendet und auch CCM benutzt, kann man auch die volle Zeilenzahl nutzen.
Peter Hegel schrieb: > Da taucht aber schon die nächste Frage auf. Funktioniert denn das > Einhalten von tvhs zwischen den fallenden Flanken von VSYNC und HSYNC? > Gehen die nicht gleichzeitig Low wenn line_cnt == 0 ist: > DMA2_Stream0->M0AR = (uint32_t)(TFT_ADR + HSYNC_ADR_MASKE - THP); Meine Routinen kommen ursprünglich von einem QVGA-TFT. Da gibt es tvhs und tvhh überhaupt nicht. Bei der Umstellung auf WQVGA hat sich keinerlei Instabilität gezeigt. In einigen Punkten scheinen mir die Datenblätter auch etwas 'erfinderisch' zu sein. Vsync kann man auch steuern, indem man keine Adressleitung, sondern den selben IO-Pin als Portbit setzt und löscht. > Den Vertical Front Porch habe ich auch etwas anders implementiert: > if(line_cnt < Y_START_POS || line_cnt >= V_LEN-TVF) > ...BlackPixel Die "Front Porches" (ist hoffentlich der Plural) haben sich im Laufe der Zeit als völlig unnötig gezeigt; daher habe ich sie auch gnadenlos weggelassen. Das dafür Zeiten angegeben sind liegt wohl an der Kompatibilität zu Videosignalen, deren Timing auf Röhrenmonitore Rücksicht nehmen mußte. Wenn man die "Porches" verwendet und hierfür auch noch Platz im RAM hat, kann man damit Zeichen auch außerhalb des sichtbaren Bereiches beginnen oder enden lassen, was beispielsweise bei Laufschrift gut wirkt, wenn links und rechts Teilbuchstaben angezeigt werden, bis die letzte Spalte links verschwunden oder rechts aufgetaucht ist. Vertikal kann man das Bild weich nach oben laufen lassen (soft-scroll). Das sind aber alles Feinheiten, die vermutlich die meisten Leute garnicht brauchen.
Hallo. Gibt es Demohardware mit 800x480-Display, der ich mit 60fps Graubilddaten übergeben kann und die das ohne Framebuffer direkt anzeigt? . Parallel . zB. 6Bit Daten . Die zwei VSYNC/HSYNC Bits kann ich bei Bedarf mitliefern Beispielsweise auf Basis des hier vorgeschlagenen Quellcodes? Bei den Controllern SSDxxxx der Ebay-China-Boards lese ich "Framebuffer" oder "13fps" aber kein vsync/hsync auf der Pinheader-Belegung. Oder können die 60fps ohne Buffer? Grüße Lars
Lars R. schrieb: > Gibt es Demohardware mit 800x480-Display, der ich mit 60fps > Graubilddaten übergeben kann und die das ohne Framebuffer direkt > anzeigt? > . Parallel > . zB. 6Bit Daten Bestimmt nicht! 800x480 mit 256 bzw. 64 Graustufen brauchen einen Bildspeicher von 384kB. Der ..407 hat maximal 128K intern zur Verfügung; auch ein ..427 mit 192K würde nicht reichen. Bei reiner sw-Darstellung würden 48kB reichen, die dann über SPI1 ausgegeben werden könnten. Lars R. schrieb: > aber kein vsync/hsync auf der Pinheader-Belegung Die arbeiten vermutlich im DE-Modus.
@m.n.: Es hätte ja sein können, Du hast etwas. Deine Homepage habe ich angeschaut. Bei Glyn sieht es auf den ersten Blick so aus, dass es auch 800x480-Displays gibt, die zu den von Dir verwendeten WQVGA kompatibel sind. KOMPLETTES Zwischenspeichern habe ich nicht verlangt. Daten kommen vom FPGA.
Lars R. schrieb: > Bei Glyn sieht es auf den ersten > Blick so aus, dass es auch 800x480-Displays gibt, die zu den von Dir > verwendeten WQVGA kompatibel sind. Die Steckverbinder (40-pol. FFC) sind gleich beschaltet. Die Datenrate variiert natürlich mit den diversen Auflösungen. > KOMPLETTES Zwischenspeichern habe ich > nicht verlangt. Daten kommen vom FPGA. Da verstehe ich nicht so richtig, was Du eigentlich vor hast.
Bilddaten mit dem FPGA ausgeben. Pixel für Pixel. Zeile für Zeile. Per Handshake oder in definierten Zyklen. Über 1.27mm oder 2.54mm. Was ich umgehen möchte: LCD-Kabel <-> PCB, Backlight, LCD, Timing, Init, Power. Mit dem Display will ich mich eigentlich nicht beschäftigen. Auf der Suche im Netz habe ich auch Andere gefunden, die einfach nur etwas ausgeben wollen, aber nicht nur mit 5Hz SPI. Wenn es dann auch eine Lösung jenseits der China-PCB-Displays wäre, bei der man davon ausgehen kann, dass sie bei eventuellem Bedarf auch in ein paar Monaten noch verfügbar ist...
Tolles Projekt. Was passiert denn, wenn die Framerate zu niedrig wird? Flackert oder flimmert das Display dann? Und was ist, wenn die CPU in das externe SRAM schreibt während ein DMA-Transfer zum TFT läuft? Dann müsste der Round-Robin Scheduler ja dafür sorgen, dass lediglich die Geschwindigkeit des DMA-Transfers vorübergehend etwas absinkt?
Steffen Koepf schrieb: > Was passiert denn, wenn die Framerate zu niedrig wird? Flackert oder > flimmert das Display dann? Was ist denn der Unterschied zwischen Flackern und Flimmern? Durch die Trägheit des TFTs kann die Bildwiederholrate (framerate) bis ca. 30Hz gesenkt werden, sofern man direkt drauf sieht. Bei statischer Anzeige von Grafiken/Texten ist das in Ordnung. Bei schneller Ausgabe neuer Bildinhalte, wird die Ausgabe unruhig; eine Laufschrift beispielsweise ist sehr ruckelig. > Und was ist, wenn die CPU in das externe SRAM schreibt während ein > DMA-Transfer zum TFT läuft? Das ist alles problemlos, da ein TFT kein exaktes Taktsignal bei der Bildausgabe benötigt. Der DMA-Controller besorgt sich die notwendigen Zugriffe. Wie geschrieben, sollten die TFT-Datenleitungen mit einem xx573 entkoppelt werden, oder DCLK besser dekodiert werden anstatt nur das /WR-Signal direkt zu nutzen.
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.