C/C++ Entwicklungsumgebung für raspberry pi zero w

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.

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

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.

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.

Ich habe die Toolchain auf Windows installiert

>https://gnutoolchains.com/download/

Und ich habe auf Windows mingw32 installiert

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

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

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.