Hallo, auf einem raspberry pi zero w möchte ich C/C++ Code entwickeln. Welche IDE würdet ihr mir empfehlen?
Ich würde empfehlen, keine IDE auf dem Zero zu installieren. Besser ist es, einen Cross Compiler zu nutzen. Dadurch kannst du deinen leistungsstarken Rechner zum entwickeln nutzen und musst nicht Stunden auf den Zero warten bis der dein Programm übersetzt hat. In meinem Studium habe ich Eclipse und einen Cross Compiler genutzt und kann es nur empfehlen.
Maulwurfmann schrieb: > In meinem Studium habe ich Eclipse und einen Cross Compiler genutzt und > kann es nur empfehlen. Ja, so habe ich es seither auch gehandhabt. Auf dem PC übersetzen, Eclipse überträgt das dann im Hintergrund und startet den GDB. So lässt sich auch gut debuggen. Die IDE ist da aber nur das Tüpfelchen auf dem i. Du kannst auch mit einem selbst geschriebenen make übersetzen, es per FTP o.ä. übertragen und per PuTTY den GDB händisch starten.
rpi schrieb: > auf einem raspberry pi zero w möchte ich C/C++ Code entwickeln Ich nehme mal an, es muss Linux sein, ein anderes OS, das auf dem Pi Zero schnell rennt, ist keine Option? Pi Imager : RISC OS Ansonsten, warum nicht auf Pi 4 entwickeln, und dann auf Pi Zero schieben?
Hallo, ok ich würde dann den Weg mit Eclipse und dem Cross-Compiler einschlagen. Dazu würde ich gerne wissen welche Eclipse Version (IDE C/C++) und welche Cross-Compiler Version? Wie richtet man dann den Zugang zum Raspberry Pi ein?
So ich habe nun mal die neue IDE von Eclipse installiert und auch noch
die GNU Arm cross compiler toolchain. Das erste Testprogramm in C kann
ich nun auch erfolgreich übersetzen und linken. Herauskommt ein binary.
Dieses möchte ich auch auf dem raspberry pi testen. Allerdings kommt die
Meldung
>-bash: ./Test: Keine Berechtigung
Wie kann ich das binary auf meinem Target zu Laufen bringen?
Für alle, die das noch nicht wissen: den QtCreator kann man auch für nicht-Qt Projekte nehmen. Mit Eclipse konnte ich mich noch nie im Leben anfreunden.
rpi schrieb: > Allerdings kommt die Meldung >> -bash: ./Test: Keine Berechtigung Wie hast du denn das Binary übertragen? Hast du es nach der Übertragung auch ausführbar gemacht? BobbyX schrieb: > Mit Eclipse konnte ich mich noch nie im Leben anfreunden. Muss ich mir auch Mal anschauen. Aber letzten Endes ist das wir immer Geschmackssache. Ich arbeite mit Eclipse auch auf der Arbeit... Und wenn man sein Werkzeug kennt findet man sich damit halt am schnellsten zurecht.
rpi schrieb: > auf einem raspberry pi zero w möchte ich C/C++ Code entwickeln. Welche > IDE würdet ihr mir empfehlen? Wenn Du direkt(!) auf dem Zero entwickeln willst, würde ich gar keine IDE nehmen, sondern zwei SSH-Sitzungen aufmachen, auf der einen einen Editor (nano, vi,...) direkt auf dem Zero laufen lassen und damit den Code editieren und auf der zweiten SSH eine Console fürs Compilieren und Testen der Anwendung.
So bin nun etwas weitergekommen. Jetzt scheitert es am Debugging.
Angehängte Dateien:
Findes die Ursache nicht, warum das debugging auf dem Target nicht läuft
Es steht was von Speicherzugrifffehler. Kann es sein das auf dem raspberry pi noch Zugriffsrechte benötige?
Ich weiß es leider auch nicht, bin aber an dem Ergebnis interessiert, da ich gerade dasselbe versuche. Mein erfolgloser Ansatz ging über Visual Studio Code, das auch so eine Remote-Verbindung bietet. Es lief einfach nicht. Bis ich auf GitHub (https://github.com/microsoft/vscode-remote-release/issues/669) die Info von Microsoft las, dass ARM zwar unterstützt wird, aber nicht das reduzierte Instruction Set vom Pi Zero -> keine Chance. Könnte es hier ein ähnliches Problem sein? Ich kenne die Eclipse ARM Toolchain nicht. Aber wenn Du auf Rasperry-Seite nicht selbst compiliert hast, sondern Binaries installiert, dann könnte es dasselbe Problem mit dem nicht unterstützten Instruction Set sein. Ich richte gerade Samba ein und plane mit Visual Studio Code oder Atom zu entwickeln. Das bietet immerhin einen guten Editor mit Syntax-Highlighting und ist besser als Emacs oder Nano im Terminal. Gruß, Felix
Hi ja da beschäftigt man sich Tage und Wochen damit. Ich habe schon einige Wege eingeschlagen. Keiner weiss genau wie und was gemacht werden muss damit das per remote funktioniert. Am besten man kauft sich eine komplette Entwicklungsumgebung mit Debugger.
Der eine sagt du must netbenas oder rust oder eclipse verwenden.
Beitrag #6555111 wurde von einem Moderator gelöscht.
rpi schrieb: >>-bash: ./Test: Keine Berechtigung > Wie kann ich das binary auf meinem Target zu Laufen bringen? Ich vermute mal Du hast 64-Bit ARM cross-compiliert und auf dem Pi Zero ist natürlich ein 32-Bit ARM Linux ...
Lothar schrieb: > 64-Bit ARM cross-compiliert und auf dem Pi Zero > ist natürlich ein 32-Bit ARM Linux Stimmt, das geht natürlich nicht. Gleiches Problem ergäbe sich auch beim Cross-Compilieren auf dem Raspberry 4. Es wäre interessant zu wissen, ob das Hello-World-Beispiel oben ohne den Debugger funktioniert hat. Aber beim Debugger gilt dasselbe wie für Visual Studio Code: Es muss ein Gegenstück auf dem Pi installiert sein. Wenn das nur als falsch compiliertes Binary verfügbar ist, läuft es nicht auf dem Zero.
Auf dem raspberry pi habe ich natürlich das binary zu Laufen gebracht. -> Test.elf -> gestartet mit ./Test.elf
Also Laufen tut das Programm wenn man es manuell startet. Wie kann ich auf dem raspberry pi und windows prüfen ob es 32Bit ist oder 64Bit?
Was spricht, eine Entwickungsumgebung und Compiler auf dem Raspi zu haben. Ich habe eben mal installiert: apt-get install cmake apt-get install kdevelop Dann konnte ich kdevelop öffnen. ein Projekt erstellen, die Source compilieren und anstarten. Alles ging remote eingeloggt mit ssh -X user@raspi Eine Sache von nicht mal 10 Minuten.
Hi, hast einen Weg geschildert, wo man direkt auf dem raspberry pi entwickelt. Ich möchte ja eine Lösung haben wo ich remote via Wiondows auf den raspberry pi zugreifen und debuggen kann.
Der zero ist schon langsam wenn man mit der grafischen Oberfläche entwickeln möchte.
rpi schrieb: > Auf dem raspberry pi habe ich natürlich das binary zu Laufen gebracht. Das ist doch schon mal ein guter Schritt, das ist schon mal komfortabler als mein Ansatz mit Samba. Ich glaube nicht, dass 32/64 Bit der Punkt sind, sondern das Instruction Set der alten ARM-Prozessoren. Armv7 ist auch 32 bit und wird wohl von Visual Studio Code unterstützt, da es schon ein neueres instruction set hat. Aber wie schon gesagt, ich weiß nicht, ob dieses Problem hier analog auch vorliegt. Wie hast Du den Raspberry-Teil der Toolchain zum Cross-Debuggen auf dem Raspberry installiert? Binaries oder Code, den Du selbst compiliert hast? Binaries wären ein Indikator, dass das das Problem sein könnte. Ansonsten ein paar Gedanken: Ist das Debuggen denn so wichtig? Wären Loggen in ein Error-File oder auf die serielle Schnittstelle eine Alternative? Wie wirst Du jenseits von Hello-World vorgehen, z.B. wenn Du die WiringPi Library installieren willst. Unterstützt der Crosscompiler sowas? Oder Du nimmst einen Raspberry 3/4 als Entwicklungsgerät und greifst wie von PittyJ vorgeschlagen bei RemoteDesktop drauf zu. Nach Beendigung der Entwicklung compilierst Du auf dem Zero halt nochmal neu. Gruß, Felix
>Wie hast Du den Raspberry-Teil der Toolchain zum >Cross-Debuggen auf dem Raspberry installiert? Binaries oder Code, den Du >selbst compiliert hast? Binaries wären ein Indikator, dass das das >Problem sein könnte. Verstehe nicht ganz was du damit meinst. Also der Code wird mit Eclipse erstellt und kompiliert und gelinkt mit der arm gnu toolchain (https://gnutoolchains.com/raspberry/).
>Binaries wären ein Indikator, dass das das >Problem sein könnte. Was meinst du genau damit?
So ich hab es nun herausgefunden woran es lang. Beim konfigurieren des Debuggers habe ich die falsche exe von gdb eingefügt. Der Code lässt sich nun debuggen.
Sogar die Funktionalität von #include <wiringPi.h> habe ich getestet. Funktioniert soweit auch. Allerdings gibt es doch noch so ein kleines Problem. Der Eclipse Editor findet die stdio.h und die wiringPi.h nicht. Es wird alles übersetzt nur ich kann die Deklaration und Implementierung nicht sehen.
rpi schrieb: > Was meinst du genau damit? Um remote debuggen zu können, brauchst Du auf dem Raspberry ein Gegenstück, das mit Eclipse kommuniziert, d.h. einen remotefähigen Debugger. Dieser muss auf dem Raspberry installiert werden. So ist es jedenfalls bei Visual Studio Code und dieses "Gegenstück" auf dem Raspberry verursacht hier den Fehler. Sehe jetzt allerdings an Deinem Screenshot, dass Du gdbserver verwendest. Ist wahrscheinlich bereits installiert in Raspbian und damit nicht von diesem Problem betroffen.
Auf dem raspberry pi habe ich den gdbserver installiert mit
>sudo apt-get install gdbserver
Kann mir jemand noch sagen wie ich auf die ganzen Headerdateien auf Windows Eclipse von raspberry pi zugreifen kann?
rpi schrieb: > Auf dem raspberry pi habe ich den gdbserver installiert mit Kannst Du bitte mal kurz zusammenfassen, was Du genau installiert hast und wie Du es in Eclipse bzw. mit dem Raspberry integriert hast? Oder vielleicht einfach nur die jeweiligen Links. Es gibt so viele Varianten von Prebuilds und per Hand zusammengebauten Einzelteilen...
Folgende Tools habe ich heruntergeladen: 1. https://www.eclipse.org/downloads/ 2. https://gnutoolchains.com/raspberry/ 3. http://gnuwin32.sourceforge.net/packages/make.htm 4. Auf dem raspberry pi zero w habe ich dann noch den gdbserver installiert: sudo apt-get install gdbserver
Folgende Videobeiträge haben mir geholfen das ganze einzurichten: https://www.youtube.com/watch?v=5VZRsfoVxbQ https://www.youtube.com/watch?v=Al6OZ2kF_qA
Nun habe ich noch einen Punkt. Wie kann ich nun von Windows aus mit Eclipse auf den Quellcode und Headerdateien vom raspberry pi zugreifen? Weiss nicht wie ich das einrichten kann.
rpi schrieb: > Wie kann ich nun von Windows aus mit > Eclipse auf den Quellcode und Headerdateien vom raspberry pi zugreifen? > Weiss nicht wie ich das einrichten kann. Auf der von Dir verlinkten Seite gnutoolchains.com ist auch ein Tutorial zum Synchen vom sysroot Verzeichnis: https://gnutoolchains.com/raspberry/tutorial/sysroot Hast Du das schon probiert?
Hi Felix,
super Danke!
Und wo finde ich
>Run <toolchain>\tools\UpdateSysroot.bat
Ich kann das Tool UpdateSysroot.bat auf meinem Rechner nicht finden
rpi schrieb: > Ich kann das Tool UpdateSysroot.bat auf meinem Rechner nicht finden Tja, ist wohl weg. Einmal im Forum des Herstellers gegoogelt, da suchen viele nach. Bei einem Thread stand die offizielle Antwort "Please use the VisualGDB Project Properties to synchronize the toolchain sysroot". Das ist das Produkt, das die Firma verkauft... Ab 100 Euro bist Du dabei. Ansonsten halt manuell synchen, z.B. nach C:\SysGCC\raspberry\arm-linux-gnueabihf\sysroot\usr\include Das war das, was ich mit "was machst Du nach Hello Welt" meinte. Google zeigt Dir da viele Fragen und viele Antworten. Sysprogs ist ja nicht der einzige Anbieter von toolchains. Kann Dir da nicht helfen, bin selber noch in der Evaluationsphase. Bei Visual Studio Code lief es bei mir ähnlich. 2 Tage installiert und ausprobiert. Am Ende dann die Erkenntnis, dass ausgerechnet der Raspberry Zero nicht läuft. Alles für die Tonne...
rpi schrieb: > Ich kann das Tool UpdateSysroot.bat auf meinem Rechner nicht finden Inhalt von C:\SysGCC\raspberry\TOOLS\UpdateSysroot.bat:
1 | PortableSmartty\SmarTTY.exe /UpdateSysroot:..\arm-linux-gnueabihf\sysroot |
via https://gnutoolchains.com/raspberry/ raspberry-gcc6.3.0-r4.exe (534 MB) Haben die im (gnutoolchains)Forum Tomaten auf den Augen?:) Als Inspiration: - Hier cross-compiled einer das komplette QT -> https://palombo.org.uk/qt-on-rpi/ - sysroot updaten -> https://gnutoolchains.com/raspberry/tutorial/sysroot - Jeff Geerling baut komplette Kernels remote: https://www.jeffgeerling.com/blog/2020/cross-compiling-raspberry-pi-os-linux-kernel-on-macos Vielleicht mal an eine Virtuelle Maschine mit Linux denken. Da gibt es viel Neues zu entdecken und zu lernen:) Siehe https://wiki.gentoo.org/wiki/Raspberry_Pi/Cross_building Das ist dann so easy wie "armv6j-unknown-linux-gnueabihf-emerge mein-paket". (Ich unterschlage natürlich den Weg dahin:P)
:
Bearbeitet durch User
Jedzia D. schrieb: > Haben die im (gnutoolchains)Forum Tomaten auf den Augen?:) Das ist ein toller Tipp, vielen Dank. Die anderen Links sind auch interessant, da werde ich mich mal inspirieren lassen. Aber Tomaten auf den Augen trifft es nicht so ganz, die Firma hat das wohl schon bewusst ausgebaut: https://sysprogs.com/w/forums/topic/cross-compiling-opencv-with-advanced-cmake-for-raspberry-pi/ Einige andere Downloads hatte ich probiert und es nicht gefunden, das hier ist wahrscheinlich das letzte. My precious...
So, ich habe mich mal durchgequält, alles installiert und ein kleines Beispiel mit WiringPi aufgebaut, compiliert und remote debugged. Mein Fazit ist durchwachsen. Positiv ist auf jeden Fall, dass ich jetzt eine echte IDE mit Syntax-Check und Highlighting, Code-Completion und Remote-Debugger habe. Die Installation auf dem Target kann dabei sehr klein bleiben, es braucht keine Entwicklungsumgebung, kein X-Window, noch nicht mal ein Betriebssystem. Es ist kein großer Speicher oder Rechenleistung auf dem Target nötig. Negativ: 1. Der Weg dahin war sehr lang und steinig. Recherche, Installation und Ausprobieren haben viele Stunden gedauert. Anlegen eines Testprogramms und Makefiles per nano in der Konsole hat nur 10 Minuten gedauert. 2. Das Ganze ist extrem speicherhungrig. Eclipse braucht 600MB, die Toolchain 5.5 GB. Davon sind 5 GB das rootsys. Verwunderlich, da mein Installationsfile für den Raspberry viel kleiner War... Das Kompilat ist 100kB groß im Gegensatz zu 10kB in der Konsole per Hand. Wahrscheinlich aber eine falsche Einstellung. 3. Seine Toolchain redundant zu halten ist ein immenser Aufwand. Für jedes Gerät ist die richtige Kombinatorik von Tool- und Library-Releases vorzuhalten. Nach jeder Installation/Update rootsys anzupassen. 4. Die Bedienung ist durch die vielen kombinierten Tools extrem komplex. Jede Anleitung ist veraltet, weil sich jede Installation durch diese Kombinatorik leicht unterschiedlich verhält. 5. Bei Kleinprojekten ist die Compilierung eher langsamer, da der Overhead von Toolchain, den 5GB sysroot und Remote-Übertragung recht groß ist, Mein Fazit: Für professionelle Entwicklung von Großprojekten "bare-bone" auf ARM wird das wohl der richtige Weg sein. Für Privatprojekte auf Raspberrys mit Linux kann ich es nicht wirklich empfehlen. Ich werde es nur aus Spieltrieb weiter verfolgen bzw. weil noch einiges mit ESP32 und ATmega machen will und von der Arduino-IDE genervt bin. Ich würde empfehlen, was oben schon vorgeschlagen wurde: 1. 2 Terminal Lösung mit Nano/Emacs und lokalem Debugger gdb 2. Samba auf dem Pi und auf dem PC Atom, Visual Studio Code etc. Damit hat man schonmal Syntax-Highlighting und Formatierung. 3. Ab Raspberry Pi 3 Arbeit über remote Desktop mit schlanker IDE wie kdevelop auf dem PI. Oder virtuell mit QEMU. 4. Visual Studio Code über SSH ist ein cooles Verfahren, funktioniert nur leider nicht auf dem Raspberry Zero (https://code.visualstudio.com/docs/remote/ssh) 5. Vielversprechend klingt auch Netbeans (z.B. https://raspberry-projects.com/pi/programming-in-c/compilers-and-ides/netbeans-windows/installing-netbeans-for-c-remote-development-on-a-raspberry-pi). All diese Verfahren haben zudem den Vorteil, dass man nicht auf die Programmiersprache festgelegt ist. Ist man beim Cross-Compiling zwar auch nicht, aber dann braucht man neue Toolchains, neue Plugins etc. Vielleicht hilft es ja jemand oder jemand sieht es ganz anders?
Felix schrieb: > So, ich habe mich mal durchgequält, alles installiert und ein > kleines > Beispiel mit WiringPi aufgebaut, compiliert und remote debugged. Nochmal: QtCreator, den ganzen Ballast, den du beschreibst, hast du mit der IDE NICHT! Anleitungen, wie man bare bone/cross compile Projekte damit umsetzt gibt es genug im Netz. Zum Beispiel: https://www.ics.com/blog/configuring-qt-creator-raspberry-pi.
Bist Du sicher, dass das nicht veraltet ist? Die verlinkten Quellen (z.B. https://wiki.qt.io/RaspberryPi2EGLFS) beziehen sich auf Raspian Stretch und sind seit 5 Jahren nicht mehr angepasst worden, gilt auch für die verlinkte Toolchain. Weiss nicht, ob da noch so viel passiert. Und die Grundproblematik mit der Gigabyte-großen ständig veralteten Toolchain ist doch dieselbe, nur das Tool drumrum ist ein anderes. Gut, lohnt sich wahrscheinlich, wenn man in der Qt-Welt unterwegs ist.
Guten Abend, mich würde nun interessieren ob der Weg mit Eclipse und der GNU ARM Toolchain veraltet ist oder nicht? @Felix: Ich kann nicht ganz nachvollziehen welchen Weg du für die Entwicklung von C/C++ Code auf einem Windowsrechner mit remote Zugriff auf einen raspberry pi zero.
Veraltet ist der Weg des Cross-Compilings sicher nicht. Bei Mikrocontrollern ohne Betriebssystem gibt es ja auch keine andere Wahl (nackter ARM-Chip, ATmega,...). Die Arduino-IDE funktioniert ja nach demselben Prinzip. Die Frage ist halt, ob es notwendig ist. Beim Raspberry Pi mit Linux finde ich wie oben beschrieben, dass die Nachteile in den allermeisten Fällen überwiegen. Du musst halt überlegen, was Du machen willst und was Du brauchst. Ansonsten solltest Du die Toolchain von der IDE drumrum gedanklich getrennt halten. Mit einer Toolchain kannst Du mit Eclipse arbeiten, mit QtCreator, mit vielen anderen und sogar direkt auf der Windows-Kommandozeile. Letzteres beschreibt ja die Doku von SysProgs sehr gut, da ist alles drin von der Installation bis hin zum Remote-Debuggen in sehr wenigen Schritten: https://gnutoolchains.com/raspberry/tutorial/ Nach dieser Anleitung bin ich vorgegangen und damit lief dann schon alles. Filetransport mache ich mit Bitvise SSH. Notwendig ist halt noch der Synch von Sysroot, dazu habe ich die Anleitung gepostet und Jedzia den Link auf UpdateSysroot.bat Aus Sicht der Toolchain ist damit eigentlich alles gesagt. Danach habe ich noch Eclipse draufgesetzt. Dazu sind Deine Youtubes nicht so schlecht, nur erklären sie halt nicht, warum man etwas macht. Make z.B. braucht man meiner Meinung nach nicht noch separat. Optimal ist da die Docu von Eclipse selbst: https://eclipse-embed-cdt.github.io/, setzt halt voraus, dass man versteht, was man warum tut. Ein ganz gutes Komplett-Dokument gibt es von Bosch/Rexroth: https://www.boschrexroth.com/documents/portlet_file_entry/12605/Eal4c_And_RaspberryPi_RemoteDebugging.pdf/8472d778-9452-da76-59fd-a7e35ee17857?download=true Da muss man sich nur den Teil mit dem EAL SDK wegdenken.
jetzt verstehe ich, weshalb Freepascal auf dem RasPI so einen Hpe erlebt. Da kann man das gleich direkt drauf laufen lassen und auch dort kompilieren und hat eine IDE etc. Muss es denn bei dir C sein? Sonst schau mal im Freepascal Forum. Ich glaube nirgends wird FreePAscal so häufig genutzt wie unter Linux und Raspi Witzigerweise war ich damals immer davon ausgegangen das unter Linux fast jeder in C programmiert
Ich habe gute Erfahrungen mit Visual Studio Code und den Remote-Erweiterungen gemacht. Visual Studio Code auf Windows installieren, darin dann die Remote Extensions für SSH Installieren. Von dort aus per SSH auf den Raspi verbinden. (Das installiert ein Backend auf dem Raspi im Benutzerverzeichnis) Der Quellcode liegt dann auf dem Raspi, auch Compiler, Debugger werden einfach vom Raspi Linux benutzt und dort ausgeführt, vollkommen egal welche Distribution dort läuft. Das VS Code auf dem Entwicklerrechner ist quasi nur ein graphisches Frontend, alles andere wird transparent auf dem Raspi erledigt. Der Vorteil ist, es funktioniert mit allen Sprachen gleich, egal ob man Python, C++ , Javascript, Shell oder C# benutzten möchte und man braucht auf dem Raspi keine Grafikoberfläche laufen lassen. Ärger mit einem nicht passenden Cross-Compiler hat man dann auch nicht. Nachteil: Compilieren braucht logischerweise etwas länger weil der Raspi nicht so performant ist. Das ganze funktioniert auch wenn man das SSH noch über andere Rechner Tunneln muss (Ich komme über Firmen VPN nur auf bestimmte Rechner per SSH, von dort gehe ich dann weiter...)
:
Bearbeitet durch User
Hi, Danke für eure weiteren Posts. Ich kann trotz Anleitung UpdateSysroot.bat nicht finden. Auf keiner ARm GNU Toolchain Version kann ich dieses Tool finden.
>Nach dieser Anleitung bin ich vorgegangen >und damit lief dann schon alles. Filetransport >mache ich mit Bitvise SSH. Notwendig ist >halt noch der Synch von Sysroot, dazu habe >ich die Anleitung gepostet und Jedzia den >Link auf UpdateSysroot.bat >Aus Sicht der Toolchain ist damit eigentlich >alles gesagt. Kann den Link zu Jedzia nicht finden
rpi schrieb: > Kann den Link zu Jedzia nicht finden Das meinst Du nicht ernst, oder? CTRL+F im Browser gleich jetzt wenn Du das liest. Nach Jedzia suchen. Den Text lesen. Den Link rauskopieren. raspberry-gcc6.3.0-r4.exe runterladen. Installieren. Wie von Jedzia beschrieben steht die Datei unter C:\SysGCC\raspberry\TOOLS\UpdateSysroot.bat Das Tools Verzeichnis kopierst Du in Deine neue aktuelle Toolchain und bist fertig. Als besonderer Service hier der Link, dann musst Du noch nicht mal hochscrollen: https://github.com/sysprogs/gnutoolchains/releases/download/raspberry-gcc6.3.0-r4/raspberry-gcc6.3.0-r4.exe Weiterer Service: Du kannst beim Installieren den Installationspfad angeben. Das solltest Du tun, sonst hat Du in Deinem Unterverzeichnis eine Mischung aus alter und neuer Version und es wird nichts mehr laufen. Aber ganz im Ernst: das hier ist kein Adventure, wo Du den Drachen suchen und töten musst. Überlege Dir doch bitte, was genau Du tun willst und warum. Was ist Dein Ziel? Dann gehe es mit möglichst einfachen Mitteln systematisch an. Wenn das Cross-Compiling für Deinen aktuellen Kenntnisstand zu komplex ist, ist es das falsche Mittel. Das ist es in den meisten Fällen sowieso. Ebenso wie der Raspberry Zero. Den nimmt man nur, wenn man es klein und stromsparend braucht - nicht bloss, weil er 10 Euro billiger ist als ein anderes Modell. Zum Lernen ist er das falsche Gerät, weil halt nicht alles drauf läuft und so ist ein guter Teil der Tutorials im Netz für Dich unbrauchbar. Das Gleiche gilt für C/C++. Wenn Du Programmieren lernen willst, ist Python besser, das braucht keinen Compiler. Oder halt das hier empfohlene FreePascal.
Hallo Felix, zuerst vielen Dank. Ich hab die exe Datei heruntergeladen und siehe da, da ist auch die Batchdatei. Hab dann gleich die Batchdatei ausgeführt und die Daten synchronisiert. Werden dadurch die Daten auf raspberry pi gleich gezogen mit den lokalen Daten von Windows oder umgekehrt?
Kann man das Tool auch in seine Eclipse-Umgebung einbinden?
rpi schrieb: > Werden dadurch die Daten auf raspberry pi > gleich gezogen mit den lokalen Daten von Windows oder umgekehrt? > Kann man das Tool auch in seine Eclipse-Umgebung einbinden? Auf keinen Fall darfst Du Sysroot in Richtung PC->Raspberry synchronisieren (macht UpdateSysroot.bat auch nicht). Grund ist, dass auf Raspberry-Seite der Linux-Package-Manager die Installation verwaltet, den bringst Du mit Updates von der Seite aus dem Tritt. Es macht auch keinen Sinn, denn die Daten im Sysroot-Verzeichnis vom PC werden ja nie vom PC aus verändert, das ist eine reine Referenz für Eclipse bzw. Compiler und Linker. Ein Antriggern dieses Vorgangs per Eclipse ist sicher möglich (in Eclipse kann man alles konfigurieren), aber wozu? Das machst Du im Normalfall ein paarmal im Jahr. Warum sollte man da Stunden drüber brüten? Oder verwechselst Du das mit dem Deployen der compilierten Builds auf den Raspberry? Die liegen im Build-Verzeichnis von Eclipse, niemals in Sysroot. Das sollte man natürlich automatisieren, ist eigentlich bei Embedded C/C++ Eclipse auch vorbereitet. Wenn Du Bestandteile von Linux selbst cross-compilest, musst Du natürlich Abhängigkeit zum Package-Manager beachten... Kannst Du mal kurz beschreiben, was Du eigentlich erreichen willst?
Hi Felix, ich möchte mit dem raspberry pi zero experimentieren im Bereich embedded Software in C oder auch in C++. Dazu habe ich mich entschlossen auf Windows per Remote C Code für den raspberry pi zu entwickeln. Soweit funktioniert nun fast alles.
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.