STM32F429 LTDC Nutzen, welche Displays sind möglich?

>Ich wäre sehr dankbar wenn mir jemand einmal kurz aufzeigen kann wo mein
>Verständnisproblem bzw. die Ursache meiner Verwirrung liegt.

Der LTDC ist der Displaycontroller. Für ein Display
deiner Grösse brauchst du noch externes RAM.

Such mal nach STM32F429 LTDC VGA. Das kommt deiner
Geschichte am nächsten. Statt der R2R DACs müsstest
du dann theoretisch die digitalen IOs direkt an
das Display anschliessen. So weit zur Theorie;)

Okay, laut dem Datenblatt soll aber ein HIMAX HX8262-A nzw ein HIMAX 
HX8678-A als Referenz für das Timing und Weiteres herangezogen werden.

Oder sehe ich das auch wieder falsch?

Danke schonmal für den Tip!


Viele Grüße
Christian

>Okay, laut dem Datenblatt soll aber ein HIMAX HX8262-A nzw ein HIMAX
>HX8678-A als Referenz für das Timing und Weiteres herangezogen werden.

Ja und? Dann lies halt die Datnblätter der Controller.

Im Prinzip kannst du das Display so wie auf dem STM32F429
Discovery anschliessen. Dotclock, Enable, Hsync, Vsync
und die RGB Leitungen. Konfigurieren musst du das Display
nicht, also fallen die anderen Leitungen weg.

Das Timing einzustellen im LTDC könnte dann knifflig werden.

Und der FPC Connector ist sicher auch nicht jedermanns Sache.

Einfach ist was anderes, aber gehen wird das irgendwie.

@holger:

Kannst Du mir einen Tipp geben wie es einfacher geht?

Ich versuche auchs chon seit 2 Tagen hinter ein Beispiel mit dem 
STM32F429-Disco zu kommen wo das TFT vom Disco-Board angesteuert wird. 
So wie ich es sehe ist es ja die gleiche Schnittstelle wie die von 
meinem beabsichtigten Board. Daher dachte ich, ich könne mich an dem 
Beispiel orientieren. Seltsamerweise wird das Display auf dem 
Disco-Board aber auch initialisiert und alles...
Und ich weiss noch nicht so recht wofür der Beispielcode das externe 
SDRAM nutzt... Ich bin nur noch verwirrt je mehr ich versuche es zu 
verstehen...


Macht es deiner Meinung nach Sinn ein Display mit einem SSD1963 oder 
Ähnliches einzusetzen? Bevor ich jetzt vollkommen die falsche Richtung 
einschlage...


Viele Grüße
Christian

Chris D. schrieb:
> Dadurch kann man die sehr preiswerten "dummen" Displays einsetzen (um
> die $10). Den Preis von Reichelt kann man nur als üble Frechheit
> bezeichnen.

Dann zeig doch mal Deine Preisliste, damit auch Deine üblen Frechheiten 
sichtbar werden.
Bei den von Reichelt vertriebenen Displays handelt es sich um 
Ausführungen von EDT für Glyn, die von 3,5" - 7" alle die gleiche 
Steckerbelegung haben und damit untereinander kompatibel sind. Ferner 
ist eine passende Stromversorgung für die Hintergrundbeleuchtung 
vorhanden.

@Christian
Für die ersten Erfahrungen könntest Du auch eine kleineres Display 
nehmen, was ohne ext. Speicher auskommt. Ich hatte mal 5,7" QVGA aus der 
besagten Glyn-Serie angeboten: 
Beitrag "[V] 5,7"-TFT QVGA, gebraucht"

Eine ganz einfache Ansteuerung dazu funktioniert schon am ext. Datenbus 
vom STM32F407: 
http://mino-elektronik.de/TFT-direct-drive/TFT-direct-drive.htm#tft-1 
ff.

Ich hätte da auch noch eine kleine Frage die zum Thema passt.

Warum ist auf dem 32F429IDISCOVERY Board in dem Display noch ein ILI9341 
Controller eingebaut? Der STM32F429 hat doch schon einen 
Displaycontroller. Da hätte ST doch ein bisschen Geld sparen können oder 
das Board noch billiger anbieten können, oder? Oder wollte man noch die 
Möglichkeit bieten, das Display über SPI/FMC ansteuern zu können?

TriHexagon schrieb:
> Warum ist auf dem 32F429IDISCOVERY Board in dem Display noch ein ILI9341
> Controller eingebaut?

Vermutlich, weil dieses Display für < 1 $ zu bekommen war. Für den 
Anwender vom Discovery-Board ist das eher nervend, da hier das parallele 
Interface vom ..429 genutzt wird.

@ Uwe.B.
Oder siehst Du irgendeinen Sinn darin?

Chris D. schrieb:
> Ich zumindest eher nicht.

Für mich ist da sogar ein Punkt, der mich von eingehender Nutzung des 
429 Discovery-Boards abhält. Ich mag lieber schlanken, funktionalen 
Code. Zudem ist mir das Display zu klein und zu schlecht abzulesen.

@ Chris:
Deine 'rabiate' Art, das Display zu entfernen/-sorgen gefällt mir 
eigentlich ganz gut. Allerdings ist es auch ein wenig fummelig, einen 
40-pol. Adapter anzuschließen.

Markus Horbach schrieb:
> Vor dem Proggen unbedingt CubeMX installieren

Für mich ein Grund, die Finger davon zu lassen ;-)

Uwe B. schrieb:
> ich vermute mal ST wollte beim F429-Board einfach die Möglichkeiten
> vom DMA2D zeigen und dafür muss das Display am LTDC-Port hängen
>
> damit sind dann Überblend-Effekt, Alpha-Channel und
> so Zeug möglich...und das kopieren von RAM-Teilen
> per DMA2D läuft unanhängig von der CPU oder TFT-Controller

Es ging um den ILI9341, der dafür nicht notwendig ist.

Uwe B. schrieb:
> ich persönlich würde das Display nicht per FMC betreiben wollen :-)

Weshalb auch, wenn ein TFT-Controller auf dem Chip ist.

Markus Horbach schrieb:
> @ TriHexagon : das TFT auf dem Disco Board kann in mehreren Modi
> betrieben werden, die per Lötbrücken umgestellt werden. Per Lötbrücken
> kann man auf dem Board noch viel mehr verstellen, SB9 sollte man als
> erstes überbrücken.

Dass heißt man kann den ILI9341 einfach umgehen? Sorry, beschäftige mich 
erst seit gestern mit dem Board und blicke noch nicht ganz durch, aber 
nach dem Schematic nachzuurteilen sieht es auf dem ersten Blick so aus.

Markus Horbach schrieb:
> Bevor man sich ein teures TFT kauft ist das STM32F429-Disco
> Board+Lochraster VGA eine ideale Spielwiese für erste Schritte.
> Besonders, da man davon ausgehen kann, das das Board OK ist !
> Die Timings für 800x480 funktionieren nur an einen 16:9 Monitor, die
> beiden anderen Auflösungen kann jeder Monitor. Für VGA kann man den ILI
> getrost ignorieren.

Oh an VGA habe ich gar nicht mehr gedacht. Da geht einem ja das 
Bastlerhertz auf ;).

m.n. schrieb:
> Markus Horbach schrieb:
>> Vor dem Proggen unbedingt CubeMX installieren
>
> Für mich ein Grund, die Finger davon zu lassen ;-)

Es ist echt ein bisschen Overbloat, aber zumindest fürs Initialisieren 
ist es Gold wert. Es gibt ja zum Glück immer noch die Möglichkeit direkt 
in die Register zu schreiben.

Chris D. schrieb:
> Ja, das war auch wirklich das erste, was ich nach dem Auspacken gemacht
> habe: Display runter ;-)

Und du grinst dann noch mit einem zugekniffenen Auge?

Also, wenn ich das lese, wird mir schlecht. Wozu geiert ihr denn 
eigentlich auf der Embedded nach solchen Boards, wenn ihr sie als 
allererstes schlachtet?

Mein Vorschlag ist immer wieder, sich zunächst ein Projekt vorzunehmen 
und danach eine dazu passende Leiterplatte zu machen. OK, die kostet 
dann auch nen Herstellungspreis, aber dafür hat man dann deutlich mehr 
und besseres als mit irgend einem kleinen Eval-Board.

Jaja, ich kann es vestehen, wenn jemand so eine Art 
Universal-Steuerbaugruppe haben wollen, wo sie neben einem µC und dessen 
I/O auch noch einen Bildschirm, SD Karte, USB usw. haben wollen, damit 
sie dies für Bastelzwecke einsetzen können. Ein Eval-Board mit Display 
drauf ist dafür ganz OK, aber selbiges runterzureißen und dann Strippen 
dran? So einen Drahtverhau kriegt man nie wieder in Form.

Ich habe ja ein Verständnis für Leute, die beruflich was anderes machen 
oder bereits emeritiert sind oder Schüler mit schmalem Taschengeld - und 
die deshalb keinen Zugriff (mehr) auf die üblichen Distributoren haben 
und sich deshalb leider an die üblichen Halsabschneider der Branche 
halten müssen und ein Eval-Board benutzen müssen, weil eben DIESES der 
einzige Weg für sie ist, weigstens etwas auf die Beine zu kriegen.

Ja, mir kommt da der Ärger hoch, weil auf diese Weise ganz gewiß ne 
Menge Leute mit Ambitionen sich an verrammelten Einkaufswegen aufreiben 
müssen. Ich hatte ja nicht umsonst das Projekt "Lernbetty" hier 
angefangen, damit auch Leute mit ganz kleinem Budget etwas Benutzbares 
in die Finger kriegen können.

Ich hatte auch mal dran gedacht, hier sowas wie einen Nachfolger für die 
Lernbetty zu plazieren, ein Beispiel sieht man auf dem Bild. (die Box 
stammt von Glyn, da passen Display+LP prima rein) Das 7" Display hat ca. 
22 Euro gekostet, aus China via ebay. Ich meine, das kann man sich 
leisten. Die LP ist genau so groß, hat einen NXP-Chip drauf und 16 MB 
RAM (32 bittig).

Ich bin ohnehin mehr für NXP als für ST, denn technisch hat NXP schon 
immer mehr drauf gehabt und ST war immer nur der Nachzügler. Jahrelang 
haben die von ST kein SDRAM-Interface, keinen 32 Bit breiten externen 
Bus und keinen Displaycontroller gehabt. Selbst jetzt hakelt es bei 
denen immer noch.


Und jetzt muß ich hier lesen, wie selbst Leute aus der Branche wie du 
sowas sinnlos zerbastelst. Zestörungswut?

W.S.

W.S. schrieb:
> Und jetzt muß ich hier lesen, wie selbst Leute aus der Branche wie du
> sowas sinnlos zerbastelst. Zestörungswut?

Da Du mich nicht meinst, kann ich ja entspannt antworten.
Mein 429 Discovery-Board habe ich ganz regulär vom Distributor erstanden 
(nicht mit lange anstehen verwechseln ;-) Daß das Display nichts taugt, 
konnte ich erst danach feststellen. Daher kommt der Wunsch (Zwang), es 
auszutauschen.
Mit NXP hast Du ja recht, wenn es nur ums TFT geht. Wenn man hohen 
Prozessortakt und viel RAM auf dem Chip möchte, ist STM32 eben ein Stück 
voraus. Das war auch der Grund, warum ich mit ARM etwas angefangen habe. 
Wenn es um 'Schönheit' und Nutzen der Hardware geht, hat für mich immer 
noch Renesas die Nase vor. Gut, ist ein anderes Thema.

TriHexagon schrieb:
> Dass heißt man kann den ILI9341 einfach umgehen? Sorry, beschäftige mich
> erst seit gestern mit dem Board und blicke noch nicht ganz durch, aber
> nach dem Schematic nachzuurteilen sieht es auf dem ersten Blick so aus.

Einfach umgehen? Eben nicht! Du mußt ihn aktivieren, damit er nicht mehr 
stört; gäbe es ihn nicht, wäre Alles bestens.

m.n. schrieb:
> TriHexagon schrieb:
>> Dass heißt man kann den ILI9341 einfach umgehen? Sorry, beschäftige mich
>> erst seit gestern mit dem Board und blicke noch nicht ganz durch, aber
>> nach dem Schematic nachzuurteilen sieht es auf dem ersten Blick so aus.
>
> Einfach umgehen? Eben nicht! Du mußt ihn aktivieren, damit er nicht mehr
> stört; gäbe es ihn nicht, wäre Alles bestens.

Ja stimmt, geht leider nicht, sah zuerst so aus. Jetzt muss ich das Ding 
zuerst über Serial Interface Mode zum RGB Interface Mode schalten -.- .

m.n. schrieb:
> Mein 429 Discovery-Board habe ich ganz regulär vom Distributor erstanden

Jaja, glaub ich dir doch. Aber die nächste Embedded ist ja bald. Bei den 
beiden letzten hab ich die Geier in hellen Scharen um die Stände von ST 
sich drängeln sehen, die Visitenkarten schwenkend.. Mal sehen, wie es 
heuer sein wird..

Aber mal zu den STM32ern: Das mit dem hohen Takt war deinerseits wohl 
ein Scherz. Wenn man mal nachschaut, wieviele Waitstates man bei höheren 
Taktfrequenzen vorsehen muß - trotz Flashrom-Accelerator-Dingens, merkt 
man schnell, daß da bei ST ne Menge Augenwischerei und Schaumschlägerei 
betrieben wird.

Das Nächste ist der externe Bus: bislang eben nur 16 bittig und erst 
seit vorigem Sommer gibt's die ersten Muster im 208er Gehäuse mit 32 
bittigem Bus. Das Blöde dabei ist, daß dort noch Macken drin sind und 
man bei SDRAM keine statischen externen Teile anschließen darf. Bei 
NXP ist z.B. der LPC2478 schon steinalt und der LPC4088 schon seit 
Jahren erhältlich - sogar bei TME für jedermann.

Bei den STM32F429-Discovery ist m.W. ein viel kleinerer Chip verbaut und 
demzufolge der externe Bus höchstwahrscheinlich nicht 32 bittig - und 
das trotz des Displayes. Flaschenhals, sag ich nur. Was soll das? Wenn 
Chris schreibt "wie unsere Grafikroutinen auf großen Displays laufen", 
dann kommt mir nur das Kopfschütteln.

W.S.

W.S. schrieb:
> Aber die nächste Embedded ist ja bald. Bei den
> beiden letzten hab ich die Geier in hellen Scharen um die Stände von ST
> sich drängeln sehen, die Visitenkarten schwenkend.. Mal sehen, wie es
> heuer sein wird..

Ich gehe mindestens schon 20 Jahre nicht mehr auf Messen. Der Aufwand 
lohnt sich einfach nicht! Falls doch einmal, zahle ich lieber den vollen 
Eintrittspreis, als meine Daten sonstwo abzuliefern: Wohlstandskind 
eben.

> Aber mal zu den STM32ern: Das mit dem hohen Takt war deinerseits wohl
> ein Scherz. Wenn man mal nachschaut, wieviele Waitstates man bei höheren
> Taktfrequenzen vorsehen muß - trotz Flashrom-Accelerator-Dingens, merkt
> man schnell, daß da bei ST ne Menge Augenwischerei und Schaumschlägerei
> betrieben wird.

Ich beiße jeden Morgen in eine faule Zitrone und hasse Scherze!

Ich kenne die RX von Renesas mit 100 MHz Flash-Zugriff. Im Vergleich 
dazu sind die STM32F4 (grob) proportional zur Taktfrequenz schneller. 
Meinem obigen Link folgend kann man die Zeiten für Zeichenausgabe auf 
einem TFT sehen: RX610 @ 100 MHz / STM32F407 @ 168 MHz.
Selbst bei ISR-Aufrufen stören die waitstates nicht, da parallel zum 
Sichern der notendigen Register schon der Flash-Zugriff für den ISR-Code 
stattfinden kann.

wg. ext. Busbreite: ich habe eine Schaltung mit ..429 in Arbeit, bei der 
ich einen 100pol. µC nehme. Den breiten ext. Bus brauche ich nicht. Was 
ich gut finde, ist die FLUT.

Chris D. schrieb:
> Aber: der Op hat nach dem LTDC des STM32F429 gefragt. Da hilft ihm ein
> NXP-Verweis wenig.

Glaubst Du, der meldet sich noch mal?

Hi,

ich pappe mich mal hier dran, da ich das Display auf dem F429 sehr nett 
finde und auch benutze, zusammen mit der Lib von Zilen Majerle.

Aber mal generell zum Verständnis: Arbeitet das Ding im DMA Betrieb? Ich 
habe da herumk gesucht und keine Treffer für DMA gefunden, weder im Lib 
Code von Tilen als auch im ST StdPeriphLib. Jedenfalls sehe ich es auf 
dem Display, wenn ich im Memory Debug eine Zahl ändere sofort an einem 
Pixel, auch wenn der Debugger steht.

Und wenn DMA: Wer schaufelt sich da die Daten rein? Das Display vom 
SDRAM oder schiebt der Controller sie rüber?

Uwe B. schrieb:

> dieser sendet (einmal eingestellt)
> die Bildinformationen zyklisch vom externen SDRAM
> an das Display (ähnlich einer Grafik-Karte)
> mit VSync, HSync und RGB-Daten
>
> wenn die CPU ein Pixel im Grafik-RAM verändert,
> wird dieses beim nächsten Display-Refresh angezeigt

Hi,

heisst das umgekehrt auch, dass der Bus zum SDRAM derweil blockiert ist 
für die CPU? Ich habe noch einen großen Struct im SDRAM liegen, mein 
"Spielfeld". Das würde aber auch in das CCRAM passen oder auch ins 
normale RAM. Meine Anwendung modifiziert ja das SDRAM über einfache 
Umrechungen der x,y Koordinaten.

Christian J. schrieb:
> heisst das umgekehrt auch, dass der Bus zum SDRAM derweil blockiert ist
> für die CPU?

Ah.... JA. Du hast es herausgefunden.

Ja, so ist es. Die Video-Daten müssen aus dem RAM in die Zwischenpufer 
des TFT-Controllers geschaufelt werden nd von dort aus zum eigentlichen 
Display.

Das belastet natürlich den Bus, insbesondere das externe Businterface. 
Eben deshalb ist es ja so wichtig, dieses nicht zum Flaschenhals werden 
zu lassen. Und daher eben meine Ansicht, daß für sowas vorzugsweise eben 
ein 32 bittiger externer RAM nebst 32 bittigem Bus in Frage kommt.

Rechne doch einfach mal aus, was da an Datenströmen zustande kommt:
bei einem 7" in WVGA kannst du ca. 30..40 MPixel/s veranschlagen, jedes 
zu 16 Bit (bei 565 Farbe). Macht rund 60..80 MByte/s, die da geschaufelt 
sein wollen. Wenn der externe Bus dann noch zu etwas taugen soll, müßten 
darüber hinaus nochmal 60..80 MByte/s (oder mehr wenn's geht) zur 
Verfügung stehen. das wäre dann das Kontingent, aus dem sich die CPU 
bedienen kann.

W.S.

W.S. schrieb:

> Ja, so ist es. Die Video-Daten müssen aus dem RAM in die Zwischenpufer
> des TFT-Controllers geschaufelt werden nd von dort aus zum eigentlichen
> Display.

In de Tat. Meine Spielrei mit meinem "Game of Life", was eine optimierte 
Berechnung hat, die nur das "Delta" berechnet und auch nur das darstellt 
zeigt, dass ich beo Verwendung des CCRAM und SRAM1 nahezu die 10 fache 
Geschwindigkeit erreichen kann. Über 20 Generationen / s spult der durch 
bei dieser rechenintensiven Simulation, wo jeder Befehl in der 
Kernschleife gleich spürbar wird.

De facto ist das SDRAM bei Verwendung des Grafik Displays also ein 
Schleichspeicher und eigentlich nicht mehr zu verwenden :-(

Wuselt ganz schön:

https://www.youtube.com/watch?v=DXGynpIPawA&feature=youtu.be

Chris D. schrieb:
> eine andere Möglichkeit, die sich gerade bei ständig wechselnden
> Inhalten (im Idealfall Videos) anbietet, habe ich neulich hier
> skizziert:

Hi,

das kenne ich von meinem C64 als ich noch Asm programmierte auf dem, so 
mit 16 glaube ich. Beim STm32 bin ich noch nicht in die Tiefen der 
Hardware rein, erstmal Programme die fast ohne Hardware auskommen, ISRs, 
die Ansteuerung des durchaus komplexen Displays (laut Init in der 
StdPeriphLib) etc kommen später.

Ich habe bisher noch nicht herausgefunden wo denn genau der DMA 
eingestellt wird und wie man den Bereich ändern kann auf den er zeigt. 
Das Display haut ja wohl auch die meisten GPIOs weg, so dass nur noch 19 
freie übrig bleiben.

Weiss jemand wo man die Geschwindgkeit einstellen kann mit der das 
Display refreshed wird? In den StdPeriphLibs meine ich?

GOL wird erst interessant, wenn man die "Hand Gottes" programmiert, also 
Mutationen, Alterung, zufälliges Leben usw. Normalerweise endet ja alles 
im Stillstand aber dann nicht mehr, es "lebt" immer weiter. Ich fange 
mit nur 100 Zellen an. Der RNG sorgt dafür dass es immer andere Muster 
sind.

https://www.youtube.com/watch?v=8FqgWFN0F6U&feature=youtu.be

Jetzt altern sie wenn sie still stehen und sterben (nach 100 Gen.) und 
wenn es weniger als 500 "Mutationen" (auf 76000 Pixel) gibt (=wenig 
Leben) werden (diff) neue Zellen wahllos neu geschaffen. solange bis es 
wieder über 500 liegt. Dann sieht man die viele der Muster, wie 
Raumschiffe usw.

Die enorme Rechengeschwindigkeit des STM32 macht das Ganze durchaus 
interessanter als auf einem Z80. Allerdings ist der Code auch extrem 
geschwindigkeitsoptimiert, es läuft eine Suchmaske drüber die nur 
belebte Regionen betrachtet.