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
Klar habt ihr beide Recht, aber mit geht es ja hauptsächlich darum QT in windows zu nutzen. Ist man halt gewohnt...
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.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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.