Hallo an alle, ich experimentiere zur Zeit ein bisschen mit dem STM32F4 Discovery rum und würde gerne ein 7" TFT display anschließen. Hierfür soll der STM über einen Grafikcontroller mit dem Display kommunizieren. Meine Frage ist nun, ob es möglich ist solch einen Grafikcontroller an den STM anzuschließen, da ich hier bereits gelesen habe, dass der STM keinen externen Datenbus herausgeführt hat, ich aber der Meinung bin, dass ein Anschluss über das FSMC-Modul des Controllers möglich ist? Gruß Jan
Jan schrieb: > da ich hier bereits gelesen habe, dass der STM keinen > externen Datenbus herausgeführt hat, Du solltest das Datenblatt lesen. Die Gehäuse mit 144/178 Pins haben den Bus verfügbar, die 100pol. nur in einem Multiplex-Modus.
Ahhh jetzt auf deinen Hinweis hab ichs gefunden! Ist aber schon sehr versteckt :-o Also das heißt ja, dass Adress- und Datenbus quasi zusammenfallen...nicht schön. Wie sieht das dann mit der Performance aus? Absolut nicht zu verwenden oder gerade noch ausreichend? Hat da schon jemand Erfahrungen gesammelt? Gruß Jan
Jan schrieb: > Hierfür soll der STM > über einen Grafikcontroller mit dem Display kommunizieren. Das sind alles unbekannte Größen. Da kann Dir keiner helfen.
Ich habe gerade ein TFT 3.2" in Betrieb genommen. Trotz einem einfachen 16Bit breiten BitBanging Interface kommt man auf Frameraten von 30 Fps. Natürlich tut der Controller im Testprogramm nichts anders als Display und Touchscreen zu bedienen. 7" - Display sagt ja nichts über die Anzahl der Pixel. Ist es 320x240 oder mehr ? Außerdem: der erste Treffer beim G**geln ringt es schon: http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/CD00201397.pdf Gruß Thilo
Also konkret habe ich an ein 7" mit 800*480 Pixel gedacht. Dargestellt werden soll eigentlich "nur" eine Menüführung, in der sich nur einige Elemente ändern...also keine animierten Gimmiks oder ähnliches Thilo, danke für den Link, das Dokument hab ich nicht gefunden. Hab zwar eine App-Note von Epson gefunden, die ein Panasonic-Display angesteuert haben, aber bei ST zu suchen ist mir irgendwie nicht in den Sinn gekommen :-( Grafikcontroller habe ich mir noch keinen bestimmen ausgesucht, habe aber hier schon von Epson und Fujitsu "Lime" gelesen, die wohl recht gut sein sollen.
Jan schrieb: > schon von Epson und Fujitsu "Lime" gelesen Sind 2 völlig unterschiedliche Leistungsklassen. Bei Epson gibt es welche, die man als Port betreiben kann, nennt sich "indirekte Adressierung" oder so ähnlich. Das heißt, man schreibt Adressen und Funktionen in den Controller zum Setzen und Löschen von Pixeln. Zu den Grafikboliden von Fujitsu kann ich dir nur empfehlen, deren Manual mal herunterzuladen und zu studieren. Wenn du damit überhaupt mental klarkommst und es dir dann auch das Weitermachen noch zutraust, dann kannst du es damit ja mal versuchen. Ist aber ein sehr umfängliches Thema und nach meiner Meinung für dieses Bastelboard völlig ungeeignet. Sei froh, wenn du an so ein Board ein einfaches 32x128 Monochrom-Display drangebacken bekommst. W.S.
Falls es auch ein kleineres Display tut, einfach mal in der Bucht schauen, da habe ich 2.8" und 3.2" mit Touchscreen als Huckepack auf einem STM32F103-Board gesehen. Stichwort: Mini-STM32.
Ja W.S, ich hab gestern mal ins Handbuch des Lime reingeschaut und da gehts schon gut ab. Ich hab gerade noch einmal bei Epson nachgesehen udn mir ist der S1D13U11F00A aufgefallen. Der hat wohl einen USB2.0 Anschluss....ist sowas eine brauchbare Alternative? Gruß Jan
Hallo, also ich habe auch schon Versuche gemacht und einige Hardware mit externen Grafik Controllern für TFT aufgebaut, das Problem ist aber immer der externe BUS, der die meiste Performance aufbraucht. Weil die Grafik Controller nicht Syncron bei der Datenübertragung arbeiten fallen da sehr viele Waits an. Wenn es natürlich nur ein statisches Bild sein soll ist das ja nicht so schlimm. Ansonsten EPSON S1D13505 oder S1D13506 mit EDO-RAM IS41LV16100B 50ns. Aber mein Tip: ARM9 + TFT Controller wie die Atmel AT91SAM9G10,G15. Dann sind viele Probleme schon durch den Hersteller gelöst... Gruß Sascha
Hallo Sascha, das klingt schon einmal interessant. Trotzdem kann ich das von dir beschriebene Problem nicht ganz nachvollziehen. Meinst du damit, dass die Datenübertragung über den Bus schlichtweg zu langsam ist bei der gemultiplexten Variante? Oder dass die CPU des STM32 an sich mit der Übertragung der Bilddaten zu sehr ausgelastet ist? Bei letzterem Fall sollte doch der Weg über den DMA-Controller Abhilfe schaffen, da nur dieser dann die Übertragung handelt und die CPU entlastet ist? Gruß Jan
Hi Jan, ich nutze beispielsweise einen PIC32 mit externen Epson Controllern S1D1781 und S1D1748 für 4,3 Zoll (480x 272) bzw. 5,7 Zoll (640x480) TFTs. Der Controller kümmert sich um das ganze Timing um das Bild darzustellen, das ist auf jeden Fall angenehm. Die Daten müssen alle über den externen Bus, bei mir sind die Addressen mit den Daten gemultiplext, die Performance ist aber trotzdem noch gut (ext Bus läuft mit 80Mhz, die Waits des Controller und Setup/Hold Zeiten sind auch so im unteren 2stelligen ns Bereich). Jetzt kommt es ein wenig darauf an, was du darstellen wisst. Wenn das meiste statisch ist, und es sich nur wenig "bewegt", dann sind die meisten 32 Bitter locker ausreichend. Ein weiterer, sehr wichtiger Aspekt ist, wie deine Grafikbibliotek implementiert ist. Wenn man z.B einen Text aktualieseren will, wird das in der Microchip Lib so gemacht: Der alte Text wird gelöscht, indem ein Bereich oder Fenster komplett mit der Hintergrundfarbe überschrieben wird. Das braucht nur einen Adressierungsbefehl und dann nur noch Daten, die Operation ist also sehr schnell. Der eigentliche Text wird dann aus PutPixel Operationen zusammengebaut, für jeden Pixel ist also eine Adress und eine Datenübertragung notwendig. Das ist aber noch so schnell, dass es für das Menschliche Auge kaum sichtbar ist. Der Vorteil der Methode ist, dass im Microcontroller kein RAM für das Objekt (Text, Button...) verbraucht wird. Wenn du aber das Objekt vorher im RAM berechnest, und es dann als komplettes Element in den TFT Controller schreibst, ist das natürlich deutlich schneller (so ne Art DoubleBuffering). In diesem Fall muss das Okejt natürlich in den RAM passen, ein Button mit 80x80 Pixeln würde mit 16 Bit Farbtiefe schon gut 12kB RAM benötigen. Dann kannst du aber auch die Features wie DMA deines Controllers nutzen, um wirklich das letzte bisschen Performance aus deinem System herauszuquetschen. Gruß Stefan
Hallo, ja wenn z.b der externe BUS der CPU auf 30MHz leuft und dazu noch einen BUS-Clock ausgibt mit dem man den Grafik Controller versorgt (syncroner Betrieb) geht es etwas schneller. Nur mal so als Beispiel ich habe mit einem M32C Controller, der mit 24MHz getaktet wurde und einem Epson S1D13705, der mit 6MHz Pixelclock lief gerade mal so zwischen 1 bis 3 Mbyte pro Sekunde durchgebracht. Der externe BUS wird dann immer solange angehalten bis der Grafik Controller die Daten entgegen nehmen konnte. Das blöde daran war nur die Ganze CPU stand dann still. Wie das mit der DMA beim CM3 geht habe ich noch nicht ausprobiert. Da meine Entscheidung auch 800x600 mit 7" ist nehme ich einen AT91SAM9G10 der Pixel Clock nimmt mit steigender Auflösung da auch gleich quadratisch zu !!! (30-48MHz) Gruß Sascha
Willi schrieb: > die 100pol. nur in einem Multiplex-Modus. Was aber in diesem Fall nicht stimmt. Der Display Controller seiners 7" Displays benutzt eine SSD1963 und der benötigt nur 16Datenleitungen und 4 Steuerleitungen ( NE1, A16 als /RS, NWE, NOE). Da auf den Addressbus bis auf A16 verzichtet werden kann, gibt es keine Probleme mit der PIN-Anzahl und dem FSMC beim STM32F407-100Pin (Discovery F4). Multiplexen ist in diesem Fall nicht nötig. Einige Beispiele zeigen, wie dass dies praktisch gemacht wird. Das Turorial zum FSMC ist in der Software-Lib zum DiscoveryF4 Board zu sehen. ST benutzt ein ILI9320 / ILI9325 Controller in Zusammenhang mit den BB-Boards. Beim SSD1963 und besonders wenn es en größeres Display ist, ist sehr darauf zu achten, dass die Display-Stromversorgung der 5V Hintergrundbeleuchtung nicht mehr aus dem USB, bzw. aus dem Board direkt entommen wird. Der Strom der benötigt wird, ist zu groß und überfordert die Energieversorgung des Discovery. Diese lässt sich diskret erzeugen und man kann damit dann auch das Board versorgen. Die 3.3V erzeugt das Discovery on-Board. Bitte die Verbindungsleitungen zum Display sehr kurz halten, sonst gibts Probleme. Der SSD1963 ist sehr empfindlich was die Kapazitätszunahme der Versorgungsleitung betrifft. Bei Youtube findet man sehr viele praktisch umgesetzte Beispiele wie man es machen kann.
Hier gibts einiges für den STM32F4 zu sehen, u.A. auch Grafik: http://mikrocontroller.bplaced.net/wordpress/?page_id=744
Sooo kurzes Update: Ich habe die letzten Tage mal genutzt, um an dem Thema weiter zu arbeiten. Mittlerweile habe ich ein 800*480 Pixel Display mit dem STM32F4 Discovery verbunden, welches von einem SSD1963 getrieben wird. Ansteuerung über FSMC läuft und funktioniert problemlos, bin echt erstaunt wie unkompliziert das funktioniert hat :) Nachdem ich die typischen "Discovery-Fehlkonfigurationen" ausgemerzt habe (Passende Quartz-Frequenz angegeben und PLL Teiler darauf angepasst, sowie den ART und Cache aktiviert) läuft das Ganze schon recht flott. Core läuft wie der AHB Bus auf 168 MHz. Nun bin ich mir aber nicht sicher, ob ich damit auch bewegte Bilder flüssig anzeigen kann. Bisher nutze ich nur ein paar Putpixel-Funktionen. Nun stell ich mir die Frage, wieich die Framerate am Besten ermitteln kann. Hat dazu jemand ne Idee? Gruß Jan
Am besten die verstrichene Zeit mit Systick ausmessen. Der ist unbestechlich, auf vielen (allen?) STM32 vorhanden, genau und sogar unter vielen RTOS abfragbar.
Systick ist prinzipiell ne gute Idee und auch schon konfiguriert. Nur frag ich mich grad, auf was ich triggern soll? V-Sync vom Ssd1963 ist ja relativ witzlos, da dieses Signal nur den Status des Grafikchips widerspiegelt?
Sooo ich hab jetzt einfach mal gemessen, wie oft der Controller das Display innerhalb einer Sekunde komplett füllen kann. Dabei ergeben sich mit 168MHz Systemtakt eine Framerate von 19fps und mit 200Mhz spuckt er sogar 22-23fps aus. Alles in allem bin ich recht zufrieden damit, möchte das Display ja eigentlich nur als GUI benutzen und damit hauptsächlich statische Bilder anzeigen. Für Videos sicherlich nicht so geeignet, da der STM einfach zu wenig Ram hat und da würde dann die Bildrate sicherlich auch noch bisschen abnehmen.
Jan schrieb: > Sooo ich hab jetzt einfach mal gemessen, wie oft der Controller das > Display innerhalb einer Sekunde komplett füllen kann. > Dabei ergeben sich mit 168MHz Systemtakt eine Framerate von 19fps > und mit 200Mhz spuckt er sogar 22-23fps aus. Mich würde interessieren, ob Du das TE-Signal beachtest und, wenn ja, wie sehr der Datenstrom dadurch gebremst wird. Ferner: wie sehen Deine Schreibzugriffe zu den Messergebnissen aus? Setzt Du einmal die Startadresse und schreibst fortan nur noch Pixelwerte (8/16/24 Bit?) oder wird jedes Pixel vorher adressiert?
Also so sieht meine Initialisierung der FSMC-Schnittstelle aus:
1 | FSMC_NORSRAMTimingInitTypeDef DISPL_TIM; |
2 | DISPL_TIM.FSMC_AddressSetupTime = 2; |
3 | DISPL_TIM.FSMC_AddressHoldTime = 0; |
4 | DISPL_TIM.FSMC_DataSetupTime = 1; |
5 | DISPL_TIM.FSMC_BusTurnAroundDuration = 0; |
6 | DISPL_TIM.FSMC_CLKDivision = 0; |
7 | DISPL_TIM.FSMC_DataLatency = 0; |
8 | DISPL_TIM.FSMC_AccessMode = FSMC_AccessMode_B; |
9 | |
10 | |
11 | FSMC_NORSRAMInitTypeDef DISPL; |
12 | DISPL.FSMC_Bank = FSMC_Bank1_NORSRAM1; |
13 | DISPL.FSMC_DataAddressMux = FSMC_DataAddressMux_Disable; |
14 | DISPL.FSMC_MemoryType = FSMC_MemoryType_NOR; |
15 | DISPL.FSMC_MemoryDataWidth = FSMC_MemoryDataWidth_16b; |
16 | DISPL.FSMC_BurstAccessMode = FSMC_BurstAccessMode_Disable; |
17 | DISPL.FSMC_AsynchronousWait = FSMC_AsynchronousWait_Enable; |
18 | DISPL.FSMC_WaitSignalPolarity = FSMC_WaitSignalPolarity_Low; |
19 | DISPL.FSMC_WrapMode = FSMC_WrapMode_Disable; |
20 | DISPL.FSMC_WaitSignalActive = FSMC_WaitSignalActive_DuringWaitState; |
21 | DISPL.FSMC_WriteOperation = FSMC_WriteOperation_Enable; |
22 | DISPL.FSMC_WaitSignal = FSMC_WaitSignal_Enable; |
23 | DISPL.FSMC_ExtendedMode = FSMC_ExtendedMode_Disable; |
24 | DISPL.FSMC_WriteBurst = FSMC_WriteBurst_Disable; |
25 | DISPL.FSMC_ReadWriteTimingStruct = &DISPL_TIM; |
Das TE-Signal des SSD1963 habe ich mit dem NWAIT des STM verbunden. Was mich nur grad wundert ist, dass die Framerate gleich bleibt, auch wenn ich FSMC_AsynchronousWait_Disable setze... Ja ich setzte die Startadresse und schreibe dann nur neue Daten raus.
Jan schrieb: > Was mich nur grad wundert ist, dass die Framerate gleich bleibt, auch > wenn ich FSMC_AsynchronousWait_Disable setze... Flimmert denn der Bildinhalt, wenn das Display neue Daten bekommt? Die Funktion des TE-Pins habe ich so verstanden, dass er neue Daten nur während Vsync und Hsync quitiert; andernfalls müßte das /WAIT des ext. Busses die Ausgabe deutlich bremsen. Für mich war das bislang das K.O.-Kriterium, diesen Controller nicht weiter zu beachten. Vielleicht ist der Controller fürs sequentielle Schreiben besser organisiert (Puffer). Aber sobald man Schrift oder Grafik ausgeben will, muß ja jedes neue Pixel in der Regel komplett adressiert werden. Das wird dann wohl nicht mehr so flott gehen.
So nun hab ich das Rätsels Lösung: Die Leitung vom TE-Pin des SSD1963 zum Verbindungsstecker ist schlicht und einfach nicht geroutet! Deswegen kommt das TE-Signal auch nicht beim Discovery-Board an. Mal sehen ob ich da per Hand was machen kann, der Pinabstand ist schon sehr grenzwertig :( Oder ich lebe einfach ohne das TE-Signal, was für ein statisches Bild ja eh boogie ist. @ m.n: Jaein. Neue Daten nimmt der Controller prinzipiell immer an. Das TE Signal ist eigentlich nur wirklich wichtig, wenn du fließende Bilder (sprich ein Video) darstellen willst, da du mit seiner Hilfe den Zugriff synchronisieren kannst. Klar, wenn du ein Pixel direkt setzten willst, musst du es jedes mal komplett neu adressieren. Aber das geht dann schon wieder mehr Richtung GUI / Benutzerführung und nicht Datenstrom abspielen. Da spielt dann die Framerate eh keine so große Rolle mehr. Für nen Video-Stream (Puffer komplett von Anfang bis Ende mit Daten aus dem Ram befüllen) halte ich den SSD1963 prinzipiell schon gut geeignet.
Hallo, ich bin mal wieder dazu gekommen ein bisschen am Projekt weiter zu arbeiten. Nachdem ich das TFT richtig konfiguriert (PLL, Pixelrate), den Code an einigen Stellen umstrukturiert, sowie die Code-Optimierung im Compiler aktiviert habe, bekomme ich nun Frameraten von 42fps raus. Wohl gemerkt noch ohne Beachtung des TE-Signals, mangels gerouteter Leiterbahn. Klar, der Controller macht momentan nichts anderes, als einen statischen 16Bit-Wert (RGB565) aus dem Flash in einer Endlosschleife ans FSMC-Interface zu schreiben, aber zumindest die Performance des FSMC an dieser Stelle ist beachtlich. Daten aus einem externen Speicher zu lesen und ans Display zu schicken ist natürlich nochmal ne andere Hausnummer, sollte aber mit DMA auch ganz gut gehen. Nun würde ich doch gerne mal versuchen, ein Video aufs Display auszugeben. Kann mir jemand einen Codec (mit Berücksichtigung der Rechenleistung des STM) dafür empfehlen? Danke und Gruß
Hi Jan! Ich bin auch gerade daran, die Framerate mit der gleichen Konfiguration zu pushen. Ich komme allerdings nur auf etwa 11 FPS, ohne DMA2D, den möchte ich gerade noch aktivieren. Wie viel Takte vergehen eigentlich beim Lesen und Schreiben eines Half-Words? Um mein Display zu füllen (800x480x16Bit, RGB565) vergehen etwa 90ms. Irgendwas ist da noch Faul, hättest du einen Tipp für mich? EDIT: Ah, der F4Discovery hat keinen ART :> naja, der CoreF429I ist unterwegs :>
Mitlesa schrieb: > Reginald L. schrieb: >> Hi Jan! > > Jan hat vor ca 1.5 Jahren zuletzt geschrieben ..... Jop, ich kann lesen :)
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.