GUI Embedded

Wenn du schon so fragst, bleiben nur fertige Produkte wo Hardware, 
Software und Entwicklungsumgebung zusammen geliefert werden. Mir fällt 
da spontan der Raspberry Pi ein.

Arduino wollte ich nicht verwenden.
Erfahrungen mit C++ und C# sind vorhanden.

Es muss kein Betriebssystem sein alla Android oder Raspberian wo alles 
mögliche an Apps installiert werden kann. Es geht mehr um ein 
effizientes, schnell bootendes betriebssystem das kein Herunterfahren 
benötigt und jeder Zeit hart ausgeschalten werden kann.

Das Zielsystem sollte debuggbar sein.

Z.b. bietet Visual Studio zumindest für C # WPF oder Forms eine relativ 
gute Toolbox für GUI Applikationen für  PC Applikationen an.

Qt ist hier für C++ GUI Applikationen zu nennen.

Nun gibt es diverse Wege zum Ziel und ich will nicht 50% der n Wege 
gehen um festzustellen ein anderer Ansatz wäre besser gewesen.

Jeder gibt hier seine Sicht der Dinge wieder.
Es liegt dann an mir weiter zu recherchieren und das für mich passende 
Konzept zu wählen.

Was mir vorschwebt wäre folgendes....
GUI App Entwicklung mit Visual Studio C# mit Settings  Libs  .Net 
Framework, für die Zielhardware ... Raspberry Pi oder Beagle Bono oder 
... also Arm Cortex A.
Hier muss vermutlich das Win Iot core als Betriebssystem installiert 
sein. Das hat aber erschreckend lange Bootzeiten. > 30 Sekunden .... 
oder kann das selber verschlankt werden?

Alternativ auf eine Linux Distribution Mono installieren und dann läuft 
da scheinbar auch die C# GUI App.

Oder ist das mit C# alles nix auf Embedded Systemen und ich sollte mich 
auf Embedded Linux und QT konzentrieren.

Ich sehe somit einige Lösungswege .... überschaue sie aber noch nicht.

Die optisch schönste Variante ist für mich touchGFX, auf der 
Herstellerseite oder bei YouTube findest du einige Beispiele. Das 
braucht einen Cortex-M4 / -M7 und eine schnelle Grafik, dafür bekommt 
man eine GUI wie man sie vom Smartphone gewohnt ist. Demos laufen auf 
Evalboards von ST oder NXP oder auf dem PC als Simulation. Ist 
allerdings wie die meisten professionellen GUI Libs nicht konstenlos.

>Mir ist klar, dass die Frage sehr allgemein formuliert ist.
>Ich will mir erst einen Überblick über Möglichkeiten verschaffen.

Damit kannst du das Spektrum von
3 Status LEDs als GUI / 7-Segment Anzeige bis hin zu
HDMI Ausgang @1080p + Maus Bedienung abdecken.

Um Frust zu vermeiden definiere deine Anforderungen an die GUI
im Sinne von Auflösung, Farbtiefe, Aktualisierungsgeschwindigkeit usw,
die Möglichkeiten sind unendlich. Ebenso soltest du Lizenzzahlungen für 
bereits existierende Frameworks entweder akzeptieren oder ausschliessen.
Die Anforderung, deine bisherigen Programmierkenntnisse nicht erweitern 
zu müssen kannst du als nicht erfüllbar abhaken.
Visual Studio mit C# und embedded GUI beissen sich etwas wenn man eine 
gängige Lösung für embedded GUI sucht.

Gruß,
dasrotemopped.

Wenn ich also auf QT setzen würde,
Was benötige ich dann als Entwicklungsumgebung?

Zielhardware.... Raspbery Pi 3.
Welche Linux Distribution?
Entwicklungsumgebung auf PC wäre welche genau?

Wie sieht es mit dem debuggen aus?

Ein Link auf eine Seite, die das Gesamtpaket abhandelt wäre nicht 
verkehrt.
Verstreut auf x Seiten geht auch.

Werde mich dann noch zu genüge einlesen können.

Danke.

https://www.qt.io/download

http://doc.qt.io/qt-5/gettingstarted.html

Google kaputt ?

dasrotemopped.

https://wiki.qt.io/Native_Build_of_Qt5_on_a_Raspberry_Pi

Warum Cross Platform ?

dasrotemopped schrieb:
> Visual Studio mit C# und embedded GUI beissen sich etwas wenn man eine
> gängige Lösung für embedded GUI sucht.

Na ja .... früher vor 10 Jahren gab es PDAs, pocket PCs da lief Win 
mobil 5 drauf und da konnte man wunderbar mit C# und Visual Studio für 
Applikationen schreiben.
Das win mobile und smartphone Geschäft ist von Microsoft ja irgendwie 
gegen die Wand gefahren worden. Win iot core ist scheinbar der 
nachfolger von win mobile .... win ce.

GUI Anwendungen (rechenintensiv) und hardwareanwendungen (Reaktionszeit) 
sollten eh getrennt sein. GUI ist interaktion mit Menschen und da spielt 
das Geschehen im 100ms Bereich.

Verbindungen über USART oder I2C, SPI von GUI Plattform zu schnellen 
Microcontrollern die Signale ... Prozesse überwachen ist da imo 
zielführender.

Für GUI Applikationen jetzt ein power pc einzusetzen wäre da für mich 
doch etwas überzogen.

Die Plattform auf der die GUI läuft soll also nicht die 
eierlegendewollmilchsau sein sondern nur fürs GUI taugen....
und da suche ich eben was gescheites, das mir im privaten nutzt .... 
meinen beruflichen Horizont in richtiger Richtung erweitert.

@Miro

du hast ja jetzt doch ein winig an infos fallen lassen, ...

Ist das für privat / Gewrblich?
Um wieviele installationen geht es?

Was soll die embedded GUI können / was stellst du dir darunter vor?
Auflösung
Bedienung Touch resistiv  touch kapazitiv  Maus  tastatur  ohne

Auf welcher HW soll das hinterher laufen? -> Raspberry PI

Für embedded und private und raspberry Pi hätte ich noch was:
https://www.embedded-wizard.de/raspberry-pi.html
Gibts auch für den STM32 ;)

Bootzeiten ist boot2QT in der open source version enthalten?

Die Bootzeiten von Windows lassen sich auch verkürtzen. Im prinzip ein 
eingefrorenes System to disk in der das system immer aus genau diesem 
zustand aufwacht. Benötigt aber die passende Windows version (ebbedded 
Industrie glaube ich) und einiges an konfiguration (Sysprep 
lockdownmanager UniversalWriteFilter)

was mit STM32 und emWin möglich ist:
https://youtu.be/X_h-pNRZq0c

was mit STM32 und selbstgestrickter Firmware + CubeMX geht:
https://youtu.be/miGGfDeDFWU

>GUI Anwendungen (rechenintensiv) und
>hardwareanwendungen (Reaktionszeit) sollten eh getrennt sein.
Warum ? Ein STM32 kann beides gleichzeitig.

Mascha als riesiger Mauscursor und die ausgestreckte Hand ist der 
Pointer für die Tastenfelder  bei ca. 20fps, voller Redraw mit jedem 
neuen Frame, Also Reaktionszeit = 50ms

Soll aber nicht heissen, das Raspi + QT5 keine gute Lösung ist.
Ich finde nur die Behauptung, das ein ARM A Prozessor für einen GUI
zwingend nötig ist, etwas gewagt.

Gruß,
dasrotemopped.

Mir ist schon klar, dass mit quasi jedem Mikrocontroller mit 
entsprechender Performance Bilder auf ein Display mehr oder wenig 
flüssig zu "zaubern" sind.
Mir ist auch klar das es diesbezüglich ein Unterschied macht ob ich ein 
QVGA, VGA, HD, oder 4K Format füllen will.
Dafür gibt es dann aber auch ARMs M A von 48MHz bis >1GHz.


Es geht mir mehr um eine Toolbox.
Ein Werkzeugkasten der mich beim Zusammenklicken der GUI, mehr sollte es 
salopp gesagt nicht sein, unterstützt. Ich will überwiegend keine GUI 
Komponenten mühselig selber entwickeln.

Eine Toolbox, die mir Komponenten wie z.B. "Buttons", "ComboBox", 
"ScrollBars", "RadioButtons", "Charts" u.s.w. bereitstellt.

Denke oder ahne, das QT sowas ermöglicht.

Gegen VS C# Mono haben sich ja einige eher negativ geäußert.
Wobei man immer beachten muss, aus welchem Umfeld kommt eine Aussage und 
ist diese repräsentativ.
Ich will aber nicht auf biegen und brechen C# hier im privaten 
einsetzen, wenn das im Embedded Umfeld ein "toter Gaul" ist. Da hätte 
ich keinen Mehrwert davon.

Visual Studio C# ist eine Entwicklungsumgebung, die nicht viele Wünsche 
übrig lässt. Wie das bei der QT Umgebung aussieht weiß ich eben noch 
nicht.
Ich kann leider nur das beurteilen, was ich kenne und mit VS C# habe ich 
im GUI Bereich schon ein bisschen Erfahrung.

welche Visual Studio Version nutzt du denn ?
die Express oder eine kommerzielle ?
Bei QT stehst du ja auch vor der Wahl, eingeschränkt und kostenlos
oder uneingeschränkt und kostenpflichtig.
Habe bei VS und QT schnell gemerkt, das kostenlos keine gute Wahl ist.
Da ich aber keine kommerzielle Anwendung habe war mit das ganze kein 
Geld wert. Die STM32 Lösung dagegen kostet nichts und war zum Basteln 
ausreichend.

Gruß,

dasrotemopped.

Miro schrieb:
> Es geht mir mehr um eine Toolbox.
> Ein Werkzeugkasten der mich beim Zusammenklicken der GUI, mehr sollte es
> salopp gesagt nicht sein, unterstützt. Ich will überwiegend keine GUI
> Komponenten mühselig selber entwickeln.
>
> Eine Toolbox, die mir Komponenten wie z.B. "Buttons", "ComboBox",
> "ScrollBars", "RadioButtons", "Charts" u.s.w. bereitstellt.

Du möchtest was Fertiges, sagst aber nichts über die Ziel-Plattform. Was 
also erwartest du? Ich sag's mal so:

Typ A: Für gewöhnliche µC, wie sie hier üblich sind, ist bei einem TFT 
mit 800x480 Pixeln die Obergrenze erreicht. Solche Chips kann man noch 
selber verlöten und ohne vorgefertigtes OS betreiben. Sie haben zumeist 
ausreichenden ROM, aber nur begrenzt an RAM.

Typ B: Höher geht's nur mit dickeren µC, die man aber nicht mehr selbst 
auf seine Bastel-LP gesetzt kriegt, da heißen die Stichworte dann 
Armstone, Colibri, Raspberry und Konsorten. Sowas läuft dann komplett im 
RAM, von dem eigentlich reichlich vorhanden ist.

Typ A und B sind zwei ziemlich verschieden gelagerte Anwendungen, 
weswegen du mit Sicherheit keinen "Werkzeugkasten zum Zusammenklicken" 
für beides bekommen wirst. Sowas gibt's allenfalls für Typ B - und für 
Typ A mußt du dir was Eigenes einfallen lassen oder bei Firmen wie 
Segger einkaufen. Wenn dir dafür das Geld fehlt, dann bedenke, daß sowas 
IMMER etwas kostet: entweder Geld oder eigenen Entwicklerschweiß.

Ich hatte damals in der Lernbetty einen Rumpf für ein ROM-basiertes 
Menüsystem vorgestellt. Dieser Ansatz taugt auch für Farbgrafik, 
vorausgesetzt man hat keine solch lahmen Enten wie Displays mit eigenem 
Controller und seriellem Interface. Das wäre auch ein Ansatz für dich - 
wenn du dafür nicht zu faul wärest. Da muß nämlich noch ne Menge Arbeit 
hinein. Dafür kriegst du dann aber etwas, das eigentlich fast gar keine 
Bootzeit benötigt, weil alle Objekte bereits im ROM zur Benutzung fertig 
verlinkt sind.

Ein nächster Tip wäre das Entwicklerpaket zum Symbian-OS. Vormals Psion, 
später die Nokia-Phones. Compiler war Gcc. Dort werden vom OS C++ 
Objekte exportiert und das Ganze ist recht gut hierarchisch aufgebaut. 
Falls du das noch irgendwo herunterladen kannst, wäre ein Blick hinein 
durchaus nützlich. Aber eines muß dir auch hier klar sein: mit C++ und 
Objekten ist malloc und Konsorten angesagt und sowas braucht Bootzeit.

W.S.

Danke,

ich denke, ich werde mich auf QT konzentrieren.

Schau dir auch mal Lazarus an. Kompiliert auf Windows, Linux und anderen 
und eben auch auf Arm-Linux, d.h. Raspi etc. Von kleinen Details 
angesehen laeuft dann der gleiche Quellcode auf den unterschiedlichen 
Systemen, das macht die Entwicklung angenehm.