QML To STM32

[hp-freund (Gast)]

Moin,

hat sich schon jemand damit beschäftigt?

https://www.youtube.com/watch?v=2ZfESR3YjaM
https://www.youtube.com/watch?v=9wLCr7Mubo4

Der Ersteller schreibt das er mit seinen Programm aus dem QML Code den C 
Code für den STM32 macht. Die Frage ist nur: wie?

Irgendwo in den QT-Sources ist vermutlich jedes Grafikelement als 
Bitmuster abgelegt und ich vermute das er diese verarbeitet.

Wäre doch schön wenn man für den STM32 damit eine Oberfläche zusammen 
klicken kann oder?

Er schreibt auf Anfrage zu seinem Code:

There is no configuration or installation to do, it's just a ,Qt program 
that i have developed, that converts QML file to C source code for STM32

Jetzt frage ich mich ob es noch jemanden gibt der sich daran versucht 
hat...

[Arc N. (arc)]

Für den STM32F7 mit ucLinux gibt es Anleitungen...
http://www.emcraft.com/som/stm32f7/running-qt-gui

[hp-freund (Gast)]

Hallo Arc Net,

danke für den Hinweis.
Aber eigentlich geht es mit nur um die reine Grafik und 
Touch-Auswertung.
Also so wie im Video. Ohne Betriebssystem, einfach simpler C-Code zum 
einbinden in das eigene Projekt.

Auch die Kleinen sollen so aussehen wie die Grossen ;-)

[Arc N. (arc)]

hp-freund schrieb:
> Hallo Arc Net,
>
> danke für den Hinweis.
> Aber eigentlich geht es mit nur um die reine Grafik und
> Touch-Auswertung.
> Also so wie im Video. Ohne Betriebssystem, einfach simpler C-Code zum
> einbinden in das eigene Projekt.
>
> Auch die Kleinen sollen so aussehen wie die Grossen ;-)

Sowas hätte ich auch gerne. Vor allem wenn dann ein und dasselbe 
Framework für beides genutzt werden könnte...

Ob das so wie im Video dargestellt wird funktioniert, ist imo allerdings 
sehr fraglich.
Zitat von https://www.mentor.com/embedded-software/nucleus/ui/qt
"The Footprint Management Tool can produce an absolute minimum embedded 
library footprint of about 3MB. The footprint for the Washing Machine 
demonstration was reduced from ~13MB to ~4MB by using this tool."

Qt ohne OS?
http://doc.qt.io/qt-4.8/qt-embedded-porting-operatingsystem.html
"Qt for Embedded Linux is reasonably platform-independent, making use of 
the standard C library and some POSIX functions, but only a Linux 
implementation is publically available. If you are looking for a 
non-Linux commercial implementation, it is worth contacting 
[e-mail] to see if we can help."

[hp-freund (Gast)]

Arc N. schrieb:
> Ob das so wie im Video dargestellt wird funktioniert, ist imo allerdings
> sehr fraglich.

Ehrlich gesagt war ich mir auch nicht sicher ob das alles echt ist.
"kortex" schreibt das er nur einen Teil umgesetzt hat und man sieht auch 
das eine recht grosse Datenmenge geflasht wird.

Das Wichtigste schien mir die Erstellung der gezeigten Quelldateien die 
die Byte Arrays der Grafikelemente enthalten.

Wie wir bei anderen GUIs für STM32 gesehen haben geht das dann auch mit 
sinnvollen Datenmengen.

Es wäre einfach nur schön mal ein richtiges Konzept zu haben und nicht 
jedes Mal das Fahrrad neu zu erfinden.

Viele Ansätze gibt es ja schon für mehr oder weniger vollständige GUIs 
für µC, aber man kämpft sich doch jedes Mal wieder von vorne durch.

Es muss auch nicht unbedingt Qt sein, der Ansatz von UB in der 
Codesammlung ist auch nicht verkehrt. Dazu noch einen "Designer" für das 
leichte erstellen von Grafikelementen wäre auch eine feine Sache.

Im Grunde läuft alles auf die Erstellung der Grafik hinaus, bei der 
bestimmte Events ausgelöst werden können und Eigenschaften veränderbar 
sind.

[Sven B. (scummos)]

hp-freund schrieb:
> Irgendwo in den QT-Sources ist vermutlich jedes Grafikelement als
> Bitmuster abgelegt und ich vermute das er diese verarbeitet.
Äh, nein. So funktioniert das schon lange nicht mehr (wenn es je mal so 
funktioniert hat). So eine QtQuick-GUI wird heutzutage mit OpenGL 
gemalt, aus Primitiven.

> Der Ersteller schreibt das er mit seinen Programm aus dem QML Code den C
> Code für den STM32 macht. Die Frage ist nur: wie?
QML ist erstmal nur eine abstrakte Beschreibungssprache. Sowas wie ein 
Rectangle {} lässt sich bestimmt relativ leicht in C-Code übersetzen. 
Trotzdem eine coole Idee.
Dass allerdings die Features von QML unterstützt werden, die die Sprache 
wirklich sinnvoll machen (Bindings!) bezweifle ich stark. :)

[Sönke P. (snke_p)]

Vermutlich besteht sein Vorgehen i.w. darin, die Grafikelemente in ihren 
unterschiedlichen Betätigungszuständen als Bilder rendern zu lassen (sh. 
http://stackoverflow.com/questions/17090019/how-to-take-screenshot-qt-qml), 
die Geometriedaten der Elemente auszuwerten und dann das ganze mit ein 
wenig Klebecode auszugeben.

Statt QML hätte man in dem Fall dann prinzipiell auch HTML+CSS, SVG oder 
ein Gimp/Photoshop Bild mit entsprechenden Ebenen/Slices verwenden 
können.
QtCreator/QML hat halt den Vorteil, dass man den Renderer als Dreingabe 
hat und die konsistente Benamung der Elemente einfacher ist.

Frage mich nur, wie der rechtliche Status für den Einsatz solcher direkt 
von Qt abgeleiteten Widgets ist - aber vielleicht ist der Autor ja 
gerade deswegen lieber so schweigsam...