Hallo zusammen, Ich arbeite schon seit längerem mit STM32 Controllern und ab und zu ist auch mal eine GUI Anwendung dabei. Daher erfreute es mich sehr das ST den TouchGFX Grafik Stack aufgekauft hat und mitlerweile sogar auch in CubeMX integriert hat. *** Ja, TouchGFX ist nun so wie es aussieht frei für die Nutzung mit STM Controllern (Nur am Rande weil ich hier im Forum noch nichts über die tolle Nachricht gelesen hab ;) ) *** Doch dann kam auch so gleich die Ernüchterung. Wie damals bei STemWin ist ein Projekt Export für VisualGDB leider nicht möglich sobald man den Grafik Stack einschaltet. Klar kann man noch auf SW4STM oder Atollic TrueStudio umsteigen da es für diese IDEs einen Projekt Export gibt, allerdings hat ein kurzer Versuch mit TrueStudio gezeigt, dass selbst das nicht ohne Probleme klappt. (Errors und Warnings zu Hauf) Ich hatte mir damals extra VisualGDB gekauft, nach langer Leidenszeit mit CooCox und ähnlichem, um endlich von dem Eclipse kram wegzukommen und weil ich einfach sehr gut mit Visual Studio zurechtkomme. Doch leider wird diese IDE nur sehr rudimentär von CubeMX unterstützt. Daher die Frage: Nutzt jemand von euch TouchGFX mit VisualGDB erfolgreich, und wenn ja, mit oder ohne CubeMX generierten Initcode ? Zum testen hab ich ein STM32F746 Eval hier, was aus dem TouchGFX Designer auch direkt läuft, allerdings eben nicht wenn ich das Projekt in Visual GDB portiere. Also wenn jemand ein Tipp hat wär ich sehr dankbar :) Viele Grüße Stefan
Eigentlich geht das mit CubeMX zwischenzeitlich recht gut. Welche Version von VisualGDB benutzt Du?
C. W. schrieb: > Eigentlich geht das mit CubeMX zwischenzeitlich recht gut. Welche > Version von VisualGDB benutzt Du? Ja da hatte ich mich etwas unklar ausgedrückt. Die Hardware Sachen klappen soweit ganz gut. Es geht eher darum wenn man die Middlewares nutzen möchte, wie den Grafik Stack.(Da diese wohl eine "advanced project structure" erforden, und man keine advanced projects für visualgdb oder makefile exportieren kann.) Ich nutze die Version 5.4 prev. 10, also die aktuelle von der Homepage.
Stefan F. schrieb: > allerdings eben nicht wenn ich das Projekt > in Visual GDB portiere. Was genau läuft denn da nicht? Die Quellcodedateien und Bibliotheken sollten sich doch auch in VisualGDB einbinden lassen, im Zweifelsfall manuell.
Dr. Sommer schrieb: > Was genau läuft denn da nicht? Naja es gibt ja die Möglichkeit in VisualGDB zb. Keil Projekte zu importieren. https://visualgdb.com/tutorials/arm/import/keil/ Also generiere ich mit CubeMX den Code für MDK ARM und importiere das ganze Projekt in Visual Studio. Danach kommen haufenweisse Fehlermeldungen bzgl. unbekannter asm Befehle und ähnlichem. Einiges davon bekommt man weg wenn man die Anleitung befolgt aber vieles auch nicht. Das sind meines Erachtens hauptsächlich unterschiede bei Instructions zwischen GCC und MDK ARM. Ich wollte mir eben ersparen die Linkerscripte und alles händisch anzupassen und hatte gehofft das so umgehen zu können. Aber vermutlich führt kein Weg dran vorbei im Moment die HW Inits mit Cube zu generieren und TouchGFX händisch zu inkludieren. (Hatte ich auch schon mal versucht aber irgendwann aufgegeben da die Projektstruktur und Menge an Files doch recht komplex ist.) Ich werde also nochmal einen Versuch starten und wenn ich die besagten Fehlermeldungen am Bildschirm habe hier mal posten. Danke schonmal für die Antworten
Stefan F. schrieb: > Also generiere ich mit CubeMX den Code für MDK ARM und importiere das > ganze Projekt in Visual Studio Generiere doch lieber ein Projekt für eine GCC basierte IDE. Es sollte doch möglich sein, die Quelltext-Dateien in ein neues VisualGDB Projekt zu übernehmen..
Dr. Sommer schrieb: > Generiere doch lieber ein Projekt für eine GCC basierte IDE. Ja. Keil hatte ich ja nur genutzt da es dafür eine Anleitung von Visual GDB gab die ganz einleuchtend klang und ich mir davon versprochen hab, dass das ganze makefile und linker Zeugs damit erschlagen wär :) Mir ist schon klar das man das auch alles händisch reinwurschteln kann, allerdings hatte ich halt gehofft das vielleicht jemand dafür schon eine elegantere Lösung gefunden hat. Wie gesagt das sind ein Haufen files aus 3 unterschiedlichen Quellen (Cube, VisualGDB und TouchGFX) und die alle unter einen Hut zu bringen inklusive FreeRTOS (mit dem ich bisher noch keinerlei Erfahrungen hab ausser ner Blinky Task) ist eben doch recht umständlich. Keil user laden das generierte Projekt und alles tut, und können sich dann um die eigentliche high level Programmierung kümmern. (Ich weiß ist meckern auf hohem Niveau, allerdings hab ich auch schon oft genug low level Sachen gemacht und wollte jetzt eigtl. was, dass schnelle Erfolge bringt shame lazy_me */shame* ) Aber wie gesagt, Ich werde jetzt nochmal versuchen das alles händisch unter einen Hut zu bringen und dann bei den konkreten Fehlermeldungen hier nochmal um Rat ersuchen :)
Das Thema würde mich auch brennend interessieren. Eigentlich ist die Übergabe zwischen Cube und Vgdb ja super gemacht und funktioniert dank GPDSC recht flott. Leider wird gerade diese Exportmöglichkeit beim Einbinden des Graphic Frameworks deaktiv geschaltet. Weiß jemand hier genaueres warum Cube das derzeit so handhabt?
touchGFX baut sich irgendwie als 'master' ein, das passt nicht zu der Struktur die Cube sonst anlegt. Wenn man da viel dran ändert wird das nicht mehr mit dem Designer zusammenpassen. Ich hatte auch mal damit gespielt, da gab es den Designer noch nicht. Das in ein Eclipse Projekt zu bringen war aufwändig und das möchte ich auch nicht nochmal von Hand machen. Aber super das touchGFX jetzt bei STM offen ist, für private Projekte waren mir die 3k€ auch etwas zuviel. Und dafür bekam man nicht alle Quellen, nur fertige Treiber Libs für Standardhardware. Habe gestern mal den Designer installiert, die Beispiele lassen sich wirklich mit einem Klick erstellen und auf ein Board laden, das ist sehr schön.
Wieso ist touchGFX eigentlich STM32-spezifisch? Eine GUI-Library sollte doch ziemlich Plattform-unabhängig sein, mindestens mal zwischen allen ARM-Prozessoren. Das riecht schon sehr nach forciertem Vendor-Lock-In...
ist nicht STM32 spezifisch, es gab auch Treiber für zB LPC4088. Das braucht wegen der Animaierten Sachen schnelle Grafik und da hat STM die Nase vorn wie ich das sehe, die Grafkikbeschleuniger der STM werden da genutzt. Ob es mit der Aquise durch ST den Support für andere noch gibt weiss ich nicht.
Johannes S. schrieb: > ist nicht STM32 spezifisch, es gab auch Treiber für zB LPC4088. Ach, auf der Website heißt es: "TouchGFX is a user-friendly graphical C++ tool integrated in the STM32 ecosystem." Aber ich finde es spannend dass hier "einfach so" eine C++-Bibliothek für Mikrocontroller angeboten und genutzt wird, und hier nicht sofort die Mistgabeln und Fackeln gezückt werden...
Die verwenden aber schon C++ für Fortgeschrittene und ein MVC Modell. Das Ergebnis ist dafür Smartphone like. Die Website ist auch neu, da ist nichts mehr von den anderen Plattformen zu sehen.
Johannes S. schrieb: > Die verwenden aber schon C++ für Fortgeschrittene und ein MVC > Modell. Interessant, kann man da ein paar Beispiele von sehen?
Die Website von TouchGFX hat sich seit ca. einem halben Jahr ständig verändert. Nun, seit einer Woche etwa gab es den großen Umschwung inkl. Download des Designers. Auch die Integration in Cube ist nicht sehr weit her... Es ist aber auf jeden Fall so, dass ST seit Juli das TouchGFX sein Eigen nennt: https://www.st.com/content/st_com/en/about/media-center/press-item.html/c2854.html Was offen bleibt ist die mögliche Codegenerierung für VisualGDB...
:
Bearbeitet durch User
Ach die hamm das gekauft? Da steht jetz die Frage im Raum was langfristig mit STemWin passieren wird. Da ich vorhab das mal für Projekte zu nutzen wär das schon interessant.
Mw E. schrieb: > Da steht jetz die Frage im Raum was langfristig mit STemWin passieren > wird. Das sagt mir meine Glaskugel zwar nicht aber dazu ein paar Gedanken: (ST)emWin kann ohne große Klimmzüge ein Display mit SPI z.B. an einen STM32F103C8 - kann man wohl bei TouchGFX auch hinbekommen aber nur mit im RAM gespiegeltem Displayinhalt emWin gibt es auch weiterhin für andere Controller fertig lizensiert gegen den Einwurf von Euros gibt es emWin auch zu kaufen um es mit jedem Controller benutzen zu können btw - Hat jemand Erfahrungen bezüglich der Unterschiede beim Bedarf an Speicher?
Dr. Sommer schrieb: > Interessant, kann man da ein paar Beispiele von sehen? hier ist ein Stück Doku: https://touchgfx.zendesk.com/hc/en-us/articles/205717801-The-Screen-Concept-and-Model-View-Presenter Es ist sehr einfach den Designer zu installieren (unter Windows jedenfalls) und ein Beispielprojekt aus einer Vorlage zu erstellen. Dann hat man den Quellcode wie ein Screen angelegt wird. Ich hatte mir das vor über einem Jahr angesehen und muss mich da auch erst wieder reinarbeiten. Mit dem Konzept kann man auch eine Simulation erzeugen die das gleiche Look & Feel hat wie auf dem µC. Der komplette Quellcode ist aber wie früher bei den Demos auch nicht drin, ein Teil ist in einer lib die MCU abhängig dazugelinkt wird. Nur wurde in der Demo zeitweise ein Wasserzeichen eingeblendet und das ist jetzt wohl nicht mehr drin.
C. W. schrieb: > btw - Hat jemand Erfahrungen bezüglich der Unterschiede beim Bedarf an > Speicher? touchGFX braucht viel Flash, die Fonts sind hochaufgelöst und Bitmaps werden in voller Farbenpracht mit Alpha Kanal gebraucht.
Johannes S. schrieb: > touchGFX braucht viel Flash, die Fonts sind hochaufgelöst und Bitmaps > werden in voller Farbenpracht mit Alpha Kanal gebraucht. Könnte man diesen Kladderadatsch nicht elegant in einen SPI-Flash auslagern?
ja, das wird in den umfangreicheren Demos auch gemacht, da sind die Resourcen einige MB gross.
Angehängte Dateien:
-
PreBuild.PNG
36 KB -
BuildOutput.PNG
29 KB
Also hab mal wieder weitergemacht und bin nun wieder an dem Punkt wo ich die Fehlermeldung habe wenn ich es versuche über das Makefile zu integrieren. Anleitung hierfür: https://touchgfx.zendesk.com/hc/en-us/articles/206116381-Using-other-IDEs-with-TouchGFX Versuch nach Methode 1. Das Make von dem durch TouchGFX Designer generierten Projekt wird hierbei vor dem eigentlichen build Prozess ausgeführt und liefert den Output wie auf dem Bild zu sehen ist. Vermutung ist nun, dass entweder das aktuelle arm none eabi diesen einen Befehl nicht (wc) nicht kennt oder Ich das ganze hier irgendwie falsch aufrufe. Eine andere Vermutung ist das er den Treiber um den extrernen Flash zu flashen vermisst. Dazu gäbe es auch eine Anleitung bei VisualGDB: https://visualgdb.com/tutorials/arm/stm32/flash/ Allerdings hatte ich gehofft das das nicht nötig ist. Komischerweise läuft das Makefile sauber durch wenn ich es in dem TouchGFX Environment mache. Nach dieser Anleitung: https://touchgfx.zendesk.com/hc/en-us/articles/206116381-Using-other-IDEs-with-TouchGFX unter Methode 1 beschrieben. Das besagte Makefile ist auch im Anhang. Bei Bedarf oder falls es jemand hilft kann ich auch das gesamte Projekt hochladen. Vielleicht hat ja jemand einen Tipp :) Ansonsten würde ich als nächstes wohl oder übel versuchen des External Flash loader irgendwie reinzubekommen :D Grüße Stefan
Stefan F. schrieb: > Vermutung ist nun, dass entweder das aktuelle arm none eabi diesen einen > Befehl nicht (wc) nicht kennt oder Ich das ganze hier irgendwie falsch > aufrufe. Der gehört überhaupt nicht zum GCC, sondern zu Unix ("Word Count"). Schau doch mal ob bei TouchGFX eine wc.exe dabei ist und füge deren Verzeichnis zur Path-Variable hinzu. Genau hier offenbaren sich die Probleme von Code-Generatoren - anscheinend braucht man das makefile vom Generator, welches ein bestimmtes Tool braucht, die Integration wird schwierig... Wäre es nur eine "normale" Bibliothek die man nur inkluden/hinzulinken müsste, und würde man seine GUI mit handgeschriebenem Code bauen (bei vernünftigem API kein Problem), hätte man solche Probleme nicht.
Hmm, auch ne interessante Thesis. Aber, sieht das wirklich nach einem Programm-Aufruf aus?
1 | ifeq ($(shell find "$(application_path)" -wholename "$(application_path)/$(binary_output_path)/extflash.bin" -size +0c | wc -l | xargs echo),1) |
(Zeile 311)
Stefan F. schrieb: > Aber, sieht das wirklich nach einem Programm-Aufruf aus? Ja. Es werden "find", "wc", "xargs" und "echo" aufgerufen.
Genauer: es wird geprüft ob die Datei existiert und nicht leer ist. Auf etwas kuriose Art...
Gleiches bei mir... Ich bekomme es einfach nicht zum Laufen in Verbindung mit eigenem Code.
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.