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?
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.
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/
Neuerdings gibt es auch QT für Mikrocontroller: https://www.qt.io/blog/2018/05/03/qt-microncontrollers-mcu
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.
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:
1 | RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE; |
2 | RCC_OscInitStruct.HSEState = RCC_HSE_ON; |
3 | RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON; |
4 | RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE; |
5 | //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)
|
6 | RCC_OscInitStruct.PLL.PLLN = 10; |
7 | RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV7; |
8 | RCC_OscInitStruct.PLL.PLLQ = RCC_PLLQ_DIV2; |
9 | 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?
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.
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
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.
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.