GUI Erstellung für STM32

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?

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.

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.

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

1

  /** Initializes the CPU, AHB and APB busses clocks 

2

  */

3

  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;

4

  RCC_OscInitStruct.HSEState = RCC_HSE_ON;

5

  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;

6

  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;

7

  RCC_OscInitStruct.PLL.PLLM = 1;

8

  RCC_OscInitStruct.PLL.PLLN = 8;

9

  RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV7;

10

  RCC_OscInitStruct.PLL.PLLQ = RCC_PLLQ_DIV2;

11

  RCC_OscInitStruct.PLL.PLLR = RCC_PLLR_DIV2;

12

  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)

13

  {.......

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.

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.