Hallo,
Ich habe mal eine Frage die sich jeder QT Anwender wahrscheinlich mal
gefragt hat. Ich möchte eine Anwendung für ein Embedded System
schreiben. Es spielt kaum eine Rolle welches genau, nehmen wir einfach
mal an für einen Rasberry.
Als Mausschubser würde ich gerne irgendwie ein folgendes System
aufbauen, wohlwissend das es kompliziert ist. Es geht also eher um
Machbarkeit die erfahrene Nutzer sicher beurteilen können.
Wunsch-System:
- QT auf Windows PC für vollständige Entwicklung der Applikation
- Linux in VMWARE mit yocto, sdk daraus, und Dinge die ich noch nicht
kenne
- Embedded System über Ethernet verbunden
- alles ein Rechner oder QT Rechner und Linux über Ethernet verbunden
Frage also: Kann man so cross so compilieren und letztlich "live" alles
rüberschieben wie mit der volgenden Umgebung? Welche Probleme erwarten
mich.
Meist vorgeschlagene Systeme:
Alles in der VMWARE einschließlich QT
> Frage also: Kann man so cross so compilieren und letztlich "live" alles> rüberschieben wie mit der volgenden Umgebung?
Ja, kann man. Erfahrungsgemäß wird es wesentlich vereinfacht, wenn man
auf dem Entwicklungssystem nativ entwickeln und debuggen kann, und erst
wenns da läuft compiliert man cross und schiebt das Ergebnis rüber.
Alternative ist cross-complieren und -debuggen, da ist die Hürde aber
gleich etwas höher. Geht aber auch gut wenn mans mal richtig
automatisiert hat.
Achja und man spart sich viel unnötigen Kinderkram wenn Entwicklungs-
und Zielbetriebssystem (sehr) ähnlich sind. Also z.B. Linux->Linux gut,
Winblöd->angefaulter Apfel schlecht, Linux->Winböld schlecht,
Winblöd->Winblöd gut. Die darunterliegende Hardware ist dagegen eher
zweitranging, da lernt man dann ordentlich zu typisieren und den
Sprachstandard zu befolgen ;-)
HTH
Sollte keine grosse Sachen sein. Du musst nur den Source von Qt
runterladen und einmal passend uebersetzen. War jedenfalls vor >10Jahren
als ich das fuer meinen Chumbi und meinen Zaurus unter Linux gemacht
habe keine grosse Sache.
Allerdings ist das einer der Momente wo du einen fetten 8-16core zu
Schaetzen weisst. QT ist megabig und brauchte damals deutlich ueber eine
1h fuer einen Build.
Olaf
Host schrieb:> geht es ja hauptsächlich darum QT in> windows zu nutzen
Bleib solange wie möglich bei Deinem vertrauten System und transferiere
erst wenn es funktioniert. QT ist problemlos Cross-Platform fähig.
Ich entwickle ein QT-basiertes PC-Projekt auf meinem Debian - bei mir
läuft ausschließlich Debian (und ein virtuelles FreeBSD zum Testen), mit
jedem Release auf GitHub laufen dort automatisch GH-Actions auf drei
virtuellen Maschinen (Ubuntu, MacOS und Windows), die sich den Quelltext
holen, CMake ausführen und dann per Make bauen, paketieren und die
Pakete nach GitHub kopieren.
Der größte Aufwand war, den Build für die beiden nicht vorhandenen
„Fremdsysteme“ (auch nicht virtuell) zu realisieren, dabei kam aber
Hilfe von Anwendern dieser Systeme.
Die restlichen Pakete (RasPi und FreeBSD) baue ich selber lokal.
Für Anregungen mal dort schauen:
https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners
OpenHantek:
https://github.com/OpenHantek/OpenHantek6022
die GH-Actions:
https://github.com/OpenHantek/OpenHantek6022/blob/main/.github/workflows/build_check.yml
Martin
Host schrieb:> Linux in VMWARE mit yocto, sdk daraus, und Dinge die ich noch nicht> kenne
Jesus, willst du dich gleich unermesslichen Schmerzen aussetzen oder
wieso machst du alles damit das ganze langsam und frickelig wird? Willst
20 Stunden dein Yocto kompilieren?
Mein Ratschlag: Egal was für ein Setup du aktuell hast oder was deine
dumme IT meint zu meinen:
Dicke Workstation kaufen. Hier nicht die Server CPU sondern die neueste
und dickste Intel/AMD Generation aus dem Desktop Bereich nehmen (sind
schneller und nicht Asbach Uralt). Das wäre der Intel 13900K oder Ryzen
7950X. Dazu 128GB RAM (dein Yocto wirst du gelegentlich in eine RAM Disk
legen) und dazu eine mindestens 2TB große sehr schnelle NVMe SSD (PCIe
4.0).
Kannst du dir von Bechtle/Mindfactory zusammenschrauben lassen.
Kostenpunkt so 2000-3000€. Die Firma zahlt dir im Monat locker das
dreifache, irgendwelche dummen Kostenstellen notfalls mit
Geschäftsführung übergehen. Eine Iteration in 30 Minuten vs 3 Stunden
kann kein Controller im Einkauf leugnen. Kernel in unter einer Minute
ebenfalls nicht.
Auf das System installierst du ein Ubuntu 22.04 LTS und schließt es an
eine ungefilterte Internetanbindung mit mindestens 1GBit an.
Damit kann man mit Yocto arbeiten, der VM Mist ist absoluter Blödsinn.
Dann kannst du auch qtcreator mit devtool sinnvoll nutzen.
Warten schrieb:> Dicke Workstation kaufen
Total unnötig. Man kompiliert ja nicht ständig das komplette Yocto neu,
sondern nur die eigene Anwendung.
Erstelle die Anwendung mit CMake und mach alles so Standard/0815 wie
möglich. Dann kannst du relativ einfach ein Recipe für Yocto erstellen
mit welchem du dann deine Anwendung für Yocto kompilieren kannst. Die
kannst du dann z.B. mit dem Yocto devtool die Anwendung direkt "live"
auf das laufende Target überspielen und dort ausführen. Das Yocto
Buildsystem kompiliert automatisch alle Abhängigkeiten, d.h. du musst
dich nicht damit rumschlagen die alle selbst zu bauen.
Ein bisschen Einarbeitungszeit für das Yocto Buildsystem musst du aber
schon mit einplanen.
Host schrieb:> Frage also: Kann man so cross so compilieren und letztlich "live" alles> rüberschieben wie mit der volgenden Umgebung?
Wenn du alles nativ unter einem unterstützten Linux durchführst geht das
problemlos mit devtool deploy und GDB. Gibt sogar eine offizielle
Erweiterung für Eclipse wenn man darauf steht.
Ich empfehle einen DHCP Server an einem zweiten Interface oder in
Kombination mit einem managed Switch und DHCP Option 82 damit dein
Target immer die gleiche IP bekommt. Hier natürlich nur Geräte mit CLI
kaufen, keinen Consumer Schrott, der kann das nicht.
Wenn du nur eine Anwendung entwickelst reicht dir devtool/gdb
wahrscheinlich aus. Sofern du am System selbst arbeitest solltest du
möglichst schnell einen NFS Server für das rootfs und tftp für den
Kernel/Device Tree einrichten.
Dazu eine fernsteuerbare Möglichkeit um einen Reset/Program Mode bei
deiner Hardware auszulösen und auch durchführen zu können.
Das machst du so früh wie möglich, spart einfach massiv Zeit nach einem
erfolgreichen Build des z.B. Bootloaders diesen direkt flashen zu
lassen. Brauchst du am Ende eh für CI.
Programmierer schrieb:> Total unnötig. Man kompiliert ja nicht ständig das komplette Yocto neu,> sondern nur die eigene Anwendung.
Wenn es wirklich so ist.
Ich glaube aber kaum, dass das gesamte Board Enablement bereits erledigt
ist und wenn man z.B. von init auf systemd wechselt wird doch einiges
neu kompiliert. Genauso bei anderen fundamentalen Änderungen am SDK. Ich
lese auch noch nichts von einem sstate Server/Paketspiegel, das Projekt
steckt wohl eher noch in den Kinderschuhen.
Zudem schadet es oft nicht einmal schnell alles neu zu kompilieren,
manchmal werden Änderungen nicht erkannt.
Die gesparte Zeit wird oft unterschätzt. Und auch wenn deine Anwendung
30s kompiliert braucht sie auf einem anständigen Rechner keine 10s. Das
läppert sich.
Warten schrieb:> Ich glaube aber kaum, dass das gesamte Board Enablement bereits erledigt> ist
Sinnvollerweise kauft man ein Board bei dem das alles schon erledigt
ist. Es klingt nicht so, als ob der TO da besondere Anforderungen hat.
Also z.B. ein Variscite Board nehmen, das vorgegebene Yocto System
laden, ein paar unnötige Pakete deaktivieren, die eigene Anwendung rein
setzen und fertig. Das hab ich auf einem Laptop gemacht, weil man nur
selten alles neu kompilieren muss. Das braucht keine fette Workstation.
Warten schrieb:> Hier natürlich nur Geräte mit CLI kaufen, keinen Consumer Schrott, der> kann das nicht.
Jeder Plastik-DSL-Router kann das, und braucht da keine CLI für sondern
ein webbasiertes Setup.
Programmierer schrieb:> Sinnvollerweise kauft man ein Board bei dem das alles schon erledigt> ist. Es klingt nicht so, als ob der TO da besondere Anforderungen hat.
Wenn es eine 0815 Linux Anwendung ist kann er diese aber auch ganz ohne
Yocto erstellen. Dazu muss er auch nicht Cross Compilen.
Programmierer schrieb:> Warten schrieb:>> Hier natürlich nur Geräte mit CLI kaufen, keinen Consumer Schrott, der>> kann das nicht.>> Jeder Plastik-DSL-Router kann das, und braucht da keine CLI für sondern> ein webbasiertes Setup.
Jeder Plastikrouter kann das wenn man genau ein einziges Sample besitzt
und daher immer die gleiche MAC hat. Richtige Switches mit
entsprechenden DHCP Optionen sind notwendig sobald man mehrere Samples
hat.
Host schrieb:> Klar habt ihr beide Recht, aber mit geht es ja hauptsächlich darum QT in> windows zu nutzen. Ist man halt gewohnt...
Der QT Designer läuft unter Linux genauso wie unter Windows. Da gewinnst
Du nichts und verlierst nichts. Du hast dann eben keine Probleme mehr
mit verschiedenen Plattformen etc.
Was auch geht: Jetson Nano oder Xavier NX als Entwicklungsplattform
nehmen, am besten mit extra NVMe-SSD. Da läuft dann Deine Entwicklung
drauf. Je nachdem, was Deine Zielplattform ist, kann das recht bequem
sein, weil Du dann nativ auf der jeweiligen Architektur (aarch64 oder
armhf) entwickelst und Linux-Binaries innerhalb einer Architektur
binärkompatibel sind. (die passenden Libraries mal vorausgesetzt) Heißt
also: Du kannst Deine Binaries auf einem Desktop-System entwickeln und
dann 1:1 auf das Zielsystem rüberkopieren, und es sollte dann einfach so
laufen.
fchk
Ich habe einen Threatripper 1950. Die haben 16 Kerne und 32 Threads. Das
sieht schon ganz toll aus wenn der 30 zu compilieren benutzt. Wenn dann
aber die großen Files kommen zählt wie immer die Single Kern Leistung.
Aber Geschwindigkeit meines 4 Jahre alten Rechners ist nicht so das
Problem. Wie richtig gesagt wurde ist es später eher Kleinkram der
nachcompiliert wird.
Embedded ist ja wesendlich weniger als ein PC System. Zumindest bei mir.
Mein Problem ist eher quasi ganz auf Linux umzustellen, ohne notwendige
Windows Tagesgeschäfte gleichzeitig nutzen zu können. Ich such da einen
Mittelweg.
Im Moment tendiere ich da auch zu zwei Rechnern. Man kann sich nicht
darauf verlassen das alles was am auf dem PC funktioniert nachher auch
auf dem embedded Rechner geht. Daher wäre ein schnellstmögliches
debuggen auf dem Zielsystem schon toll.
Ich werde die Tipps und Links mal in Ruhe anschauen, Danke.
Εrnst B. schrieb:> WSL/WSL2 mal ausprobiert?
Ist nicht Yocto validiert. Kann, muss aber nicht funktionieren. Will man
GUI braucht man das aktuellste Windows Update von vor ein paar Wochen
bei Windows 10, würde mich verwundern, wenn das irgendeine Firma bereits
ausgerollt hat.
Ich rate zu zwei Rechnern. Der Windows Rechner ist dann meist ein Laptop
nachdem man für Mails usw. kaum Leistung benötigt. Die Linux Workstation
hast du in einem getrennten Netz mit freiem Internetzugang und
ausschließlich Zugang zum Git Server und der Build Infrastruktur. Mit
viel Glück bekommst du von der IT zusätzlich noch einen Linux Ryzen
Laptop...
Wenn deine IT ganz weit in der Cloud ist kannst du mit Glück auch den
Windows Laptop abschaffen, gibt von Microsoft einen Web Client für
Mails. Verschlüsselte Mails sind meistens noch problematisch, hat man
aber nicht immer. Selbst Teams bekommst du sogar für Linux:
https://www.heise.de/news/Microsoft-Teams-Linux-Client-weicht-Progressive-Web-App-7333515.html
Du kannst auch problemlos mit deinem Windows Laptop auf der Workstation
arbeiten, einerseits natürlich SSH und dann natürlich z.B. vscode mit
der Remote Erweiterung über SSH.
Machen wir hier so ähnlich. Am Arbeitsplatz einen Windowsrechner für
Mail, Office, ERP und evtl. bisschen CAD. Alles was Softwareentwicklung
angeht läuft auf einem 32 Core Threadripper mit 128GB RAM im
Druckerraum. IT wollte nur zertifizierte Hardware im Serverraum haben.
Kosten für den angebotenen Epyc Server Faktor 3 zum Threadrippersystem
bei gleicher Leistung. Sogar ein Windows only Compiler (für MB90Fxxx und
MB96Fxxx) läuft per Wine auf der Kiste (und sogar schneller wie auf dem
Arbeitsplatzrechner). Dank Linux lässt uns die IT auch mit ihrem
Schlangenöl^W Virenscanner in Ruhe.
Matthias
> Alles was Softwareentwicklung angeht läuft auf einem 32 Core> Threadripper mit 128GB RAM im Druckerraum.
Wie funktioniert das dann mit der ganzen Hardware die du lokal
anschliessen musst? Also sagen wir mal J-Link, Oszi, Analyzer,
spezielle Debugger, RS485, 4-20mA Umsetzer, usw....
Olaf
olaf schrieb:>> Alles was Softwareentwicklung angeht läuft auf einem 32 Core>> Threadripper mit 128GB RAM im Druckerraum.>> Wie funktioniert das dann mit der ganzen Hardware die du lokal> anschliessen musst? Also sagen wir mal J-Link, Oszi, Analyzer,> spezielle Debugger, RS485, 4-20mA Umsetzer, usw....
J-Link -> J-Link Remote Server
Oszi -> Steht am Arbeitsplatz
Analyzer -> Steht im Schrank (brauch ich extrem selten, Oszi reicht)
Speziellen Debugger -> Das olle Fujitsu-Ding hab ich seit Jahren nicht
mehr in Betrieb. Rest siehe J-Link
RS485 -> hängt am Windows-PC und wird per kleinem Programm auf tcpip
weitergeleitet
CAN -> dito. PCAN-USB per Tool weiter an Linuxrechner auf Socket CAN
Matthias
>Wunsch-System:>- QT auf Windows PC für vollständige Entwicklung der Applikation>- Linux in VMWARE mit yocto, sdk daraus, und Dinge die ich noch nicht>kenne>- Embedded System über Ethernet verbunden>- alles ein Rechner oder QT Rechner und Linux über Ethernet verbunden
Hab das Thema jetzt hinter mir und hier meine Erfahrung.
1. VM + Yocto image erstellen ist grausam, weil man nicht alle
Cores/Threads und Speicher für das Gastsystem nehmen kann, deshalb
empfehle ich Dir einfach eine zweite Platte mit Linux
2. In dem Linux einen Dockercontainer erstellen und alle
Yoctoabhängigkeiten hineininstallieren.
3. Yocto SDK kann in ein anderen Dockercontainer installiert werden.
Die Seiten haben mir geholfen das Boot2Qt zum laufen zu kriegen und die
Yoctocontainer einzurichten.
https://raymii.org/s/tutorials/Yocto_boot2qt_for_the_Seeed_reTerminal_qt6.htmlhttps://embeddeduse.com/2020/05/26/qt-embedded-systems-1-build-linux-image-with-yocto/
Auf einem Windowsbetriebssystem will ich keine Embeddedentwicklung mehr
tätigen, auch wenn es in einer VM laufen sollte. Es ist soviel
angenehmer auf Linux mit Dockercontainer, insbesondere wenn man mal ein
Fehler nicht behebbaren Fehler reinzaubert. In dem Fall ist auch ein
Dockercontainer besser und du komplierst das Yoctoimage um einiges
schneller.
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
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten