mikrocontroller.net

Forum: Compiler & IDEs GUI Erstellung für STM32


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Von Renesas kenne ich das Programm "GUIX", welches zur Erstellung 
grafischer Oberflächen benutzt wird. Man erstellt die Grafiken und 
Steuerelemente und das Programm erstellt alle notwendigen Dateien und 
Programmzeilen zur weiteren Verwendung der GUI.

Gibt es etwas vergleichbares für den STM32?

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist denn GUI-Implementierung spezifisch für den Mikrocontroller? 
Produziert das "GUIX"-Programm etwa keinen standardkonformen C(++)-Code, 
welchen man einfach auf den STM32 übernehmen kann, indem man lediglich 
den Low-Level-Treiber für LCD/Touch... anpasst? Ist die 
Wiederverwendbarkeit solcher Software so schlecht dass man für jeden 
Controller alles neu machen muss?

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe es, ehrlich gesagt, noch nicht getestet, da ich mit dem STM32 
bisher nicht entwickelt habe. Dieses Programm auch nicht von Renesas 
entwickelt. Es gehört zum ThreadX-RTOS Programmpaket. Dieses ist, sofern 
man Synergy von Renesas benutzt, kostenlos benutzbar. Der generierte 
Code ist natürlich kompatibel zum Synergy-BSP und ThreadX. STM32CUBE 
benutzt aber FreeRTOS und natürlich eigene BSP. Bevor ich mir die noch 
vorhandenen Haare raufe, ohne zu einem Ergebnis zu kommen, wollte ich 
dieses Sachverhalt erst mal abfühlen. Vielleicht hat das ja auch schon 
jemand hier getestet.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Den STM32 HAL willste eh nicht nutzen und erst garnicht wenn der vom 
Cube Autogeneriert wurde: Bugs, Bugs, Bugs

Von der GUIX Renesas Webseite:
With a complete WYSIWYG screen design environment for drag-and-drop 
design of UI screens, GUIX Studio™ automatically generates C code that 
is compatible with the GUIX™ library and ready to be compiled and run on 
Synergy MCUs.

Nicht, dass es am Ende noch ein Lizenzproblem gibt (Vendor Lockin)
Aber ThreadX wurde ja nun von Microschrott gekauft -> Lauf Forrest! 
Lauf!

ST bietet andere Tools an.
Es gibt ein Binary BLOB von Segger emWin, kostenlos nutzbar auf den 
STM32 (STemWin).
Das kommt dann mit den Seggertools.
Inzwischen ist ST weitergewandert zu TouchGFX:
https://www.touchgfx.com/

Autor: Klaus S. (skibby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Neuerdings gibt es auch QT für Mikrocontroller:
https://www.qt.io/blog/2018/05/03/qt-microncontrollers-mcu

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also was die Preise für GUIX angeht wird einem schlecht. Bei Synergy 
zahlt man es über einen etwas erhöhten Hardwarepreis. Bei geringer 
Stückzahl durchaus attraktiv, da man keine Anschaffungskosten für die 
Software hat. Von QT für Mikrocontroller habe ich auch schon gelesen. 
Wie verhält es sich denn mit der Lizenz? Auf der Website heißt es Open 
Source License (modified GPL). Was ist bei der Verwendung in 
kommerziellen Produkten zu beachten? Die Firmware, auch Teile davon, 
will ich unter keinen Umständen preisgeben.

@Mw E.
Was genau meinst Du mit Bugs? Softwareprobleme oder dass der generierte 
Code nicht läuft?

TouchGFX werde ich mir ansehen.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Bei kommerziellen Produkten kannste Qt ja auch kaufen.
Is dann aber auch nicht billig.

Die STM32 HAL Softwarequalität ist eben ziemlich indisch.
Du füllst da andauernd Configstructs mit uints und die Definitionen dazu 
sind defines.
Anstatt das mit enums zu machen damit einem die IDE beim struct bauen 
vorschlagen kann was da reinkönnte.
(Die wollen einen eben zum CubeMX zwingen)

Bei einem STM32L431 zB kondiguriiert CubeMX die HAL falsch.
Dadurch war der UART Takt total daneben:
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
RCC_OscInitStruct.HSEState = RCC_HSE_ON;
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
//RCC_OscInitStruct.PLL.PLLM = 1;                    << diese Zeile wird von CubeMX nicht generiert und steht daher auf 0 -> HAL nimmt defaultwert von 2, aber die PLL bekommt 1 im Register (also Cube/HAL UND! Hardware sind zueinander inkonsistent)
RCC_OscInitStruct.PLL.PLLN = 10;
RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV7;
RCC_OscInitStruct.PLL.PLLQ = RCC_PLLQ_DIV2;
RCC_OscInitStruct.PLL.PLLR = RCC_PLLR_DIV2;

Weiterhin ist das auch keine echte Hardware Abstraktion.
Du musst bei DMA Transfers immernoch wissen welcher DMA und welcher 
Channel/Stream diese Peripherie erreicht.
Ja da kann man auch gleich nach referenzmanual auf den Registern 
klimpern ;)

Der USB Host stack war ganz grauenhaft.
Der Interrupt vom USB Periph schreibt direkt in der Statemachine vom 
Task rum (der Task wartete grade auf was anderes).
Dadurch wird der Task zustand inkonsistent.

Und viele andere Dinge, aber die hätte ich mir echt mal aufschreiben 
müssen.

Also du brauchst mehr zeit diese "HAL" zu verstehen und dann die Bugs zu 
suchen wenn was nicht funzt als gleich selber zu schreiben.
Die Bitdefinitionen gibts ja ind en CMSIS Headern.

Was nutzen denn diese Renesas SOCs?

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mw E. schrieb:
> (Die wollen einen eben zum CubeMX zwingen)

Was spricht gegen den CubeMX?

Mw E. schrieb:
> Bei einem STM32L431 zB kondiguriiert CubeMX die HAL falsch.
> Dadurch war der UART Takt total daneben:RCC_OscInitStruct.OscillatorType
> = RCC_OSCILLATORTYPE_HSE;
> RCC_OscInitStruct.HSEState = RCC_HSE_ON;
> RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
> RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
> //RCC_OscInitStruct.PLL.PLLM = 1;                    << diese Zeile wird
> von CubeMX nicht generiert und steht daher auf 0 -> HAL nimmt
> defaultwert von 2, aber die PLL bekommt 1 im Register (also Cube/HAL
> UND! Hardware sind zueinander inkonsistent)
> RCC_OscInitStruct.PLL.PLLN = 10;
> RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV7;
> RCC_OscInitStruct.PLL.PLLQ = RCC_PLLQ_DIV2;
> RCC_OscInitStruct.PLL.PLLR = RCC_PLLR_DIV2;

Das hier hat CubeMX bei mir ausgespuckt (gleiche MCU):
.......
  /** Initializes the CPU, AHB and APB busses clocks 
  */
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
  RCC_OscInitStruct.HSEState = RCC_HSE_ON;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
  RCC_OscInitStruct.PLL.PLLM = 1;
  RCC_OscInitStruct.PLL.PLLN = 8;
  RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV7;
  RCC_OscInitStruct.PLL.PLLQ = RCC_PLLQ_DIV2;
  RCC_OscInitStruct.PLL.PLLR = RCC_PLLR_DIV2;
  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
  {.......

Mw E. schrieb:
> Was nutzen denn diese Renesas SOCs?

Das sind ganz normale MCU mit der Besonderheit, dass man beim Kauf eine 
Lizenz für genau ein Gerät mitkauft, für ThreadX, USBX, GUIX, NetX etc. 
pp. Das ist schon sehr sexy, man kann das alles ohne weitere 
Zusatzkosten nutzen und in seinen kommerziellen Produkten verkaufen. Für 
geringe Stückzahlen gut bezahlbar. Man hat so ohne Verrenkungen Zugang 
zu allen Notwendigen Softwaretools. Zwei Dinge, die mich stören: 1.: 
ThreadX gehört jetzt Macrosaft; 2.: Es existiert de facto keine richtige 
Community rund um den Synergy. Einzig das Forum "Renesasrulz.com" ist in 
der Lage, auf Fragen zu antworten, wobei es immer die selben 5 oder 6 
Leute sind, die Antworten. Oft wird man auf die Application Module 
Guides verwiesen, die aber horrend unvollständig und deshalb 
unverständlich sind. Außerdem ist das Forum komplett in englisch 
gehalten, was es IMHO nicht unbedingt einfacher macht. Da das Forum 
offensichtlich nur von Leuten in den USA betrieben wird, muss man einige 
Stunden Zeitverzögerrung hinnehmen. Das sind eben Gründe, die mich über 
einen Wechsel zu STM32 nachdenken lassen.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann ist DER Bug jetzt wohl weg?
Stell doch mal den RCC auf externes Quarz mit 16MHz und den HCLK auf 
80MHz.
Das Problem war Reproduzierbar, aber inzwischen ist bei mir auch ein 
neuerer CubeMX installiert.

Der CubeMX ist ganz nett um sich zu klicken wo dann welche Peripherie 
auf welchen Pin rausguckt und zum hin/her schubsen. (eine Periph kommt 
an mehreren Pins raus).
Sowie die passende MCU für seine Zwecke zu finden anhand der Suche.
Aber man sollte nie auf Code generieren klicken, dann graust es einen.

Das ThreadX kommt dann mit passenden MCU Treibern nehm ich mal an?
Genau die meinte ich oben und würd gern wissen wie Bugfrei die sind.
Atmel Softpack/ASF und STM32HAL sind ja leider keine Paradebeispiele.

Matthias schrieb:
> Dinge, die mich stören: 1.:
> ThreadX gehört jetzt Macrosaft
Au ja, das würde mich auch stören.

Bei FreeRTOS weis man nicht ob Amazon da irgendwann den Laden übernimmt.
Die haben ja einen Forg gemacht und basteln daran rum.

Wobei in der FreeRTOS FAQ was von stewardship steht also 
"Produktverwaltung"
Na Toll! :/

https://freertos.org/FAQ_Amazon.html

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias schrieb:
> Man erstellt die Grafiken und
> Steuerelemente und das Programm erstellt alle notwendigen Dateien und
> Programmzeilen zur weiteren Verwendung der GUI.

Wo ist eigentlich dein Problem?

Wie man Grafik auf nem µC macht?
Oder wie man prinzipiell ein Menüsystem macht?
Oder wie man einen Touchcontroller benutzt?

Oder was?

Schreib also erstmal, was du an grafischem Können bereits hast - ich 
meine nicht, ob du Picasso in den Schatten deiner selbst stellen kannst, 
sondern ob du bereits fähig bist, auf einem Grafik-LCD an deinem µC so 
etwas zu tun:

- Text in verschiedenen Fonts und verschiedener Farbe an frei wählbare 
Position zu schreiben
- Rechtecke in verschiedener Farbe und verschiedener Größe an frei 
wählbare Position zu zeichnen
- Linien von A nach B in verschiedenen Farben zu zeichnen

Dann reden wir weiter.

Zuvor hat das Ganze keinen Zweck, denn was würdest du erwarten, auf was 
für ein Layer so ein grafisches Menüsystem aufsetzt?

Die Reihenfolge von unten nach oben geht ja etwa so:
- reine Hardware in Form eines Bildwiederholspeichers
- Event-System
- GDI, das Linien, Rechtecke, Fonts, Fontverwaltung kann
- grafische Objekte wie Buttons, Paneele, Eingabezeilen, etc.
- Menüs mit Methoden, die die tatsächliche Arbeit anstoßen - per Events 
in's ausführende Untersystem in der Firmware.

Deine oben zitierten Worte deuten mir darauf hin, daß du von alledem 
nichts weißt oder wissen willst. Wo sollen dann Andere hier anfangen, 
dir Ratschläge zu geben?

W.S.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.