mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Qt for MCUs: Grafiktoolkit für Mikrocontroller


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Christoph B. (birki2k)
Datum:
Angehängte Dateien:
  • preview image for qt.jpg
    qt.jpg
    429 KB, 115706 Downloads

Bewertung
3 lesenswert
nicht lesenswert

Das Qt-for-MCUs-Toolkit ermöglicht es, grafische Oberflächen nun auch für kleinere Mikrocontroller der Cortex-M-Reihe mithilfe von Qt zu entwickeln. Bisher war dies leistungsfähigeren Controllern in Kombination mit einem passenden Betriebssystem vorbehalten.

So sind normalerweise etwa 256 MB Arbeitsspeicher in Kombination mit einer 500-MHz-CPU samt OpenGL-Unterstützung für die Nutzung von Qt von Nöten. Ein jetzt veröffentlichtes Video zeigt Demonstrationen unter anderem auf Basis des STM32F769i-DISCO, wobei kein zusätzliches Betriebssystem verwendet werden muss. Hier wird eine flüssige Anzeige mit 60 FPS auf dem mit 216 MHz getakteten Cortex-M7 bei einer Farbtiefe von 32 Bit demonstriert. Dabei werden zusätzlich zum Framebuffer nur wenige hundert Kilobyte SRAM benötigt.

Auf der Website von Qt können bereits Demoanwendungen heruntergeladen werden, wobei es am 4. September ein Webinar als Einführung in die Entwicklung mit Qt for MCUs geben wird. Darüber hinaus findet sich ein Blogeintrag über weitere Hintergründe auf der Website.


Autor: foobar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Dabei werden zusätzlich zum Framebuffer nur wenige hundert Kilobyte
> SRAM benötigt.

Na ja, im Blog sieht es etwas anders aus:

Widgets Demo:
  Firmware size: 6.6 MB.
  RAM required: 3.4 MB.

Quick/QML Demo:
  Firmware size: 9 MB.
  RAM required: 5 MB.

E-Bike Demo:
  Firmware size: 13 MB.
  RAM required: 10 MB.


Qt ist einfach fett - ne abgespeckte Minimalversion irgendwie auf den 
größten verfügbaren Cortex-Ms zum Laufen zu bekommen, reißt mich nicht 
gerade vom Hocker ...

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist das jetzt ein neuer Aufguss von Qt/Embedded?

https://www.linux-magazin.de/ausgaben/2003/07/futter-fuer-kleine-saurier/

> Qt ist einfach fett - ne abgespeckte Minimalversion irgendwie auf den

Naja, auf dem Sharp Zaurus laeuft es super. Und immerhin kommen jetzt 
die kleinen Mikrocontroller in die Leistungsklasse die man 2003 im PDA 
hatte.

Problem ist natuerlich das aktuelle Qt Versionen nicht mehr so 
performant sein werden wie die alten. Vielleicht sollte man sich die 
alte qte Version besorgen und selber auf seinen Controller anpassen. Das 
ist nicht so kompliziert wie es klingt. Ich hab das mal fuer den Chumbi 
gemacht.

Olaf

Autor: Jose (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kommt reichlich spät diese Möglichkeit.
Davon abgesehen ist man mit intelligenten HMIs wesentlich schneller in 
der Entwicklung (z.B. Nextion). Wenn man die Display-Aufgabe heutzutage 
nicht sowieso schon auf eine mobile Web-Schnittstelle legt.

Autor: Olaf (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
> Kommt reichlich spät diese Möglichkeit.

Naja, anfang 2000 finde ich jetzt nicht so spät. :-)
Sie versuchen es jetzt halt mal wieder.

> Davon abgesehen ist man mit intelligenten HMIs wesentlich schneller in
> der Entwicklung (z.B. Nextion).

Nicht das ich jetzt gerade die schon kenne, aber sowas hat ja im 
allgemeinen den Nachteil das du auf eine bestimmte Hardware festgelegt 
bist die auch noch eher teuer ist. Das ist eher so Industriekram fuer 
den Mittelstand wo man 50-100Geraete im Jahr braucht.

Eine Oberflaeche die es erlaubt fuer relativ(jaja) beliebige Hardware 
eine halbwegs moderne Oberflaeche ein System mit Grafikbedienung 
aufzusetzen wuerde ich schon interessant finden. Bisher gibt es doch da 
nur ein paar Tools von relativ kleinen aber gierigen Firmen die auch 
fuer jeden Kram gleich eine Lizenz verkaufen wollen.

Die Frage ist natuerlich ob Qt da der richtig Ansatz ist weil es ja ein 
sehr fetter Klotz ist bei dessen Entwicklung man gewiss nicht auf 
Effizienz und einen schlanken Fuss geachtet hat. Aber da die Controller 
mittlerweile in Leistungsklassen vordringen die bisher eher BueroPC 
vorbehalten waren, waechst vielleicht zusammen was bisher nicht zusammen 
gehoert hat.

Ich finde das Konzept jedenfalls interessant und werde da mal ein Auge 
drauf behalten.

Olaf

Autor: Markus F. (mfro)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Jose schrieb:
> Kommt reichlich spät diese Möglichkeit.

die Möglichkeit kommt nicht reichlich spät, die Möglichkeit gibt's, seit 
es Qt gibt (also praktisch schon immer).

Bloß kommt die Möglichkeit jetzt in vorgekauter Form.

Sagt mir das was über die sich verändernde Entwicklerwelt?

Autor: Michael (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Markus F. schrieb:
> die Möglichkeit kommt nicht reichlich spät, die Möglichkeit gibt's, seit
> es Qt gibt (also praktisch schon immer).

Olaf schrieb:
> Naja, anfang 2000 finde ich jetzt nicht so spät. :-)

Christoph B. schrieb:
> Bisher war dies leistungsfähigeren Controllern in
> Kombination mit einem passenden Betriebssystem vorbehalten.

Autor: Felix F. (wiesel8)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
foobar schrieb:
>> Dabei werden zusätzlich zum Framebuffer nur wenige hundert Kilobyte
>> SRAM benötigt.
>
> Na ja, im Blog sieht es etwas anders aus:
>
> Widgets Demo:
>   Firmware size: 6.6 MB.
>   RAM required: 3.4 MB.
>
> Quick/QML Demo:
>   Firmware size: 9 MB.
>   RAM required: 5 MB.
>
> E-Bike Demo:
>   Firmware size: 13 MB.
>   RAM required: 10 MB.
>
>
> Qt ist einfach fett - ne abgespeckte Minimalversion irgendwie auf den
> größten verfügbaren Cortex-Ms zum Laufen zu bekommen, reißt mich nicht
> gerade vom Hocker ...
Alles Fake News was ihr hier verbreitet ;)

Laut Heise 
(https://www.heise.de/developer/meldung/Embedded-Entwicklung-Qt-zielt-auf-Mikrocontroller-4502226.html):
Das Team spricht davon, dass man von "einer 12-MHz-CPU und 128 Bytes RAM träumen könnte",

Also läuft das auch garantiert mit Arduino in 144 FPS ;)

mfg

Autor: unwissender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
habe hier noch nen stm32F769 Disco liegen,
habe mir das demo geladen, allerdings sind darin 2 Dateien *elf und 
*hex,
egal welche ich auf das board packe bekomme ich ein "menü" mit vielen 
kacheln, welche aber lauter unlesbare Zeichen anzeigen (schwarz / weiß), 
gibt es irgendwo ein howto damit ich weiß wie ich das zum laufen 
bekomme?

Autor: dasrotemopped (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sind die ELF und HEX Dateien deutlsich größer als 2MB ?
Mit Sicherheit, denn die Grafikelemente sind bei so was auf das 512Mb 
QuadSpi Flash vom Board ausgelagert.
Also Qt fragen wie man das Demmo flashen soll.

Gruß,
dasrotemopped.

Autor: 123 (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
@Felix F. (wiesel8)
Mal wieder alternative Wahrheiten?
den wichtigen halb Satz danach lässt man unter den Tisch fallen. "was 
freilich für eine Anwendung mit grafischer Benutzerschnittstelle eine 
Illusion ist." Der CT Autor hat in der ersten Version, das englische 
Orginal auch etwas missverständlich wiedergegeben, und das dann glaube 
ich ergänzt.

"Let’s be clear from the beginning on what microcontrollers we’re 
talking about exactly because some might start to dream about MCUs with 
a 12 Mhz CPU and 128 bytes of RAM."

https://www.heise.de/forum/heise-Developer/News-Kommentare/Embedded-Entwicklung-Qt-zielt-auf-Mikrocontroller/Re-128-Bytes/posting-35098196/show/

PS: ich glaub ich hab die Ironie tags übersehen, ...

Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dasrotemopped schrieb:
> Sind die ELF und HEX Dateien deutlsich größer als 2MB ?
> Mit Sicherheit, denn die Grafikelemente sind bei so was auf das 512Mb
> QuadSpi Flash vom Board ausgelagert.
> Also Qt fragen wie man das Demmo flashen soll.
>
> Gruß,
> dasrotemopped.

Habe vor langer langer Zeit mal die St Referenz Firmware für das F7 
Demokit geflasht und da musste man auch noch extra Sonderdaten auf den 
Flash bringen. Wenn ich mich korrekt erinnere gab es damals ein Flash 
Util von St mit dem das am Ende recht schnell und einfach ging.

Autor: unwissender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Robert
Danke für den Hinweis, hier kann man mal wieder sagen
"wer lesen kann ist klar im Vorteil" es lag in der Zip sogar eine 
Anleitung bei, wie das geflasht werden muss. Habe ich einfach übersehen. 
Das Zauberwort heißt hier "External loaders"

Nun aber meine Einschätzung zu der Demo,
das läuft wirklich richtig schön flüssig, und hat nette (aber nicht 
störende) Übergangseffekte. Leider zeigt sie aber eben auch nur eine 
einfache Oberfläche für Home-Automation, hier würde ich gerne mehr 
Effekte sehen, um die Leistungsfähigkeit beurteilen zu können.

Allgemein bin ich aber noch nicht sicher wohin die Reise gehen wird,
derzeit sehe ich folgend Trends (rein subjektiv) was die Visualisierung 
mittels µC angeht:

 - So wie immer: 7seg-Anzeigen/LED, Zeichendisplay (z.B. 4x20 Zeichen), 
Graphikdisplay (mit eigenen Grafiken)
 - relativ dicker µC (z.B. STM32F7...) mit QT
 - mittlerer µC mit Grafikframework (z.B. TouchGFX)
 - CPU mit (embedded) Linux (z.B. Raspbery Pi) mit Oberflächen z.b. in 
QT
 - µC / CPU Kombination (z.b. STM32MP1...) mit (embedded) Linux, z.b. 
Phyton oder auch QT

wie ist eure Meinung zu dem Thema?

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> wie ist eure Meinung zu dem Thema?

Alles ist moeglich und alles wird bleiben. :-D

Wenn du z.B Geraete baust die dauerhaft direktem Sonnenlicht ausgesetzt 
sind dann sind die meisten coolen Grafik-LCDs vollkommen unbrauchbar. 
Und wenn du Geraete baust die mit wenigen <1mA laufen muessen dann hast 
du auch garkeine Grafik sonden nur einzeln ansteuerbare Segmente. Und 
wenn du Geraete baust die von -40Grad bis +80Grad laufen sollen dann 
hast du wieder andere Ansprueche.

Olaf

Autor: Jens G. (jensg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
unwissender schrieb:
> QT
>  - µC / CPU Kombination (z.b. STM32MP1...) mit (embedded) Linux, z.b.
> Phyton oder auch QT

"Python Tkinter" ist auch eine Alternative.

Autor: Hans_Dampf (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Vorgefertigte Lösungen sind für den Profibereich meines Erachtens eher 
weniger geeignet.

Selbst gefrickelte Fullcustom-Lösungen sind besser, um den RAM-Verbrauch 
und Laufzeit besser kontrollieren zu können.

Mit einiger Programmiererfahrung und Open-Source-Code z.B. von Arduino 
ADAFruit GFX geht das recht gut und man kann schon anspruchsvolle 
Grafiken damit erstellen, die zwar keine Übergangseffekte haben, aber 
gut und modern aussehen.


Das Problem ist aber die Entwicklungszeit, die investiert werden muss. 
Da muss eine Abwägung stattfinden, ob die In-House-Entwicklung 
wirtschaftlicher und zweckmäßiger ist, als eine Graphic-Library für MCUs 
zu kaufen.

Open-Source-Tools sind meistens weniger brauchbar, zumal bei den 
käuflichen GFX Libraries vom Hersteller auch Anpassungen vorgenommen 
werden können.

Autor: Daniel -. (root)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
für STMs ist meiner Meinung nach touchgfx die erste Wahl
ich hoffe, dass die bald 4.11 mit neuen widgets rausbringen
zumal Qt nur für nicht kommerzielle Projekte gebührenfrei ist

Autor: oiuz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel -. schrieb:
> zumal Qt nur für nicht kommerzielle Projekte gebührenfrei ist
Nein.

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja Moin,

einige komponenten von QT stehen mitlerweile unter LGPLv3 und nicht mehr 
unter v2.
Wenn man in einem embedded bereich ohne diese komponenten auskommt, dann 
gilt ja v2 was durchaus ok sein kann.
Wenn nicht, sollte man sich mit LGPLv3 auseinandersetzen, ... das wird 
in vielen kommerziellen embedded projekten das kill kriterium sein. (Der 
endkunde muss die QT lib selber tauschen können)

Und kommerziel waren die QT lizenzen im embedded bereich für kleinere 
bis mitlere stückzahlen nicht wirklich der hit von wegen kosten je 
stück. Ob das heute immer noch so ist, weiss ich nicht.

Autor: Raph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie würdet ihr denn für einen STM32 und einem 3,5" TFT z.b. einen 
künstlichen Horizont programmieren? Eventuell einen der einfach Daten 
von Seriell bekommt (z.B. einem Flugsimulator etc).

Die Grafik mit den ganzen Overlays ist schon recht komplex. Gefallen 
würde mir das z.b.

https://friebe.aero/bordinstrumente-und-zubehoer/kreiselgeraete/kuenstliche-horizonte/kuenstlicher-horizont-rca-2600-3-digital-r-c-allen.html

Mit nem STM32 habe ich das aus Spaß mal nachprogrammiert. Allerdings 
läuft das nicht flüssig. Also es wird das gesammte Bild bei jeder 
Änderung neu gezeichnet.

Wie würdet Ihr das mit dem STM32 machen und nur änderungen neu zeichnen?

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hans_Dampf schrieb:
> Mit einiger Programmiererfahrung und Open-Source-Code z.B. von Arduino
> ADAFruit GFX geht das recht gut

Und denn diese GFX Library nicht passt, kann man sich etwas 
vergleichbares auch relativ schnell selber bauen - wenn man Erfahrung 
damit hat.

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was heist nicht flüssig?
Wie sieht der ablauf aus?
Welche Frame rate hast du / erwartest du?
Das ist aber alles OT.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
123 schrieb:
> einige komponenten von QT stehen mitlerweile
> unter LGPLv3 und nicht mehr unter v2

Oh, das ist relevant. Danke für den Hinweis.

Autor: Hans H. (loetkolben)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oiuz schrieb:
>> zumal Qt nur für nicht kommerzielle Projekte gebührenfrei ist
> Nein.

Quelle?
Hier https://www.qt.io/download steht:

"Rights & Obligations - An obligation to share changes to Qt source code

“When we speak of free software, we are referring to freedom, not price 
(… ) To protect your rights, we need to prevent others from denying you 
these rights or asking you to surrender the rights. Therefore, you have 
certain responsibilities if you distribute copies of the software, or if 
you modify it: responsibilities to respect the freedom of others.” – GPL 
preamble

The majority of the Qt modules are licensed under LGPLv3, meaning that 
you...

    Must provide a relinking mechanism for Qt libraries
    Must provide a license copy & explicitly acknowledge Qt usage
    Must make a Qt source code copy available for customers
    Qt source code modifications aren’t proprietary
    Must make “open” consumer devices
    For Digital Rights Management please see: FAQ
    Special consideration should be taken when attempting to enforce 
software patents"

Dh. der Nutzer muß die Software gegen neue Qt libs linken können.
Und was mit 'Must make “open” consumer devices' gemeint ist wüßte ich 
dann auch gerne.

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hans H. schrieb:
> Und was mit 'Must make “open” consumer devices' gemeint ist wüßte ich
> dann auch gerne.

Lies einfach die deutsche Übersetzung des Lizenz-Textes: 
https://www.gnu.de/documents/lgpl-3.0.de.html

Ich halte den von Dir zitierten Satz für heiße Luft.

Autor: Hans-Georg L. (h-g-l)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ist mir gerade die Tage über den Weg gelaufen,
habe es aber noch nicht ausprobiert:
https://littlevgl.com

Autor: S. R. (svenska)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Ich halte den von Dir zitierten Satz für heiße Luft.

Hier bist du auf dem falschen Dampfer. Sowohl GPLv3 als auch LGPLv3 
enthalten die Tivoization-Klausel. Das heißt, es muss möglich sein, den 
Code zu bekommen; den Code zu verändern; den veränderten Code zu 
kompilieren; das veränderte Binary auszuführen.

Letzteres ist ein Problem für kommerzielle Nutzung.

Autor: Nickless (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genauso wichtig wie die Auswahl der GFX Library ist der Anschluss des 
Displays an den MCU.

Was wird hier benutzt? SPI ist wohl zu langsam für die riesigen 
Datenmengen. Einen LIDD-Interface haben nicht alle MCUs, außerdem sind 
das dann BGAs wegen den vielen Pins.
Genauso brauchen auch andere Interfaces wie 8080 oder MIPI DSI viele 
Pins.


Und was ist mit dem Framebuffer? Ein Cortex M4 hat bis zu 256 KByte RAM, 
aber ein Frame hat deutlich mehr Daten, die gepuffert werden müssten.

Häufig braucht man sogar mehrere Framebuffer, um den nächsten Frame 
vorzubereiten, wenn man sehr schnelle Übergänge oder Effekte haben will.
Dann braucht man auch SD-RAM.

Und man braucht einen QSPI-Flash, um die ganzen Grafikelemente zu 
speichern, da diese auf keinen Fall in den Flash des MCUs passen.

Wenn man noch viele Texte in verschiedenen Sprachen hat und viele 
(große) Schriftarten, müssten diese auch in den externen Flash.


Wie man sieht, ist eine ausgefeilte GUI nicht mal eben an einem 
Wochenende zusammengefrickelt, sondern ein mühseliges Langzeitprojekt.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Irgendwie klingt das so als will qt nicht mehr in kommerziellen 
Produkten verwendet werden?
Oder wenn man zahlt is Ruhe mit GPL?

Autor: foobar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Oder wenn man zahlt is Ruhe mit GPL?

Korrekt.  War schon immer so.  Btw, ca $5500/year/seat und bei embedded 
devices evtl ne Gerätegebühr.

Autor: Olaf (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> Korrekt.  War schon immer so.  Btw, ca $5500/year/seat und bei embedded
> devices evtl ne Gerätegebühr.

Naja, einerseits kann man sie verstehen. Von irgendwas muessen sie ja 
leben.

Andererseits denke ich heute bei Software (und auch bei Qt): Was soll 
der Scheiss? Irgendwann ist eine Software auch mal fertig entwickelt. 
Dann braucht man nur noch ein paar Leute um ab und an mal einen Fehler 
zu beheben und das reicht dann. Man muss nicht immer alles andauernd 
umkrempeln und aufblasen. Wir haben keinen Fachkraeftemangel in der IT, 
wir haben zuviele Programmierer die sich mit unnoetigem Zeug 
beschaeftigen.

Olaf

Autor: M. K. (sylaina)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Olaf schrieb:
> wir haben zuviele Programmierer die sich mit unnoetigem Zeug
> beschaeftigen

Nicht nur Programmierer, nicht nur ;)

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
S. R. schrieb:
> Sowohl GPLv3 als auch LGPLv3 enthalten die Tivoization-Klausel.

Wow, was für Wort-Monster! Davon bekomme ich Angst.

> Das heißt, es muss möglich sein, den Code zu bekommen; den Code
> zu verändern; den veränderten Code zu kompilieren; das veränderte
> Binary auszuführen.

Logisch, wie soll man den Code sonst gegen eine andere Version der 
Library linken können?

> Letzteres ist ein Problem für kommerzielle Nutzung.

Wenn man den Quelltext geheim halten will oder muss. Ja, dass muss man 
sich vorher überlegen.

Firmen können aber sicher (wie Espressif) auch hingehen, und einen 
wesentlichen Teil des Codes binär liefern. Hauptsache alle Teile, die 
von Qt abhängen sind Quelloffen. Richtig?

: Bearbeitet durch User
Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Olaf schrieb:
> Irgendwann ist eine Software auch mal fertig entwickelt.

Das schon, aber die Ergebnisse sehen irgendwann altmodisch aus. Deswegen 
wird Qt ja auch ständig verändert.

Versuche mal ein Programm zu verkaufen, dass wie Windows 95 aussieht 
während die Konkurrenz mit einer stylischen 
Klickibunti-Wackeldackel-Blinke-Oberfläche (wie Playstation 4 versus 
Geldautomat der 90er Jahre) ankommt.

Dann wird die modernere Oberfläche gekauft.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Versuche mal ein Programm zu verkaufen, dass wie Windows 95 aussieht

Fensterrahmen, Menüleiste, Toolbarbuttons und die ganzen anderen 
Widgets, ich kenne massenhaft Programme die das alles heute auch noch 
haben, da hat sich nichts nennenswert verändert.

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> Stefanus F. schrieb:
> Versuche mal ein Programm zu verkaufen, dass wie Windows 95 aussieht

Bernd K. schrieb:
> Fensterrahmen, Menüleiste, Toolbarbuttons und die ganzen anderen
> Widgets, ich kenne massenhaft Programme die das alles heute auch noch
> haben, da hat sich nichts nennenswert verändert.

Es geht nicht um die Existenz der Elemente, sondern um deren visuellem 
Stil.

Function follows Design. Nicht immer, aber immer öfter.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
>> Sowohl GPLv3 als auch LGPLv3 enthalten die Tivoization-Klausel.
> Wow, was für Wort-Monster! Davon bekomme ich Angst.

Das hat sich die FSF ausgedacht, nicht ich...

>> Das heißt, es muss möglich sein, den Code zu bekommen; den Code
>> zu verändern; den veränderten Code zu kompilieren; das veränderte
>> Binary auszuführen.
>
> Logisch, wie soll man den Code sonst gegen eine andere Version
> der Library linken können?

Der Unterschied zwischen GPLv2 und GPLv3 ist der letzte Punkt.
Den gab es in der GPLv2 nicht.

>> Letzteres ist ein Problem für kommerzielle Nutzung.
>
> Wenn man den Quelltext geheim halten will oder muss.
> Ja, dass muss man sich vorher überlegen.

Du missverstehst. Der Quelltext ist in jedem Fall offen (die ersten drei 
Punkte). Das Problem entsteht, wenn es rechtliche Grenzen gibt, was 
Modifikationen durch den Benutzer angeht.

Beispiel: Wenn in deinem Auto-Steuergerät GPLv3-Code drin ist, dann 
musst du als Endnutzer in der Lage sein, eine neue Firmware dafür zu 
bauen, zu flashen und zu benutzen.

Weil du durch sowas riskierst, dass dir der Motor zu einem ungeeigneten 
Zeitpunkt explodiert und Fußgänger tötet, ist sowas gesetzlich nicht 
erlaubt (Betriebserlaubnis). Also unterbindet der Hersteller das.

Und das widerspricht der GPLv3 (aber nicht der GPLv2).

> Firmen können aber sicher (wie Espressif) auch hingehen, und einen
> wesentlichen Teil des Codes binär liefern. Hauptsache alle Teile, die
> von Qt abhängen sind Quelloffen. Richtig?

Nein. Jeder Nutzer muss prinzipiell in der Lage sein, im Endgerät!, die 
von Qt abhängigen Teile zu ersetzen. Das unterläuft Prüfsummen, 
Signaturen, Verschlüsselung und so weiter für die gesamte Firmware.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist aber doch nur ein Problem bei der freien Version oder?
Als Hersteller ist es ja kein Problem einfach eine Lizenz zu kaufen. 
5kEuro sind zwar fuer mich als Privatpersonen viel Geld, aber fuer eine 
Firma ist das doch ein Witz. Da sehe ich also erstmal kein Problem.

Es macht es hoechstens unmoeglich das Einzelpersonen eine Firma 
aufziehen. Die koennen sich dann sowas eher noch nicht leisten.

Olaf

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Es geht nicht um die Existenz der Elemente, sondern um deren visuellem
> Stil.

Der wird eigentlich von der Desktopumgebung vorgegeben. Wenn Du die 
nativen Widgets auf der jeweiligen Plattform benutzt (oder ein Toolkit 
das das tut) hast Du immer das topaktuelle Design und immer genau die 
Grauschattierung und Schattenwurf die gerade hip sind.

Das andere Extrem sind dann Anwendungen die jedem Button und jeder 
Checkbox das CI ihrer Firma aufdrücken und dann immer und überall 
aussehen wie ein Fremdkörper, ein nicht zu unterschätzender Anteil der 
Nutzer mag das eigentlich gar nicht. Beim Mac sind die Nutzer in dieser 
Hinsicht noch radikaler und jagen solche Software einstimmig zum Teufel 
weil sie nicht das dort übliche traditionelle "Look and Feel" hat.

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Nein

Danke für die Klarstellung.

Autor: oiuz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> S. R. schrieb:
>> Sowohl GPLv3 als auch LGPLv3 enthalten die Tivoization-Klausel.
> Wow, was für Wort-Monster! Davon bekomme ich Angst.
Es geht hier aber nur um den Quellcode der unter LGPv3 steht. in 
diesem Fall also die Qt-Lib.
Es nicht um die (Kunden-)Applikation die gegen die LGPL-lizensierte 
Qt-Lib linkt.

S. R. schrieb:
> Stefanus F. schrieb:
>>> Sowohl GPLv3 als auch LGPLv3 enthalten die Tivoization-Klausel.
>> Wow, was für Wort-Monster! Davon bekomme ich Angst.
> Das hat sich die FSF ausgedacht, nicht ich...
Aus einem nachvollziehbaren Grund:
https://de.wikipedia.org/wiki/Tivoisierung

Hans H. schrieb:
> oiuz schrieb:
>>> zumal Qt nur für nicht kommerzielle Projekte gebührenfrei ist
>> Nein.
>
> Quelle?
> Hier https://www.qt.io/download steht:
> ...
Damit versucht man (Vertrieb Qt) dich zum Kauf zu bringen.

Autor: Max G. (l0wside) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Raph schrieb:
> Mit nem STM32 habe ich das aus Spaß mal nachprogrammiert. Allerdings
> läuft das nicht flüssig. Also es wird das gesammte Bild bei jeder
> Änderung neu gezeichnet.

Welchen STM32 hast du denn genommen, einen STM32F0 oder einen STM32F7, 
oder irgendwas dazwischen?

Das größte Geschoss (STM32F779) hat einen eingebauten "Graphics 
Accelerator" und ein MIPI-DSI-Interface, d.h. du kannst ein 
Standard-Display anschließen. Gibt es sogar im LQFP176, man muss also 
nicht mal BGA löten. Mit 2MB Flash und 512kB RAM läuft auch Qt drauf. 
Kostet aber auch 17 EUR je Stück.

Etwas bezahlbarer wird es mit einem STM32F746, der hat nur einen 
LCD-Controller an Bord, aber auch die Grafikbeschleunigung. Kostet um 
die 10 EUR je Stück.

Wenn du den elektronischen Horizont nachbauen willst, dürften die 
Teilekosten allerdings die geringste Rolle spielen. Das 
Zulassungsgeraffel für Luftfahrt wird dich (finanziell) vermutlich 
umbringen.

Autor: Lona (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> S. R. schrieb:
>> Sowohl GPLv3 als auch LGPLv3 enthalten die Tivoization-Klausel.
>
> Wow, was für Wort-Monster! Davon bekomme ich Angst.
>
>> Das heißt, es muss möglich sein, den Code zu bekommen; den Code
>> zu verändern; den veränderten Code zu kompilieren; das veränderte
>> Binary auszuführen.
>
> Logisch, wie soll man den Code sonst gegen eine andere Version der
> Library linken können?
>
>> Letzteres ist ein Problem für kommerzielle Nutzung.
>
> Wenn man den Quelltext geheim halten will oder muss. Ja, dass muss man
> sich vorher überlegen.
>
> Firmen können aber sicher (wie Espressif) auch hingehen, und einen
> wesentlichen Teil des Codes binär liefern. Hauptsache alle Teile, die
> von Qt abhängen sind Quelloffen. Richtig?

Theoretisch könnte man sich ja ein Bootloader schreiben, welcher dann 
über einen "Server" abfrägt ob die Checksumme des Kompillats korrekt ist 
und dann das Flashen freigibt. Also für den Anwender ohne Zugriff auf 
das Firmennetz wäre ein Flashen dann nicht mehr möglich?

Oder kann man beim STM32 den Bootloader auch wieder löschen und durch 
einen eigenen ersetzen?

Autor: Lona (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Max G. schrieb:
> Wenn du den elektronischen Horizont nachbauen willst, dürften die
> Teilekosten allerdings die geringste Rolle spielen. Das
> Zulassungsgeraffel für Luftfahrt wird dich (finanziell) vermutlich
> umbringen.

Da schreibt er aber was von Flugsimulator!

Ich denke er will ein Instrument nachbauen das er dann im FS benutzen 
kann. Sowas gibt es von vielen Hobbyfliegern (sehe Youtube).

Die Idee ist nicht blöd

Autor: Jens G. (jensg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das kann eine Alternative zu Qt sein - ist für die kommerzielle Nutzung 
etwas Preiswerter. Für die private Nutzung frei.

https://ugfx.io/  "µGFX is a lightweight embedded library for displays 
and touchscreens."

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Der STM32H750 ist schön günstig (5€) und hat alles was die anderen H7 
auch haben. Vor allem hat er viel mehr Takt als die F7, was doch zum 
Pixelschubsennur gut sein kann.
SDRAM ran, QSPI Flash ran und ab gehts.
Jedenfalls ist das meine Planung für ein Universal UI Projekt.
Umsetzung: irgendwann (tm)

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olaf schrieb:
> Als Hersteller ist es ja kein Problem einfach eine Lizenz zu kaufen.
> 5kEuro sind zwar fuer mich als Privatpersonen viel Geld, aber fuer eine
> Firma ist das doch ein Witz. Da sehe ich also erstmal kein Problem.

Hast ein Späß'le g'macht, was? :-D

Ich brauchte bei uns für ein Projekt mal eine Kalibrierkarte, musste 
bestellt werden. Darauf folgten zwei Monate, bis die 
Geschäftsbeziehungen zwischen den Firmen möglich waren, dann wurde durch 
einen Fehler die Bestellung nicht ausgelöst, was einen Monat nicht 
bemerkt wurde, und schließlich wurde noch einen Monat später die 
Bestellung nicht ausgelöst, weil das Projekt eingestellt wurde.

Die Karte hat einen Wert von ca. 75€. Der Verwaltungsaufwand (mindestens 
7 Personen in 3 Ländern beteiligt) betrug mindestens das 20-fache und am 
Ende wurde nichts bestellt.

Nee, "wir brauchen mal eben eine Qt-Lizenz für Projekt X" ist bald 
teurer (und dauert länger), als eben mal schnell ein komplettes 
Framework im Team selbst zu schreiben. Da überlegt man sich, ob man auf 
Qt setzen will.

: Bearbeitet durch User
Autor: Max G. (l0wside) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Nee, "wir brauchen mal eben eine Qt-Lizenz für Projekt X" ist bald
> teurer (und dauert länger), als eben mal schnell ein komplettes
> Framework im Team selbst zu schreiben. Da überlegt man sich, ob man auf
> Qt setzen will.

Das beschriebene Szenario kommt mir zwar bekannt vor.
Für ca. 5 TEUR im Jahr lässt sich ein Softwerker aber bestenfalls zwei 
Wochen beschäftigen (wenn er in Indien oder Bulgarien sitzt, vielleicht 
vier bis sechs). In der Zeit wird er Qt nicht nachprogrammieren, nicht 
mal ansatzweise.
Qt oder eine andere Library ist damit sicher die kostengünstigere Wahl. 
"Mal eben" führt man das aber sowieso nicht ein, die Einarbeitung ist 
nicht völlig trivial.

@fritzler: Danke für den Hinweis auf den H750. Der sieht echt spannend 
aus, vor allem mit 1 MB RAM und einem LCD-Treiber bis 1024x768.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Max G. schrieb:
> In der Zeit wird er Qt nicht nachprogrammieren, nicht mal ansatzweise.
> Qt oder eine andere Library ist damit sicher die kostengünstigere Wahl.

Die meisten Produkte brauchen aber auch nicht den gesamten Umfang von 
Qt, vor allem nicht im Anfangsstadium. Die später anfallenden Kosten für 
die Pflege... nun, die fallen später an.

Viel interessanter ist der Punkt, dass man erstmal ein Vierteljahr 
warten muss, bis es losgeht. Oder man riskiert eine Neuentwicklung nach 
Ablehnung durch die Bürokratie... denn Leute auf Entscheidungen sitzen 
lassen ist etwas anderes als Time-To-Market.

Sehr schizophren, ich weiß. Aber leider real. :-(

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Max G. schrieb:
> In der Zeit wird er Qt nicht nachprogrammieren, nicht
> mal ansatzweise.

Qt ist ja auch deutlich mehr als nur GUI widgets. Das enthält Klassen 
für fast jedes Problem das einem über den Weg laufen könnte wie 
Netzwerk, Bluetooth, Gamepads und Joystick, Audio, Video, Streaming, 
Kamera, Drucker, IPC, serielle Schnittstellen, NFC, Web, Websockets, 
etc. bis hin zu so generischen Sachen wie Threads, Containerklassen, 
Strings, Signal/Slot, etc.

Wenn ein normales GUI-Framework ein Fahrrad ist dann ist Qt ein 
vollbeladener Schwerlasttransporter mit einer vollbestückten 
Fahrradhalterung am Heck die 12 Fahrräder enthält vom Klapprad bis zur 
Harley und zusätzlich noch einen Gabelstapler und einen faltbaren 12 
Tonnen Kran. Und einen fahrbereiten Porsche auf der Ladefläche. Und eine 
Wohnkabine mit Dusche und WC, 4m² Wasserbett und Satellitenfernsehen. 
Und Internet.

: Bearbeitet durch User
Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Wenn ein normales GUI-Framework ein Fahrrad ist dann ist Qt ein
> vollbeladener Schwerlasttransporter mit einer vollbestückten
> Fahrradhalterung am Heck die 12 Fahrräder enthält vom Klapprad bis zur
> Harley und zusätzlich noch einen Gabelstapler und einen faltbaren 12
> Tonnen Kran.

Wobei die ganzen Funktionen auf separate Bibliotheken verteilt sind, so 
dass man nicht alles in einem monolithischen Block hat. Man kann also 
vielleicht nicht das Fahrrad, aber zumindest die Harley auch einzeln 
fahren.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Viel interessanter ist der Punkt, dass man erstmal ein Vierteljahr
> warten muss, bis es losgeht.

Ist doch super zu lesen das der eigene Laden total kompetent und schnell 
ist. Das haette ich vorher im Leben nicht gedacht. :-D

Olaf

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olaf schrieb:
> Ist doch super zu lesen das der eigene Laden total kompetent und schnell
> ist. Das haette ich vorher im Leben nicht gedacht. :-D

Ich kenne das Projekt noch aus Zeiten, als Nokia es für Symbian 
verwendete. Da war Qt schon gut.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich kenne das Projekt noch....

Du hast weder meine Antwort noch die Fragestellung verstanden. Dafuer 
solltest du wirklich dankbar sein weil dein Gehirn noch nicht in einem 
Grosskonzern verdilbert wurde. .-)

Olaf

Autor: Wehret_den_Anfängen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine gutaussehende GUI die wie auf einem Android-Tablet aussieht ist 
aber nicht funktional.
Das macht den Controller kein bisschen besser.

Auch für die Bediener wird das dann immer mehr zur 
Selbstverständlichkeit, dass die Oberfläche wie bei dem neuesten Android 
aussieht und auch die selben Effekte hat.


Dabei wird nicht bedacht, dass bei einem Smartphone mehrere Cores nur 
für das Display zuständig sind und sehr viel der Batterieleistung 
absaugen.
Ich sehe diese Entwicklung zur Blink-Blink-GUI nicht nur positiv.


Eine Analog-Anzeige mit Tachonadel tut es auch.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Eine gutaussehende GUI die wie auf einem Android-Tablet aussieht ist
> aber nicht funktional.

Vor allem es gibt nicht DIE eine gute Gui. Das haengt auch sehr von der 
Anwendung ab. Wenn du z.B Geraete hast die draussen dauerhaft im Regen 
sind dann ist ein kapazitives Display unter Umstaenden nicht sinnvoll. 
Wenn es eine Anwendung im Ex-Bereich ist dann ist das Display hinter 
einer 5mm dicken Glasscheibe und laesst sich nicht per touch bedienen.
Man schaue sich auch mal an wie Kacke sich Windows (oder auch ein 
normales Linux) auf einem Tablett bedienen laesst weil das eben komplett 
auf Maus entwickelt wurde.

> Auch für die Bediener wird das dann immer mehr zur
> Selbstverständlichkeit, dass die Oberfläche wie bei dem neuesten Android
> aussieht und auch die selben Effekte hat.

HM..ich erwische mich einmal pro Woche dabei das ich den Mauszeiger vom 
PC auf den Oszi rueberschieben will. :-)

> Eine Analog-Anzeige mit Tachonadel tut es auch.

Manchmal, aber nicht wenn z.B die Gefahr besteht das sie festrostet und 
immer etwas falsche anzeigt. (SIL)

Der Embedded-Bereich ist deutlich komplexer als ein Handy!

Olaf

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olaf schrieb:
>> Viel interessanter ist der Punkt, dass man erstmal ein
>> Vierteljahr warten muss, bis es losgeht.
>
> Ist doch super zu lesen das der eigene Laden total kompetent
> und schnell ist. Das haette ich vorher im Leben nicht gedacht. :-D

Naja, verhält sich wie ein Großkonzern (verglichen mit Startup), 
Deutschland (verglichen mit Skandinavien) oder ein Güterschwerlastzug 
(verglichen mit S-Bahn).

Ewig passiert nix, aber wenn es dann endlich losläuft, dann hält das 
auch keiner mehr so schnell auf. Und ja, dann ists auch schnell und 
kompetent. :-D

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olaf schrieb:
>> Eine Analog-Anzeige mit Tachonadel tut es auch.
>
> Manchmal, aber nicht wenn z.B die Gefahr besteht das sie festrostet und
> immer etwas falsche anzeigt.

Gerade das ist aber auch bei Displays ein Thema (also nicht das rosten, 
sondern das falsch anzeigen). Die Software kann einfrieren und dann 
aufhören, das Display zu aktualisieren. Oder irgendein Link bricht ab, 
und das letzte Bild bleibt einfach stehen.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das lässt sich verhindern, indem man eine Animation und die aktuelle 
Uhrzeit anzeigt. Dann fällt es recht schnell auf (sollte zumindest).

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Das lässt sich verhindern, indem man eine Animation und die aktuelle
> Uhrzeit anzeigt. Dann fällt es recht schnell auf (sollte zumindest).

Kommt natürlich immer darauf an, wie kritisch ein Ausfall ist und wie 
leicht er für den jeweiligen Betrachter dann zu erkennen ist. Für den 
Tacho im Auto wäre das z.B. nicht ausreichend.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein ausgefallener Tacho im Auto fällt sehr schnell auf.
Im Gegensatz zu einem abgestürzten Navi...

: Bearbeitet durch User
Autor: Johnny B. (johnnyb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Qt ist ja auch deutlich mehr als nur GUI widgets. Das enthält Klassen
> für fast jedes Problem das einem über den Weg laufen könnte wie
> Netzwerk, Bluetooth, Gamepads und Joystick, Audio, Video, Streaming,
> Kamera, Drucker, IPC, serielle Schnittstellen, NFC, Web, Websockets,
> etc. bis hin zu so generischen Sachen wie Threads, Containerklassen,
> Strings, Signal/Slot, etc.

Rolf M. schrieb:
> Bernd K. schrieb:
>> Wenn ein normales GUI-Framework ein Fahrrad ist dann ist Qt ein
>> vollbeladener Schwerlasttransporter mit einer vollbestückten
>> Fahrradhalterung am Heck die 12 Fahrräder enthält vom Klapprad bis zur
>> Harley und zusätzlich noch einen Gabelstapler und einen faltbaren 12
>> Tonnen Kran.
>
> Wobei die ganzen Funktionen auf separate Bibliotheken verteilt sind

Ah schade, dann kann man wohl nicht einfach nur ein einziges Headerfile 
includen und alles läuft schon.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Johnny B. schrieb:
> Ah schade, dann kann man wohl nicht einfach nur ein einziges Headerfile
> includen und alles läuft schon.

Also auf dem PC ist das minimale Hello World Fenster mittlerweile auf 
satte zweistellige MB in gut einem guten Dutzend dlls angewachsen die 
man mindestens mitliefern oder dazulinken muss (vielleicht fliegt mehr 
davon raus wenn man statisch linkt, hab ich nicht probiert). Ganz früher 
waren das mal einstellige MB und nur 2 oder 3 dlls oder so.

: Bearbeitet durch User
Autor: Jens G. (jensg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Johnny B. schrieb:
> Ganz früher
> waren das mal einstellige MB und nur 2 oder 3 dlls oder so.
Na ja, ganz so dramatisch ist es nicht.

Bei meiner Anwendung sind es 5 dlls.
https://github.com/JensGrabner/Emulator_robotron_K1003/tree/master/Win32/Release

Aber eines ist ganz sicher. Das Zeugs will erlernt werden. .. und das 
ist nicht mal schnell. In meinem Fall brauchte es Unterstützung von 
einem erfahrenem Programierer.

Autor: Johnny B. (johnnyb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Johnny B. schrieb:
>> Ah schade, dann kann man wohl nicht einfach nur ein einziges Headerfile
>> includen und alles läuft schon.
>
> Also auf dem PC ist das minimale Hello World Fenster mittlerweile auf
> satte zweistellige MB in gut einem guten Dutzend dlls angewachsen die
> man mindestens mitliefern oder dazulinken muss (vielleicht fliegt mehr
> davon raus wenn man statisch linkt, hab ich nicht probiert). Ganz früher
> waren das mal einstellige MB und nur 2 oder 3 dlls oder so.

Na dann bin ich doch froh nutze ich auf dem PC Visual Studio und C#, da 
ist die erzeugte EXE für ein Hello World inkl. schönem Fenster mit 
WinForms wie früher nur ein paar wenige kB gross.
.NET ist ja jahrelang eh schon vorinstalliert, also lassen sich diese 
EXE's (Assemblys) einfach weitergeben und laufen problemlos auch auf 
anderen PC's.

Aber zurück zum Thema; hat jemand schon mal was gescheites mit ST 
TouchGFX gemacht? Das drängt sich ja förmlich auf, sofern man mit STM32 
arbeitet, weil es kostenlos ist und die YouTube Videos davon gut 
ausschauen.
Youtube-Video "ST TouchGFX Demo Video"

Autor: foobar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> .NET ist ja jahrelang eh schon vorinstalliert, also lassen sich diese
> EXE's (Assemblys) einfach weitergeben und laufen problemlos auch auf
> anderen PC's.

rofl

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Johnny B. schrieb:
> Na dann bin ich doch froh nutze ich auf dem PC Visual Studio und C#,

Ich nutze Lazarus für alle meine GUI-Tools.

Anekdote am Rande: Das hat sich jetzt ausgezahlt als wir einen ganzen 
Haufen Rechner auf denen kein Windows benötigt wird auf Ubuntu 
umgestellt haben: Mit dem andern Compiler kompiliert und es läuft 
problemlos (hier und da musste man noch ne Kleinigkeit zurechtbiegen 
aber nichts umbauen). Executables sind 5MB und haben NULL Abhängigkeiten 
außer libc und GTK.

Ist halt leider absolut Fenster-Maus-lastig (Win/Lin/OSX), auf 
Plattformen mit anderen Bedienkonzepten würd ich das nicht benutzen 
wollen.

: Bearbeitet durch User
Autor: Johannes S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johnny B. schrieb:
> Aber zurück zum Thema; hat jemand schon mal was gescheites mit ST
> TouchGFX gemacht?

Das Thema ist eigentlich Qt :)
Habe touchGFX mal vor längerer zeit ausprobiert, da war es noch 
eigenständig von Draupner Graphics. Die Programmierung mühselig in C++, 
jetzt ist es mit dem Designer schon einfacher Visualisierungen zu bauen. 
Wollte ich mal als Bedienpanel für Hausautomatisierung einsetzen, aber 
das ist schon recht aufwändig. Auf einer Hardware wie Disco F469 oder 
F769 sieht das sehr gut und flüssig aus, hat dann nach oben aber schon 
wieder Konkurrenz von sowas wie RPi wo man schon HTML nehmen könnte und 
ein komfortables OS mit WLAN/Ethernet hat.
Ist trotzdem recht cool, aufgegeben habe ich das noch nicht. Alternativ 
auch als luxuriöse Bedienung für einen Ofen oder irgendwelche Geräte. 
Nur haben die Disco Boards wenig Peripherie rausgeführt und für ein 
Einzelstück wäre mir das Design einer eigenen Platine mit so Boliden zu 
viel. Und touchGFX macht nur Sinn mit schneller Grafik weil da viele 
Pixel geschubbst werden.

: Bearbeitet durch User
Autor: Johnny B. (johnnyb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johannes S. schrieb:
> Das Thema ist eigentlich Qt :)

Ah ja stimmt, sorry.
Aber danke für deine Ausführungen zu TouchGFX.
Habe mir eben mal überlegt, das Display/Board von Glyn auszuprobieren:
https://www.glyn.de/Produkte/Displays/Smart-Embedded

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Johnny B. schrieb:
> Na dann bin ich doch froh nutze ich auf dem PC Visual Studio und C#, da
> ist die erzeugte EXE für ein Hello World inkl. schönem Fenster mit
> WinForms wie früher nur ein paar wenige kB gross.

Hmm, als ich das letzte mal solche "paar wenige kb großen" Programme 
bekommen hab, war immer genau die von diesem gebrauchte .NET-Version 
nicht installiert, und untereinander sind die alle nicht kompatibel. So 
musste ich für die paar Progrämmchen dann noch gigabyteweise 
.NET-Frameworks runterladen. Das ist dann nicht wikrlich besser.

> .NET ist ja jahrelang eh schon vorinstalliert, also lassen sich diese
> EXE's (Assemblys) einfach weitergeben und laufen problemlos auch auf
> anderen PC's.

So ähnlich geht's mir mit Qt unter Linux. Das ist dort in der Regel eh 
schon installiert.
Aber dass man, wenn man ein Qt-Programm unter Windows "deployen" will, 
oft DLLs dutzendweise braucht, kann ich bestätigen. Da ist das wirklich 
nicht mehr so einfach.

: Bearbeitet durch User
Autor: Max G. (l0wside) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was angenehm ist bei Qt (ich verwende es in mehreren Projekten): so gut 
wie alles, was man brauchen könnte, ist abstrahiert. Der gleiche Code, 
ganz ohne #ifdef, compiliert und läuft unter Linux und Windows.
Android geht mittlerweile wohl auch ganz gut, ich habe es aber nur mal 
in einer frühen Version getestet.

Ein denkbares Szenario wäre also, die Oberfläche eines Embedded-Systems 
komplett am PC zu entwickeln und dann das Ergebnis auf den STM32F7 zu 
portieren. Ob man die Steuerungslogik dann auf einen separaten µC 
auslagert, direkt auf RTEMS aufsetzt (was Qt als OS nutzt, siehe 
https://www.qt.io/blog/2018/05/03/qt-microncontrollers-mcu), in einen 
Qt-Thread packt oder komplett in QT mit signals und slots implementiert, 
wird man projektspezifisch entscheiden müssen.

Bei den erforderlichen Ressourcen (je rund 10 MB RAM und Flash) ist aber 
ein RPi Zero vielleicht auch keine so schlechte Wahl, wenn es denn Qt 
sein soll.

Autor: Christophz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olaf schrieb:
>> Auch für die Bediener wird das dann immer mehr zur
>> Selbstverständlichkeit, dass die Oberfläche wie bei dem neuesten Android
>> aussieht und auch die selben Effekte hat.
>
> HM..ich erwische mich einmal pro Woche dabei das ich den Mauszeiger vom
> PC auf den Oszi rueberschieben will. :-)

Falls dein Oszi so ein dickes ist, das zuerst Windows bootet, dann lässt 
sich dein vermisstes Verhalten mit Synergy nachrüsten:
https://github.com/symless/synergy-core

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Android geht mittlerweile wohl auch ganz gut, ich habe es aber nur mal
> in einer frühen Version getestet.

Problem bei Qt mit Android ist interessanterweise das Android-Geraete in 
der Regel Displays mit einer sehr viel hoeheren Aufloesung und/oder 
anderem Formfaktor haben als PCs. Und ich hab auch schon gesehen das 
Sachen in derselben Aufloesungen auf verschiedenen Android-Devices 
unterschiedlich grosse Fonts fuer die Buttonbeschriftungen verwendet 
haben.
Alles loesbare Probleme die aber immer etwas Nacharbeit verlangen.

Olaf

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olaf schrieb:
> Android-Geraete in der Regel Displays mit einer sehr viel hoeheren
> Aufloesung und/oder anderem Formfaktor haben als PCs

Ich mache das so, dass ich alle Abmessungen relativ zur Größe des 
Standard-Font mache. Das sieht auf jedem Gerät gut aus.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.