Hallo liebe Forengemeinde, ich möchte den LTDC eines STM32F429 nutzen um ein Display anzusteuern. Nun lese ich mich seit 2 Tagen durchs gesamte Netz und bin total verwirrt. Im Wesentlichen habe ich folgende Fragen: - Kann ich dieses Display am STM32F429 nutzen? http://www.reichelt.de/TFT-DIS-7-0-MT/3/index.html?&ACTION=3&LA=446&ARTICLE=101753&artnr=TFT-DIS+7%2C0+MT&SEARCH=7%22+touch --> Wenn ja, wie initialisiere ich es? Ich finde im angegebenen Datenblatt kaum Informationen dazu... Oder haben WVGA-Displays immer eine automatische Initialisierung? Weiterhin bin ich total verwirrt was es überhaupt für Möglichkeiten gibt. Oftmals sieht man ja, dass Displays mit den Controllern SSD1289 und SSD1963 am STM32F4-Disco verwendet werden und irgendwie über den FSMC-Bus gesteuert werden. Kann ich diese Displays auch am LTDC des STM32F429 betreiben? Oder sind das vollkommen verschiedene Dinge??? Ich wäre sehr dankbar wenn mir jemand einmal kurz aufzeigen kann wo mein Verständnisproblem bzw. die Ursache meiner Verwirrung liegt. Es ist bestimmt sehr einfach, aber ich komme einfach nicht dahinter. Viele Grüße Christian
>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
Hi Christian, willst du ein STM32F429-IC oder das STM32F429-Disco Board einsetzen ? beim Disco-Board hängt am FMC-Bus schon das SD-RAM bin mir nicht sicher ob du da noch ein Display zusätzlich drannklemmen kannst eins zuerst : FMC-Schnittstelle != LTDC-Schnittstelle beim Disco-Board hängt wie schon geschrieben das SD-RAM am FMC-Bus und wird für das Display als Graphic-Puffer benötigt Die LTDC-Schnittstelle sendet die Daten aus dem SD-RAM ans Display (mit H-Sync und V-Sync wie bei einem PC-Monitor) hier ein Beispielschnippsel für den LTDC :
1 | //--------------------------------------- |
2 | // Timer konfig |
3 | // HSync = 10 VSync = 2 |
4 | // HBP = 20 VBP = 2 |
5 | // HFP = 10 VFP = 4 |
6 | // |
7 | // Portrait : W=240, H=320 |
8 | //--------------------------------------- |
9 | LTDC_InitStruct.LTDC_HorizontalSync = 9; // HSync-1 |
10 | LTDC_InitStruct.LTDC_VerticalSync = 1; // VSync-1 |
11 | LTDC_InitStruct.LTDC_AccumulatedHBP = 29; // HSync+HBP-1 |
12 | LTDC_InitStruct.LTDC_AccumulatedVBP = 3; // VSync+VBP-1 |
13 | LTDC_InitStruct.LTDC_AccumulatedActiveW = 269; // HSync+HBP+W-1 |
14 | LTDC_InitStruct.LTDC_AccumulatedActiveH = 323; // VSync+VBP+H-1 |
15 | LTDC_InitStruct.LTDC_TotalWidth = 279; // HSync+HBP+W+HFP-1 |
16 | LTDC_InitStruct.LTDC_TotalHeigh = 327; // VSync+VBP+H+VFP-1 |
17 | |
18 | LTDC_Init(<DC_InitStruct); |
mehr ist da nicht einzustellen, man muß die Auflösung vom Display kennen und das Timing (falls das nicht stimmt wird schrott angezeigt, oder gar nichts) der Controller auf dem F429-Disco (ILI9341) hängt per SPI-Schnittstelle an der CPU und wird beim initialisieren auf die richtige Betriebsart (RGB) gestellt und andere sachen die zum Betrieb notwendig sind. Nach dem Init wird der ILI nicht mehr angesprochen Gruss Uwe
:
Bearbeitet durch User
Wir haben das kleine Display vom STM32F429-DISCO runtergeschmissen und an den entsprechenden Ausgängen ein 7"-Display (800x480) angehängt. Ein Foto unseres ersten Testaufbaus findest Du hier: Beitrag "Re: Cortex M7 zu überzüchtet" Wie Uwe schon schrieb, wird das auf dem Board befindliche zusätzliche RAM (8MB) als Speicher für den Displaycontroller genutzt. Bei diesem Board benötigst Du also keinen anderen Grafikcontroller (SSD1963 etc.). Der Controller im Chip macht eigentlich nichts anderes als ständig die Daten vom RAM zum Display zu schieben und die entsprechenden Taktsignale auszugeben. Dadurch kann man die sehr preiswerten "dummen" Displays einsetzen (um die $10). Den Preis von Reichelt kann man nur als üble Frechheit bezeichnen. Hier gibt es sogar eine 1024x600-Version für einen Zehner: http://www.aliexpress.com/item/CLAA070NT01CW-LCD-New-original-7-screen-for-tablet-inside-liquid-crystal-display-screen/32271663807.html Touchscreenfolien zum Draufkleben gibt es da auch ohne Ende. Man kann mit Tricks übrigens auch bei großen Displays ohne zusätzliches RAM auskommen, also wirklich nur mit dem STM32F429. Ich hatte das im Beitrag zum Foto mal erläutert.
:
Bearbeitet durch Moderator
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.
m.n. schrieb: > 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. Alles gut und schön - aber ein paar MC33063, ein Touchcontroller und SMD-Spulen rechtfertigen mMn trotzdem nicht diesen Preis. Die Displaybeleuchtung schließt man einfach nur an oder nimmt für 10ct noch einen Transistor plus Vorwiderstand und regelt die Helligkeit über PWM. Im Übrigen waren bisher alle Displays der AT-Serien, die wir bezogen haben, ebenfalls in der Steckerbelegung kompatibel. Und zum Basteln am STM32F429 reichen die allemal: die liefen hier auf Anhieb.
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?
m.n. schrieb: > 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. :-) So sagte es fast wörtlich damals der ST-Mensch am Telefon - der hatte sich nämlich zuerst auch gewundert und dann intern nachgefragt. > @ Uwe.B. > Oder siehst Du irgendeinen Sinn darin? Ich zumindest eher nicht.
:
Bearbeitet durch Moderator
hier mal meine Quick+Dirty Lösung für ein Display am STM32F429-LTDC : http://www.dasrotemopped.de/index.php?var=projekte&nr=17 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. Vor dem Proggen unbedingt CubeMX installieren und DM00105879.pdf lesen. Gruß, dasrotemopped. @ 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.
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 ;-)
m.n. schrieb: > 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. Ja, das war auch wirklich das erste, was ich nach dem Auspacken gemacht habe: Display runter ;-) > @ 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. Das Runterlöten ist eigentlich nicht so schwer (zumal das Display dann eh in die Tonne wandert): einfach schön mit Flussmittel einpinseln und dann mit einer dicken Lötkugel langsam drüberwandern und gleichzeitig mit einer Zange die Folie abziehen. Den (bei mir 50-poligen) Adapter habe ich "extern" aufgebaut und diesen dann über die Header des Discovery verdrahtet (siehe obigen Link zum Foto) - das erspart das Gefummel direkt auf dem Discovery. Passende Adapterplatinen gibt es auch beim Ali.
m.n. schrieb: > @ Uwe.B. > Oder siehst Du irgendeinen Sinn darin? 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 ich persönlich würde das Display nicht per FMC betreiben wollen :-)
:
Bearbeitet durch User
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.
Angehängte Dateien:
-
Eval7Zoll_Ansicht.jpg
92 KB
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: > 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? Natürlich - ich habe mir nur zu dem Zweck das Board gekauft. Und selbstverständlich kann ich dann auch entscheiden, das Ding runterzuwerfen, weil es mich bei meinem Vorhaben stört. Ganz ehrlich - was soll man mit einem 2,4"-Briefmarkendisplay mit Touchfunktion in einer ernsthaften Anwendung anfangen? Wir wollten einen 429 mit RAM und ST-Link und erstmal schauen, wie unsere Grafikroutinen auf großen Displays laufen - da gibt es nichts Günstigeres als das Discovery. > 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? Es wurde nicht geschlachtet sondern genau eine Komponente durch eine andere ersetzt, die für unsere Zwecke sinnvoll ist. > 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. Wir brauchten hier erstmal etwas, um uns mit dem 429-LTDC vertraut zu machen - und das Disco leistet alles, was wir benötigen. > 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. Das Argument verstehe ich nicht. Es geht hier doch nicht um ein Endprodukt sondern ein Entwicklungssystem, an dem ich schnell Änderungen vornehmen können muss - und genau das leistet das Disco: da habe ich alle Anschlüsse rausgeführt und kann nach Belieben experimentieren. Und wer es nicht lose mag, der kann die Sachen auch problemlos fixieren. > Und jetzt muß ich hier lesen, wie selbst Leute aus der Branche wie du > sowas sinnlos zerbastelst. Zestörungswut? Für uns hier ist das sehr sinnvoll gewesen, weil wir so problemlos ein 7" anschließen konnten. Deine Bedürfnisse sind eben nicht zwangsläufig die Bedürfnisse anderer. Selbstverständlich wird auf Experimentierboards bei Bedarf gelötet und umgestrickt. Für mich ist ein Discovery kein heiliger Gral, der unbedingt unversehrt bleiben muss, sondern einfach nur ein Experimentier-PCB. Für 25€ fackel ich nicht lange damit, ein Display runterzuwerfen, das ich sowieso nie benötigen werde, weil es für sinnvolle Anwendungen viel zu klein ist.
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: > 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. MWn nur bis 512kB Flash - und das ist für unsere Anwendung zu wenig. Aber: der Op hat nach dem LTDC des STM32F429 gefragt. Da hilft ihm ein NXP-Verweis wenig. Und: was wir hier im Forum sicher nicht brauchen, ist noch ein Glaubenskrieg über Controllerfamilien. Da gibt es schon reichlich. Jede Familie hat ihre Vor- und Nachteile und jeder hat andere gründe, warum er gerade diesen Typ einsetzt. Wir sind bspw. mit der STM32-Familie und ihrer feinen Granulierung sehr zufrieden und kennen deren Macken. Die parallele Einarbeitung in eine zweite Familie und deren Macken lohnen sich für uns definitiv nicht - dafür machen wir zu wenig Umsatz mit der reinen Elektronik/Mikrocontrollern. Bei anderen Unternehmen wie bei Dir kann das natürlich ganz anders aussehen. > 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. Warum? Das Display läuft hier ohne irgendwelche Verrenkungen und der LTDC werkelt komplett im Hintergrund. Für uns war es hier einfach das Ziel, unsere Grafikroutinen bzgl. ChromeArt usw. testen zu können. Und das können (bzw. konnten) wir mit dem Board sehr gut. Das gesparte Geld fliesst dann in andere Dinge :-)
:
Bearbeitet durch Moderator
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?
@Christian, der F429 hat einen LCD-Controller (der unabhängig von der CPU läuft) 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 Der LTDC kann auch zwei Layer "Pages" gleichzeitig verwalten (sozusagen zwei komplette Bildschirminhalte) diese können dann etweder einzeln angezeigt werden (damit ist ein Grafik-Frame Buffer realisierbar) oder sie können beide gleichzeitig angezeigt werden wobei hier die Transparenz von einem Layer eingestellt werden kann
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
Christian J. schrieb: > > De facto ist das SDRAM bei Verwendung des Grafik Displays also ein > Schleichspeicher und eigentlich nicht mehr zu verwenden :-( > kommt halt immer auf die Anwendung an ich konnte mich bei allen meinen Projekten jedenfalls über die 8MB RAM nicht beschweren bei meinen Grafik-Anwendungen reicht ein Zugriff alle 50ms auf das Display RAM und es müssen ja nicht immer alle Pixel neu gezeichnet werden egal wie...dein Video sieht gut aus, jetzt fehlt noch über den Touch die Startpixel setzen/löschen zu können :-)
Hi Christian, eine andere Möglichkeit, die sich gerade bei ständig wechselnden Inhalten (im Idealfall Videos) anbietet, habe ich neulich hier skizziert: Beitrag "Re: Cortex M7 zu überzüchtet" Wenn man das programmtechnisch löst, kommt man so auch bei 7" ganz ohne externes RAM aus. Das kann eine interessante Option sein, falls der Controller leistungsmäßig nicht am Anschlag ist.
:
Bearbeitet durch Moderator
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.
zum LTDC gibt es massig DOKU z.B http://www.compel.ru/wordpress/wp-content/uploads/2013/11/1_LTDC_ChromeART.pdf da steht auch die Berechnung vom Timing drin da wirst du aber nicht viel ändern können, sonst zeigt das Display nichts mehr an
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.