Mittels Eclipse unter Win auf ARM mit Debian remote entwickeln

[Rolf O. (roppi)]

Hallo Elektronikgemeinde,

mir stellt sich folgendes Problem:

Derzeit arbeite ich an einem Projekt welches auf dem Beaglebaord (Rev. 
C4) basiert. Auf dem ARM (Coretex A8) arbeitet ein Debian (Lenny). Aus 
verschiedenen Gründen steht mir weiter kein Linux zur Verfügung auf dem 
ich eine adäquate Entwicklungsumgebung installieren kann. Also möchte 
ich um übersichtlich und komfortabel entwickeln zu können, mittels einer 
IDE auf einem Windows Rechner remote auf dem Linux des Beagleboards 
entwickeln und nach Möglichkeit auch debuggen (mittels gdbserver).

Als IDE springt einen nach diversen Internetrecherchen Eclipse förmlich 
an. Zudem gibt es von Keil für drei solcher Entwicklungsboards (u. a. 
auch für das Beagleboard) ein entsprechendes Plugin. Allerdings war das 
bis dato eine Trial-Version welche zum 01.10. ausgelaufen ist. Eine 
Lizenz zu erwerben ist auf Grund eines Haushaltsstopps derzeit nicht 
möglich. Bis auf leichte Probleme beim Debuggen funktionierte dies aber 
ganz gut.
Nun suche ich nach einer Alternative. Es gibt auch etwaige Tutorials im 
Netz um Eclipse mit den entsprechenden Komponenten zu erweitern und zu 
konfigurieren. Allerdings keines, welches ich bisher erfolgreich 
abarbeiten konnte. Inzwischen habe ich auch entsprechende Toolchains 
gefunden (oder How-To's zur Erstellung). Allerdings gelang es mir auch 
hier bisher nicht die IDE funktionsfähig einzurichten.

Mein Hauptproblem ist, dass mir die Zeit fehlt um mich detailierter in 
die Thematiken Eclipse, Toolchains, gcc und Debugger einzuarbeiten. 
Daher bin ich auf der Suche, ob es ein ausführliches How-To gibt damit 
ich mir Eclipse entsprechend einrichten kann.

Ansonsten würde mir natürlich auch eine alternative IDE weiterhelfen, 
welche für solche Zwecke gedacht ist. Nur finde ich, dass Eclipse halt 
äußerst flexibel ist.

Per ssh komme ich auch ohne Probleme auf das Beagleboard. Allerdings 
finde ich für komplexere Aufgaben die Entwicklung auf der Konsole zu 
unübersichtlich. In das Debuggen mit gdb auf der Konsole müsste ich mich 
auch erst noch einarbeiten.

Vielen Dank schon mal für Eure Hilfe.
Gruß, Oppi

[Imon (Gast)]

Rolf O. schrieb:
> Derzeit arbeite ich an einem Projekt welches auf dem Beaglebaord (Rev.
> C4) basiert. Auf dem ARM (Coretex A8) arbeitet ein Debian (Lenny). Aus
> verschiedenen Gründen steht mir weiter kein Linux zur Verfügung auf dem
> ich eine adäquate Entwicklungsumgebung installieren kann.

wie wäre es mit einer Entsprechenden VM, die Serielle und das Netzwerk
kann man dort Rausschleifen, mehr braucht man meistens nicht. Ist nach 
meiner Meinung zwar auch nicht der Weisheit letzter Schluss geht aber 
wahrscheinlich.

> Also möchte
> ich um übersichtlich und komfortabel entwickeln zu können, mittels einer
> IDE auf einem Windows Rechner remote auf dem Linux des Beagleboards
> entwickeln und nach Möglichkeit auch debuggen (mittels gdbserver).
>
okay ich denke ich würde eine Vm nehmen wenn ich die Wahl habe

> Als IDE springt einen nach diversen Internetrecherchen Eclipse förmlich
> an.
Ja leider, ich persönlich bin vim fan und lass mich auch nicht bekehren 
;-)

>  Zudem gibt es von Keil für drei solcher Entwicklungsboards (u. a.
> auch für das Beagleboard) ein entsprechendes Plugin. Allerdings war das
> bis dato eine Trial-Version welche zum 01.10. ausgelaufen ist. Eine
> Lizenz zu erwerben ist auf Grund eines Haushaltsstopps derzeit nicht
> möglich. Bis auf leichte Probleme beim Debuggen funktionierte dies aber
> ganz gut.
lach was sind für dich leichte Probleme beim Debuggen ich dachte für 
sowas hast du das Plug in scheint also nicht wirklich zu taugen :)

> Mein Hauptproblem ist, dass mir die Zeit fehlt um mich detailierter in
> die Thematiken Eclipse, Toolchains, gcc und Debugger einzuarbeiten.

Das sind auch ganz schöne Bretter die du da Bohren willst/musst.
btw. ist das so viel günstiger dich als Entwickler da Wochen an 
Forschung rein zustecken lassen als das von dir begehrte Plugin von Keil 
zu erwerben, ich glaube bei realistischer Betrachtung wäre das Plug in 
billiger, aber das ein Management zu erklären ist schwer ich weiß,

> Per ssh komme ich auch ohne Probleme auf das Beagleboard. Allerdings
> finde ich für komplexere Aufgaben die Entwicklung auf der Konsole zu
> unübersichtlich. In das Debuggen mit gdb auf der Konsole müsste ich mich
> auch erst noch einarbeiten.
>

ddd (Debuggen durch Denken) geht immer,im zweifel ddd mit printf 
debuggen auch wenn es Mühsam ist.
generell solltest du vielleicht nochmal deine Strategie überdenken, was 
must du debuggen eine Anwendung auf denn Beagle board, das kann man mit 
den Eclipse und den gdb server gut machen, nur das würde ich mir nicht 
antun, ich würde mir einen Linux System einfodern und wenn es eine VM 
ist
dort mein Programm entwickeln debuggen etc. bis es funktioniert.
die üblichen verdächtigen was die schnittstellen deines Programms angeht 
zum system sind Standart, Framebuffer ist immer /dev/fb0, Serielle immer 
/dev/ttyXY usw da kann man denn meisten teil auf ein Linux host schon 
entwickeln und bequem debuggen. wenn dann die Applikation auf denn Host 
tut wird einfach der Kompiler gegen denn der Toolchain ausgetauscht und 
man hat eine gute Bais bei der schon 90 Prozent der Fehler elemeniert 
sind.

Angenehmer neben Effekt man kann die Software schon in angriff nehmen 
lange bevor die Hardware existiert.

beim Treiber entwickeln ist das leider ein wneig anders aber da hilft 
auch der gdb nicht wirklich hier würde ich mir eher mit printf bzw 
printk helfen und bei denn Problemen die so nicht erschlagen werden 
können mit einen JTAG wie Openbcd oder besser denn Problem zu leibe 
rücken.

[Rolf O. (roppi)]

Danke erst mal für diese ersten Kommentar. Einige dieser Ideen hatte ich 
auch schon erwogen. Allerdings hatte ich z.B. mit im Bereich VM bereits 
Probleme, als es darum ging die SD-Card mit einem Debian für das 
Beagleboard vorzubereiten.

Im Grunde muss ich aber sagen, dass ich vom Bedienkomfort (und zwecks 
Zeitersparnis bei der Einarbeitung) eine vorhandene IDE bevorzugen 
würde. Daher gefiel mir zu Anfang gleich das Produkt von Keil.

Die Argumente doch das DS-5 anzuschaffen sind 100%ig richtig. Bei diesem 
Projekt handelt es sich um eine Studienarbeit für meinen Master. Die 
Bearbeitungszeit neigt sich allerdings dem Ende und das was ich jetzt 
noch machen möchte, sind mehr Ad-Ons weil ich einfach mit dem erreichten 
Stand nicht zufrieden bin. Um so ärgerlicher ist es, wie viel Zeit 
bisher schon verstrichen ist nur um ein wenig Software zu schreiben.
Primär habe ich mich in der Studienarbeit um Hardware gekümmert und 
benötige jetzt das ein oder andere an Software um einige Messungen und 
Tests mit der Hardware durchzuführen.

Inzwischen habe ich noch zwei Teilerfolge gehabt. Zum einen bin ich 
gerade dabei WinGDB auszuprobieren. Ein PlugIn für MS Visual Studio. Zum 
anderen habe ich in anderen HowTo's das Produkt Macraigor (basiert auch 
auf Eclipse und nutzt den GDB) entdeckt. Im Grunde sieht dies auch die 
Entwicklung direkt auf der Hardware vor. Treiberentwicklung will ich 
aber den nächsten Studenten überlassen und mich damit nicht mehr 
befassen. Hier waren auch Beispielprojekte (auch für das Beagleboard) 
enthalten. Diese funktionieren auch - inkl. Debugger.

Allerdings gelingt es mir nicht, aus den vorhandenen Beispielprojekten 
ein eigenes Projekt anzulegen, welches sich Übersetzen, geschweige denn 
Debuggen lässt. Wenn ich mich mit den beiliegenden Dateien (Makefile, 
GDBinit, etc.) befasse wird mir schon klar, dass es an diesen Dingen 
scheitert.

Kann hier vielleicht einer den Ablauf schildern, was ich alles beachten 
muss um ein Projekt für ein Target zu compilieren, linken, etc. und was 
evtl. noch bei den Debuggereinstellungen zu beachten ist?

Vielen Dank!

[Imon (Gast)]

Rolf O. schrieb:
> Danke erst mal für diese ersten Kommentar. Einige dieser Ideen hatte ich
> auch schon erwogen. Allerdings hatte ich z.B. mit im Bereich VM bereits
> Probleme, als es darum ging die SD-Card mit einem Debian für das
> Beagleboard vorzubereiten.
>
>
Die SD-Card werden meistens über ein USB Device eingelesen intern oder 
extern spielt hier kaum eine rolle, diese USB device must du in der VM 
verfügbar machen.Wichtiger ist in der Vm allerdings die Serielle und ein
Netzwerk, an besten im Brige mode, NAT ist suboptimal, sobald das 
Verfügbar ist, würde ich an deiner stelle mein Beagle board so 
einstellen das es mit ein NFS root von dein host bootet, das hat denn 
großen Vorteil das du das binary auf denn host hast und im zweifel es 
durch neu Kompilieren und Kopieren schnell austauschen kannst ohne dein 
Target neu starten zu müssen.

NFS ist nach meine Erfahrung das schnellste um Software für ein Embedded 
linux auf denn Target zu entwickeln, beim Treiberentwickeln ( was du ja 
nicht machst) würde ich den uboot auf den beagleboard auch noch sagen 
hohl den kernel via tftp.


> Allerdings gelingt es mir nicht, aus den vorhandenen Beispielprojekten
> ein eigenes Projekt anzulegen, welches sich Übersetzen, geschweige denn
> Debuggen lässt. Wenn ich mich mit den beiliegenden Dateien (Makefile,
> GDBinit, etc.) befasse wird mir schon klar, dass es an diesen Dingen
> scheitert.
>
 wie schon gesagt ich nutze extesiv die Konsole und dort eine embedded 
build system. kann dir also leider wenig über das Eclipse einrichten 
sagen.

> Kann hier vielleicht einer den Ablauf schildern, was ich alles beachten
> muss um ein Projekt für ein Target zu compilieren, linken, etc. und was
> evtl. noch bei den Debuggereinstellungen zu beachten ist?
>

klar da gibt es eigentlich wenig Geheimnisse das wichtiges ist das du 
eine funktionierende Toolchain hast, die meisten Toolchains unter Linux 
( sorry ich entwickle nur unter Linux ) liegen unter /opt/<hersteller 
name> das solltest du bei dir unbedingt genau so halten wie der 
Hersteller das vorgibt, sonst kann es hässlich werden. Meisten gibt es 
in denn toolchain Verzeichnis ein unter Verzeichnis bin und sysroot. das 
bin Verzeichnis solltest du in dein Path aufnehmen, um dein Compiler 
nicht immer mit den Kompletten path aufrufen zu müssen.

Das sysroot entspricht denn was du auf den target hast. wenn du ihr 
hinein siehst fällt auf das es eine gewisse Ähnlichkeit zum root 
Verzeichnis hat.
Das kannst du als rootfilesystem (rootfs) für dein NFS export nehmen. Es 
ist üblich das die installierten Libs und Programme im sysroot mit 
debuggsymbolen installiert sind und du mit denn sysroot über NFS das 
komplette System Debuggen kannst.

bei denn erzeugen deiner eigenen Programme würde ich ein Makefile 
schreiben, hier gibt es eigentlich kaum was zu beachten für denn 
Compiler ist die Variable CC übliche für den Linker LD für die Compiler 
Optionen CFLAGS den Linker LDFLAGS etc. alles was du nun machen must ist 
am Anfang des Make file die Variable CC auf dein Arm Compiler 
umzustellen das gleiche für die anderen Tools wie Linker 
objcopy,objdump, linker etc...

die richtigen Werkzeuge für dein beagleboard sollten denn Präfix 
arm-linux-eabi- haben.
Einfach denn Compilern nutzen denn Rest sollte deine toolchain 
automatisch machen und gültigen Code für dein Target erzeugen.

beim Debuggen hat mir früher der Aufsatz ddd für den gdb gute Dienste 
geleistet denn Konnte man via Parameter denn passenden gdb mitgeben
das wäre in dein fall auch wieder arm-linux-eabi-gdb.

ich hoffe das hilft dir ein wenig auch wenn es das Arbeiten unter Linux 
umschriebt.