News Hands-On mit Qt for MCUs – QML-Parser ohne Komfortfunktionen


von Tam H. (Firma: Tamoggemon Holding k.s.) (tamhanna)


Angehängte Dateien:

Lesenswert?

Nach Nokias Übernahme von Trolltech erlebte das C++-Framework eine Hochblüte: im Vergleich zu “klassischem C++” ist Qt zugegebenermaßen bequemer. Die Microcontroller-Variante hat mit der Vollversion außer dem Namen nichts gemein. von Tam HANNA

Worum geht es hier?

Qt ist ein nach dem in Abbildung eins gezeigten Schema aufgebautes Cross-Plattform-Framework, das im Zusammenspiel mit Erweiterungen des nativen Compilers der Plattform native Applikationen erzeugt.

Für Qt spricht neben dem immensen Funktionsumfang der Bibliotheken und den leistungsstarken GUI-Stacks vor allem die Erweiterung von C++ um Komfortfunktionen. Feature Nummero eins ist das Signal-Slot-System, das “eventorientierte” Verbindungen zwischen Klassen erlaubt:

1
QPushButton *button = new QPushButton;
2
QObject::connect(button, &QPushButton::clicked, someFunction);

Zudem implementieren von QObject abgeleitete Klassen ein Parent-Child-System, das grundlegende Garbage Collection realisiert.

Exkurs: QML

Qt’s für die Desktopentwicklung vorgesehener GUI-Stack erfuhr mit Qt 4.7 eine Erweiterung: eine als QML bezeichnete und auf einem JavaScript-JSON-Parser basierende Sprache sollte Entwicklern die Erzeugung von “animationsintensiven Applikationen” für Smartphones ermöglichen.

1
Rectangle {
2
    width: 200
3
    height: 100
4
    color: "red"
5
6
    Text {
7
        anchors.centerIn: parent
8
        text: "Hello, World!"
9
    }
10
}

QML erlaubt das Einbinden von JavaScript-Ausdrücken, um auf von Steuerelementen erzeugte Ereignisse zu reagieren:

1
    menuBar: MenuBar {
2
        Menu {
3
            title: qsTr("File")
4
            MenuItem {
5
                text: qsTr("&Open")
6
                onTriggered: console.log("Open action triggered");
7
            }

Im Hintergrund bietet die Engine Integration mit selbst erzeugten C++-Klassen:Nach der initialen Umstellung liess sich mit dem Produkt, insbesondere nach der Finalisierung der Steuerelementebibliothek, bequem arbeiten.

Qt für Microcontroller: nur QML

Im Microcontrollerbereich kommt eine als Qt Ultralight bezeichnete Plattform zum Einsatz, die auf die in Modulen wie Qt Core und Qt Gui enthaltene Unterstützung verzichten muss – daraus folgt unter Anderem das Fehlen des weiter oben beschriebenen Signal-Slot-Systems. Die Bereitstellung von QML im Microcontrollersystem erfolgt zudem nicht durch einen auf dem Embeddedsystem lebenden Parser. Qt Creator wandelt die QML-Dateien stattdessen am Desktop in C++-Dateien um, und kompiliert diese:

1
    // height: 290
2
    // line 5  "C:/Users/tamha/Documents/MyMCU/MyMCU.qml"
3
    height.setValue(290);
4
    // width: 480
5
    // line 4  "C:/Users/tamha/Documents/MyMCU/MyMCU.qml"
6
    width.setValue(480);

Qt-Applikationen lassen sich per Qt for MCUs 1.9 nur eingeschränkt debuggen: Das von anderen Zielsystemen bekannte direkte Debugging aus der IDE Qt Creator heraus funktioniert nicht. Stattdessen ist entweder manuelle Aktivierung (Stichwort GDB) oder der Umweg auf die hauseigene IDE des Herstellers (Renesas) erforderlich. Beachten Sie zudem, dass Qt im Mikrocontrollerbereich unbedingt die Kompilation unter Nutzung von CMake voraussetzt: die Arbeit mit .pro-Dateien ist nicht möglich. Dafür ist die Hardwareunterstützung vergleichsweise breit – laut https://doc.qt.io/QtForMCUs/qtul-supported-platforms.html kommen MCUs von Infineion, NXP, Renesas und STM gleichermaßen zum Einsatz.

Lohnt es sich?

Qt ist auf keinen Fall billig, da die quelloffene Version nicht für die Arbeit mit Microcontrollern zugelassen ist. Möchten Sie für Microcontroller entwickeln, so ist auf jeden Fall eine kommerzielle Version erforderlich. Die Small Business-Lizenz um 499USD / Jahr setzt bei der Entwicklung von Embeddedsystemen pro Runtime Zusatzkosten voraus – die Qt Company veröffentlicht diese zum Zeitpunkt der Drucklegung nicht einmal, sondern nennt sie nur auf Anfrage (siehe https://www.qt.io/pricing#packages).

Da der Gutteil der vom Desktop bekannten Support-Infrastruktur in Qt for MCUs fehlt, ist die “Value Proposition” weniger klar. Enthält Ihr Code (wie die meisten Qt-Applikationen) Qt Core-basierte Klassen, so müssen Sie diese auf gewöhnliches C++ umschreiben. Qt hält sich zudem aus dem Thema Hardwarezugriff heraus, was den bei Portierungen anfallenden “Gewinn” durch Aufwandsreduktion einschränkt. Zu guter Letzt bieten Anbieter von Mikrocontrollern bieten heute hauseigene, durchaus komfortable GUI-Stacks an. Behalten Sie diese bei der Kaufentscheidung für und gegen Qt auf jeden Fall im Hinterkopf...


: Bearbeitet durch NewsPoster
von Olaf (Gast)


Lesenswert?

Man sollte sich vor allem mal klar machen was die mit "Mikrocontroller" 
meinen. Ich hab mal Qt Embedded auf dem Sharp Zaurus (und dem 
Chumbi)benutzt. Das war vor 15Jahren ihr erster Versuch sowas zu machen. 
Das lief damals auf einem 266Mhz Arm gerade eben so.
Das erklaert auch warum sie die aktuelle Funktionalitaet so eindampfen 
mussten.

Von daher ist das ganze also totaler Quatsch. Vor allem wenn man bedenkt 
das man ja nicht zum Selbstzweck programmiert sondern damit auch 
irgendein Problem loesen will.

Ich koennte mir aber vorstellen das es in naher Zukunft anfaengt sinn zu 
machen. Wenn wir alle als Mikrocontroller einen Dualcore mit 2x500Mhz 
haben dann koennte ein Core sich um Qt kuemmern und einer kuemmert sich 
um die harten Timing abhaengigen Sachen.

Aber natuerlich man sollte auf keinen Fall etwas entwickeln wollen wo es 
auf Kosten oder Stromverbrauch ankommt weil es ohne Qt immer 10x 
schneller und 100x Stromsparender geht. Aber sicherlich weniger huebsch 
und mit mehr Entwicklungszeit.

Es waere vielleicht interessant es heute nochmal mit QT Embedded zu 
versuchen. Ist natuerlich eingeschraenkter als aktuelles Qt, aber halt 
auch kleiner und weniger Resourcen fressend.

Olaf

von Tam H. (Firma: Tamoggemon Holding k.s.) (tamhanna)


Lesenswert?

Olaf schrieb:
> Man sollte sich vor allem mal klar machen was die mit "Mikrocontroller"

Erstmal danke für dein Kommentar. Sorry für die kurzen Antworten, ich 
bin nicht pampig sondern extrem überarbeitet. Kundin ist aus Bankrott 
zurück dank einer RIESEN Investition eines Yachtherstellers und ich - 
funktionaler Nichtschwimmer und Meerwasserphobiker (!!!) - habe nun jede 
Menge neue Probleme als Chefentwickler.

> meinen. Ich hab mal Qt Embedded auf dem Sharp Zaurus (und dem
> Chumbi)benutzt. Das war vor 15Jahren ihr erster Versuch sowas zu machen.
> Das lief damals auf einem 266Mhz Arm gerade eben so.
> Das erklaert auch warum sie die aktuelle Funktionalitaet so eindampfen
> mussten.

Meiner Meinung nach nicht komplett. Ich sehe darin eher eine 
(absichtliche) Designentscheidung, um sich den Affentanz mit TCP/IP und 
Co zu ersparen.


> Ich koennte mir aber vorstellen das es in naher Zukunft anfaengt sinn zu
> machen. Wenn wir alle als Mikrocontroller einen Dualcore mit 2x500Mhz
> haben dann koennte ein Core sich um Qt kuemmern und einer kuemmert sich
> um die harten Timing abhaengigen Sachen.

Qt lief auf 486ern!

>
> Aber natuerlich man sollte auf keinen Fall etwas entwickeln wollen wo es
> auf Kosten oder Stromverbrauch ankommt weil es ohne Qt immer 10x
> schneller und 100x Stromsparender geht. Aber sicherlich weniger huebsch
> und mit mehr Entwicklungszeit.
>
> Es waere vielleicht interessant es heute nochmal mit QT Embedded zu
> versuchen. Ist natuerlich eingeschraenkter als aktuelles Qt, aber halt
> auch kleiner und weniger Resourcen fressend.
>

Meiner Meinung nach wäre die Lösung für Qt, zu sagen FdK, und alle Tiere 
auf ein Schiff zu packen. Würde sich die Qt Company im Embeddedbereich 
beispielsweise auf Azure RTOS werfen, so hätten sie wieder eine - 
weitgehend - einheitliche Plattform und könnten zumindest Qt Core 
portieren.

Warum sie das nicht tun, kA....

von Olaf (Gast)


Lesenswert?

> Qt lief auf 486ern!

Ja, aber auch lahm. Und am Anfang nur mit 256Farben oder SW.

> Warum sie das nicht tun, kA....

Ist halt irgendwie so eine Art grosse Firma, dreimal zwischenzeitlich
verkauft und irgendwie wollen sie nun etwas Geld verdienen, wissen
aber noch nicht so genau wie es am besten geht. Und Microsoft, Google
und Amazon wollen auch noch die Weltherrschaft auf der MCU.
Frueher war einfacher. :-D


Olaf

von Tam H. (Firma: Tamoggemon Holding k.s.) (tamhanna)


Lesenswert?

Olaf schrieb:
>> Qt lief auf 486ern!
>
> Ja, aber auch lahm. Und am Anfang nur mit 256Farben oder SW.

Das stimmt. Wobei: heutige Controller sind im Bereich GUI immense 
"Powerhouses". Die kleine Trottel-Demoapplikation (siehe 
https://www.instagram.com/p/CRPMKKnnhwd/) die SGS dem Board beilegt, 
zeigt Visuals, die du damals nicht gekriegt hast.

>
>> Warum sie das nicht tun, kA....
>
> Ist halt irgendwie so eine Art grosse Firma, dreimal zwischenzeitlich
> verkauft und irgendwie wollen sie nun etwas Geld verdienen, wissen

Ja. Das stimmt. Und zum auf Embarcadero schauen sind sie zu doof. Das 
Problem ist, viele der "Idioten" bei Nokia haben in der Qt Company ein 
neues Haus gefunden. Ich habe damals ja für Nokia entwickelt...und da 
gibt es einiges an Charakterkoepfen.

> aber noch nicht so genau wie es am besten geht. Und Microsoft, Google
> und Amazon wollen auch noch die Weltherrschaft auf der MCU.
> Frueher war einfacher. :-D

mE nach nicht. Wenn ich die Qt Company wäre, würde ich alles Holz auf 
ein Boot werfen und entweder Microsoft oder Amazon als meinen "neuen 
Retter" auserwaehlen.

>
>
> Olaf

von 123 (Gast)


Lesenswert?

Hallo,

Meinermenung nach hat QT ein Problem mit den Lizenzen und Kosten:
Als ich vor etlichen Jahren mal angefragt hatte war das für kleine - 
mittlere Projekte im Embedded bereich nicht abbildbar. Und da glaube hat 
sich nicht wirklich viel getan.

Wer 2x 500Mhz hat vermutlich eine MMU mit an board und kann gleich linux 
einsetzen. Dann braucht man sich um "embedded" und "mcu" keine gedanken 
machen. da tuts dann auch die OSS version.

von Weltbester FPGA-Pongo (Gast)


Lesenswert?

Vielleicht könnte das System etwas für MultiCore FPGAs seon, wie die 
Zynq Ultrascale. Die haben Performance genug und auch den Bedarf für 
Strukturen wie wir sie von C+ / Qt kennen. Jedenfalls ein wenig ...

Wie man aber auf die Idee kommen kann, das kostenpflichtig zu machen, 
erschließt sich mir nicht. Damit wird es schwer, das System für 
Microcontroller zu etablieren. Dort geht es ja immer um Kosten und es 
wird der jeweils schwächste Prozessor gekauft.

Die Multi-Plattformlösungen, die sich weit ausgebaute libs leisten, um 
eine convenience in das Programmieren zu bringen, sind oft sehr 
zeitverschwenderisch. Bei PCs fällt das in der Regel wenig auf, aber aus 
Tests unserer SW-Abteilung weiß ich, dass QT-Programme mindestens 
10%-20% langesamer sind.

von Timo W. (Gast)


Lesenswert?

Qt macht sich mit der Lizenzpolitik selber kaputt. Es ist nicht mehr 
möglich das ohne komplette Offenlegung des codes zu benutzen oder eben 
eine absurde Summe zu zahlen für wohlgemerkt sehr viel freiwillige 
Entwicklungsarbeit. Eine Frechheit, was da passiert.

von Oliver S. (oliverso)


Lesenswert?

Timo W. schrieb:
> Es ist nicht mehr
> möglich das ohne komplette Offenlegung des codes zu benutzen oder eben
> eine absurde Summe zu zahlen für wohlgemerkt sehr viel freiwillige
> Entwicklungsarbeit.

Den Zusammenhang zwischen der freiwillige Entwicklungsarbeit und der 
kompletten Offenlegung hast du aber schon verstanden, oder?

Oliver

von Timo W. (Gast)


Lesenswert?

Oliver S. schrieb:
> Timo W. schrieb:
>> Es ist nicht mehr
>> möglich das ohne komplette Offenlegung des codes zu benutzen oder eben
>> eine absurde Summe zu zahlen für wohlgemerkt sehr viel freiwillige
>> Entwicklungsarbeit.
>
> Den Zusammenhang zwischen der freiwillige Entwicklungsarbeit und der
> kompletten Offenlegung hast du aber schon verstanden, oder?
>
> Oliver

Was erzählst du da?

von MaNiw (Gast)


Lesenswert?

Tam H. schrieb:
> im Vergleich zu “klassischem C++” ist Qt zugegebenermaßen bequemer

"Im Vergleich zu Apfelkompott enthält Spanferkel zugegebenermaßen mehr 
Birnen und ist gleichzeitig vegan" hat eine ähnliche Sinnhaftigkeit wie 
die obige Nonsense-Wortaneinanderreihung

von Rolf M. (rmagnus)


Lesenswert?

123 schrieb:
> Wer 2x 500Mhz hat vermutlich eine MMU mit an board und kann gleich linux
> einsetzen. Dann braucht man sich um "embedded" und "mcu" keine gedanken
> machen. da tuts dann auch die OSS version.

Da würde ich aber davon ausgehen, dass das erheblich mehr Ressourcen 
kostet als eine Bare-Metal-Version.

Weltbester FPGA-Pongo schrieb im Beitrag #6756200:
> Wie man aber auf die Idee kommen kann, das kostenpflichtig zu machen,
> erschließt sich mir nicht. Damit wird es schwer, das System für
> Microcontroller zu etablieren. Dort geht es ja immer um Kosten und es
> wird der jeweils schwächste Prozessor gekauft.

Du vermischst da die Entwicklungskosten mit den Herstellungskosten. 
Klar, für eine Klitsche, die im Jahr 10 Stück ihres Produkts verkauft, 
ist das ein riesiger Posten. Aber wenn ein Autohersteller das in der 
Telematik-Einheit seiner Fahrzeuge einsetzt und dann jedes Jahr eine 
halbe Million davon verkauft, dann sind die Lizenzkosten für Qt Peanuts.
Wobei es sich auch für die Klitsche lohnen kann, sofern damit die 
Entwicklung beschleunigt werden kann.
Blöd ist das Ganze für Einzelstücke wie Prototypen und dergleichen.

Timo W. schrieb:
> Oliver S. schrieb:
>> Timo W. schrieb:
>>> Es ist nicht mehr
>>> möglich das ohne komplette Offenlegung des codes zu benutzen oder eben
>>> eine absurde Summe zu zahlen für wohlgemerkt sehr viel freiwillige
>>> Entwicklungsarbeit.
>>
>> Den Zusammenhang zwischen der freiwillige Entwicklungsarbeit und der
>> kompletten Offenlegung hast du aber schon verstanden, oder?
>>
>> Oliver
>
> Was erzählst du da?

Du siehst deinen Widerspruch nicht? Du erwartest, dass die Qt-Company 
das ganze für umme bereit stellt, weil ja viel freiwillige 
Entwicklungsarbeit reingeflossen ist, damit du es dann als Closed-Source 
verkaufen kannst.

von Oliver S. (oliverso)


Lesenswert?

Nee, er erwartet, daß alle diejenigen, die das unter der GPL gemacht 
haben, unter vollem Bewusstsein, was das bedeutet, jetzt auf ihre Rechte 
verzichten sollen.

Oliver

von Rolf M. (rmagnus)


Lesenswert?

Oliver S. schrieb:
> Nee, er erwartet, daß alle diejenigen, die das unter der GPL gemacht
> haben

Niemand hat zu Qt Code ausschließlich unter GPL beigetragen.

von Olaf (Gast)


Lesenswert?

> Telematik-Einheit seiner Fahrzeuge einsetzt und dann jedes Jahr eine
> halbe Million davon verkauft, dann sind die Lizenzkosten für Qt Peanuts.
> Wobei es sich auch für die Klitsche lohnen kann, sofern damit die
> Entwicklung beschleunigt werden kann.

Ganz so einfach ist das nicht. Wenn du etwas in grossen Stueckzahlen
verkaufst sind da die Entwicklungskosten erstmal nebensaechlich,
aber wenn du ohne Qt-Embedded mit einem kleineren Controller auskommst
dann bringt das ploetzlich richtig Kohle weil du bei jeder Platine
einen Euro einsparst.

Olaf

von Oliver S. (oliverso)


Lesenswert?

Rolf M. schrieb:
> Niemand hat zu Qt Code ausschließlich unter GPL beigetragen.

Ok, QPL

Oliver

von Dennis (Gast)


Lesenswert?

Qt ist LGPL, was heißt man darf nur dynamisch linken aber seinen Code 
als closed source verkaufen. Man muss nur aufpassen keine GPL 
Komponenten zu benutzen. Wer nur Widgets und Core benutzt hat also keine 
Probleme.

von Johannes S. (Gast)


Lesenswert?

Tam H. schrieb:
> Das stimmt. Wobei: heutige Controller sind im Bereich GUI immense
> "Powerhouses". Die kleine Trottel-Demoapplikation (siehe
> https://www.instagram.com/p/CRPMKKnnhwd/) die SGS dem Board beilegt,
> zeigt Visuals, die du damals nicht gekriegt hast.

schönes Beispiel, es zeigt wie gut die Mitbwewerber schon sind :) 
touchGFX ist für mich noch das innovativste, das hat sich ST ja auch 
'gekrallt' und für private Anwendungen ist das afaik mittlerweile 
kostenlos und kann mit CubeMX auch einfach integriert werden. Es ist 
aber C++ und das ist für viele ja eine Hürde, auch wenn es einen Editor 
gibt der Code generiert. Das MVC Framework ist nicht ganz ohne und muss 
auch erstmal verstanden werden, dafür liefert es wirklich nette GUI. Für 
kommerziellen Einsatz bekommt man  Support von Draupner Graphics, und 
das was die liefern sieht sehr professionell aus. Es ist so eine Sache 
wenn ein Programmierer ein UI mit seiner UX baut...
Und dann gibt es natürlich noch einige länger etablierte wie emWin und 
viele andere. Für Hobby kann ich aber immer wieder nur lvgl empfehlen, 
da stecken auch zig Mannjahre Entwicklung drin, es hat einen hohen 
Standard erreicht und ist immer noch kostenlos. Ist ordentlich 
strukturiertes C und dank Userdata in vielen wichtigen Strukturen C++ 
freundlich, es soll auch ein C++ Interface bekommen, microPython 
Anbindung gibt es schon. Einen Editor gibt es mittlerweile auch, der 
soll aber Geld für weitere Entwicklung bringen und der Autor arbeitet an 
dem Verkaufsmodell. Allerdings kann man einfache GUI auch gut ohne 
diesen Editor erstellen weil die Positionierung mit relativen 
Abhängigkeiten sehr schön gelöst ist.

von Rolf M. (rmagnus)


Lesenswert?

Oliver S. schrieb:
> Rolf M. schrieb:
>> Niemand hat zu Qt Code ausschließlich unter GPL beigetragen.
>
> Ok, QPL

Das meine ich nicht. Wenn du zu Qt beiträgst, wählst du nicht eine 
einzelne Lizenz aus, unter der du das tust, sondern akzeptierst alle 
Lizenzen, unter denen der entsprechende Teil von Qt verfügbar ist, auch 
die kommerzielle.

Dennis schrieb:
> Qt ist LGPL, was heißt man darf nur dynamisch linken aber seinen Code
> als closed source verkaufen.

Ja, sofern man seinen Kunden die Möglichkeit bietet, die 
LGPL-Komponenten durch eigene zu ersetzen, was gerade im 
Embedded-Bereich nicht immer ganz einfach ist.
Außerdem sprichst du von der regulären Qt. Hier geht es aber um Qt for 
MCUs, welches es soweit ich sehen kann ausschließlich unter 
kommerzieller Lizenz gibt.

von Olaf (Gast)


Lesenswert?

> Für Hobby kann ich aber immer wieder nur lvgl empfehlen,

Sehe ich auch so. Vor allem kann man das schon sinnvoll auf einem 
kleinen
Controller mit 20-50Mhz Takt und sagen wir mal 32k Ram einsetzen.

> Allerdings kann man einfache GUI auch gut ohne
> diesen Editor erstellen weil die Positionierung mit relativen
> Abhängigkeiten sehr schön gelöst ist.

Ist bei Embedded eh nur nice-to-have. Schliesslich hast du da ja 
dedizierte Hardware die sich nicht aendert. Bei Qt wo du dasselbe 
Programm vielleicht auf einem PC und einem Hand laufen haben willst 
sieht das schon anders aus.

Olaf

von Dennis (Gast)


Lesenswert?

Rolf M. schrieb:
> Ja, sofern man seinen Kunden die Möglichkeit bietet, die
> LGPL-Komponenten durch eigene zu ersetzen, was gerade im
> Embedded-Bereich nicht immer ganz einfach ist.

Wenn das Geschäftsmodell erfordert, dass der Kunde keinen Softwarezugang 
zum Gerät hat ist das Müll. Mal abgesehen davon kann man dem Kunden 
sagen, dass die Garantie und Support weg ist wenn der was austauscht. 
Macht im kommerziellen Umfeld dann niemand.

von 123 (Gast)


Lesenswert?

ja die kleinen aber gemeinen unterschiede zwischen gpl/lgpl/agpl v2 und 
V3, ... wer kennt die nicht.

Bitte 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
Noch kein Account? Hier anmelden.