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