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