Forum: Compiler & IDEs QT CROSS COMPILE


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.
von Host (Gast)


Lesenswert?

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

von g457 (Gast)


Lesenswert?

> 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

von Oliver S. (oliverso)


Lesenswert?


von Host (Gast)


Lesenswert?

Klar habt ihr beide Recht, aber mit geht es ja hauptsächlich darum QT in 
windows zu nutzen. Ist man halt gewohnt...

von olaf (Gast)


Lesenswert?

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

von Martin H. (horo)


Lesenswert?

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

von Warten (Gast)


Lesenswert?

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.

von Programmierer (Gast)


Lesenswert?

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.

von Warten (Gast)


Lesenswert?

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.

von Warten (Gast)


Lesenswert?

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.

von Programmierer (Gast)


Lesenswert?

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.

von Warten (Gast)


Lesenswert?

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.

von Frank K. (fchk)


Lesenswert?

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

von Host (Gast)


Lesenswert?

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.

von Εrnst B. (ernst)


Lesenswert?

Host schrieb:
> Ich such da einen
> Mittelweg.

WSL/WSL2 mal ausprobiert?

von Warten (Gast)


Lesenswert?

Ε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.

von Μαtthias W. (matthias) Benutzerseite


Lesenswert?

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

von olaf (Gast)


Lesenswert?

> 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

von Μαtthias W. (matthias) Benutzerseite


Lesenswert?

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

von Dirk (Gast)


Lesenswert?

>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.html
https://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.

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]
  • [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.