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.
> 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 ...
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
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.
> 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
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?
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.
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):
1
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
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?
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.
@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, ...
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.
@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?
> 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
unwissender schrieb:> QT> - µC / CPU Kombination (z.b. STM32MP1...) mit (embedded) Linux, z.b.> Phyton oder auch QT
"Python Tkinter" ist auch eine Alternative.
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.
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
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.
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?
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.
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.
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.
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.
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.
> 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
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?
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.
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.
> Stefanus F. schrieb:> Versuche mal ein Programm zu verkaufen, dass wie Windows 95 aussiehtBernd 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.
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.
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
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.
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/TivoisierungHans 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.
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.
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?
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
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."
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)
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.
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.
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. :-(
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.
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.
> 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
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.
> 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
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.
> 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
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
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.
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.
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.
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.
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.
https://youtu.be/kXfMrvpdp9M
> .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
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.
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.
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.
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.
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
> 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
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.
Hallo, von der Internetseite werde ich nicht ganz schlau. Benötige ich
ein Betriebssystem wie Linux o. arbeitet es auch mit FreeRTOS?
Macht Qt auch die HW Abstraktion zur CPU und ich kann mit Qt die I/O
Ports oder das CAN Interface mit Qt Serialbus benutzen? Ist eine GUI
Applikation zwingend notwendig oder geht es auch Headless?
Dirk schrieb:> Ist eine GUI Applikation zwingend notwendig oder> geht es auch Headless?
Ich sehe keinen Sinn in einem Grafiktoolkit ohne Bildschirm.
Qt an sich kann auch ohne GUI verwendet werden. Man ersetzt dann
QApplication durch QCoreApplication.
> Macht Qt auch die HW Abstraktion zur CPU
Das ist Aufgabe des C++ Compilers
> ich kann mit Qt die I/O Ports oder das CAN Interface> mit Qt Serialbus benutzen?
Nur, wenn die Qt Bibliothek diese I/O Hardware unterstützt.
Du musst erstmal eine Qt Version für deine Hardware finden.
Stefan ⛄ F. schrieb:> Du musst erstmal eine Qt Version für deine Hardware finden.
Einfacher ist es anders herum. .. und wer QT ohne Display verwenden
möchte, wird QT ohnehin nicht benötigen.
Rolf M. schrieb:> 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.
Ja in diesem Falle hast Du natürlich recht.
Derjenige welcher so ein Progrämmchen macht muss im Visual Studio
natürlich schon ein .NET Framework definieren, welches auch
weitverbreitet ist und nicht einfach das neuste.
>Ich sehe keinen Sinn in einem Grafiktoolkit ohne Bildschirm.
Qt ist nicht nur GUI Grafikframework, sondern die Frage zielte in die
Richtung die erstellten Services auf einem ST mit minimaler Anpassung
oder gar keine Anpassung wiederzuverwenden.
> Was für ein Zufall. Wurde heute bei Youtube hochgeladen
Ohje...mit DIESER Tonqualitaet hinterlaesst die Firma aber nicht mal im
Ansatz einen kompetenten Eindruck. Das will man sich nicht antun....
Olaf
Olaf schrieb:>> Was für ein Zufall. Wurde heute bei Youtube hochgeladen>> Ohje...mit DIESER Tonqualitaet hinterlaesst die Firma aber nicht mal im> Ansatz einen kompetenten Eindruck. Das will man sich nicht antun....
Das ist ja kein professionell erstelltes Studio-Video, sondern der
Mitschnitt eines Webinars. Der Ton wird aus einem Laptop-Mikrofon
kommen und noch durch eine Vidokonferenz-Software gelaufen sein. Und
dafür ist die Verständlichkeit eigentlich recht gut. Ich bin da von
Konferenzen deutlich schlimmeres gewöhnt.
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten