Hi,

Ich beschäftige mich zur Zeit auch mit ARM Controllern. Als Compiler
nutze ich den GNU ARM. Als IDE hab ich Eclipse, aber dafür bisher kein
Plugin gefunden. Deshalb hab ich mich gestern mal dran gesetzt und eins
geschrieben. Als Vorlage diente mir unter anderem auch das Plugin von
Peter Winter für Atmel uController.

Falls es jemand testen möchte, ich habs als Anhang mit hochgeladen. Es
funktioniert soweit, aber ich denke es muss noch einiges ergänzt werden.
Verbesserungsvorschläge und Ergänzungen sind also durchaus erwünscht.

Die Installation erfolgt durch kopieren ins Plugin Verzeichnis. Zur Zeit
ist es auf Linux beschränkt, aber das muss ja nicht so bleiben.

Das Projekt ist jetzt auch über Sourceforge erreichbar:
http://www.sourceforge.net/projects/gnuarmeclipse

Wodurch ist die Beschränkung auf Linux begründet bzw. was wäre zu tun,
um das Plugin unter Windows einzusetzen?

Zur Zeit sind die unter Linux verwendeten Binaries (AS, GCC, LD)
eingetragen. Ich habs bisher nur unter Linux getestet, deshalb erstmal
die Beschränkung. Als Vorlage diente mir das AVR-Plugin und da war eine
Unterscheidung zwischen Linux und Win32. Ich gucks mir aber noch an
denke mal das ist nicht so ein großer aufwand das für Windows zu
ergänzen.

So bin endlich dazu gekommen die WinARM-Toolchain zu integrieren. Das
Plugin kann von der oben genannten Sourceforge Seite herunter geladen
werden.

Hallo,
ich habe leider ein Problem mit dem Plugin.

main.c:
#include <stdio.h>
int main(void) { echo("Hurra"); return 0;}

Wenn ich dieses file mit arm-linux-gcc main.c compile und auf das Target
lade, funktioniert alles wunderbar.

Wenn ich jedoch das file mit dem Plugin aus Eclipse heraus builde,
bekomme ich folgende warning:
arm-linux-ld: warning: cannot find entry symbol _start; defaulting to
00008244
und beim Ausführen auf dem Target bekomme ich ein "not found".

Irgend eine Idee, welche Einstellungen noch zu tätigen sind?


Danke

LG
Fritz

hallo fritz!

die meldung heisst: der linker findet die funktion _start nicht. die ist
aller wahrscheinlichkeit nach im linkerscript angegegen, wird aber, aus
welchem grund auch immer, nicht assembliert. du musst also deinen
assembler dazu bewegen, das assembler modul crt0, indem die funktion
_start existieren sollte, zu assemblieren.

viel erfolg,
nemesis

Ich werds mir mal anschauen und versuchen das Problem zu lösen.

Abend,
habe das Problem nun anders in Griff bekommen.
Habe ein Standard Managed Projekt gemacht und dann beim Assembler,
Compiler und Linker einfach die compiler binaries auf arm-linux-as,
arm-linux-gcc und arm-linux-gcc geändert.
Interessanterweise haut das so hin. D.h. Linker auch mit arm-linux-gcc
aufrufen.

Anfangs hatte ich auch probiert die crt0 dazu zu assemblieren. Hat auch
geklappt, aber beim Ausführen des entstandenen Binaries auf dem Target
kam entweder Segfault oder file not found.

Danke trotzdem für eure Hilfe

LG
Fritz

Hmm, ok, ich werde die Spur mal verfolgen. Wäre ja schön, wenn man für
ein neues Projekt nicht erst alle arm-linux-* ändern müsste und vor
allem das Target gleich auswählen könnte.

Ich hab das gerade mal getestet, aus einem mir noch nicht verständlichen
Grund werden ".S" Dateien nicht übersetzt. Ich gehe dem aber nach und
werde dann eine neue Versionen veröffentlichen.

okay, vielen dank
bin beruhigt, dass der fehler nicht an mir lag:-)

Hallo,

diese Idee finde ich super. Ich kompilieren im Moment für mein
ARM9-Board in einer virtuellen Maschine, was alles andere als nett ist.

Ich werde es gleich mal ausprobieren. Hältst du uns auf dem Laufenden
über die Entwicklung?

Günther

klar =)

Wie gesagt ansonsten gibts auch News auf der Sourceforge.Net Seite. Ein
RSS-Feed gibts auch =).

Zu dem Fehler das Crt nicht berücksichtigt wird....

Wenn die Datei crt.S heißt gehts nicht, mit crt.s wiederum doch.
Vielleicht hilft das übergangsweise. Ein Linker Script muss man mit "-T"
in den Build-Seetings noch angeben (Linker... Misc...).

Bitte mal testen, ob das die Probleme beseitigt.

Öhm, Hm.

Ich habe jetzt mal ne Eclipse mit C-Unterstützung runtergeladen und dein
Plugin ins Plaugin-Verzeichnis kopiert. Und jetzt?

Hab ein neues Projekt angefangen, aber da kann ich irgendwie kein
GNUARMECLIPSE auswählen. Sorry, ist mein erstes Mal mit der Eclipse ;-)

Günther

So sollte es gehen: -> File -> New Project -> Managed C Make Project ->
Next -> Project Name -> Next -> Project Type: Executable (ARM)...

Weiter Info: Das ".S" Assembler-Dateien nicht übersetzt werden ist kein
Fehler meines Plugins. Es liegt an Eclipse-CDT. Man kann das aber unter
"Properties, File Types" hinzufügen und dann gehts auch.

Es gibt mal wieder eine neue Version...
 -> http://www.sourceforge.net/projects/gnuarmeclipse

Hallo,

das Plugin funktioniert mit C gut. Aber was ist mit C++. Welche
Änderungen müssen vorgenommen werden? Oder wird es eine C++-Version
dieses Plugins geben.
Ich benutze den YAGARTO-Compiler bzw. die SDK4ARM von Amontec.

Karsten

Dazu muss ich es noch erweitern. Ich werde mich da mal mit beschäftigen
und geb dann bescheid wenns fertig ist =).

Ich hab mich gerade mal rangesetzt und den C++ support eingbaut. Bitte
mal testen obs auch bei euch funktioniert.

Achso... Download wie bisher hier
-> http://www.sourceforge.net/projects/gnuarmeclipse

Hallo Wilfried,
vielen Dank für deine tolle Arbeit. In deiner neuen Version fehlt aber
bei dem C++-Projekt (Win32) die Kategorie für den Assembler. Deshalb
habe ich diese hinzugefügt. Außerdem kommen noch einige Optionen hinzu.
Im Anhang ist die veränderte Version von deinem Plug-in. Ich habe es
getestet und es funktioniert einwandfrei (in Windows natürlich).
Nochmal vielen Dank!!

Mit freundlichen Grüßen
 Le Viet Bach

Hi, ok danke, werds mir anschauen und dann ins svn übernommen =).

So habs übernommen und auch gleich den Assembler für C++ unter Linux
hinzugfügt. Das ganze ist auf Sourceforge als Version 0.0.7 zu download
bereit.

Und die Arbeit hab ich gern gemacht, gemessen an den Downloads hat es
sich ja schon gelohnt =).

Hallo Wilfried,
1. sorry, ich habe einen Fehler gemacht und zwar beim ObjCopyFlash. Nach
dem Buildvorgang kommt folgendes raus:

arm-elf-objcopy -O ihex Test_Cpp_1.elf Test_Cpp_1.hex -j .intvect -j
.text -j .data"Test_Cpp_1.hex"

Die Sektion .intvect ist persönlich vor mir in meinem Projekt erstellt
worden. Ich habe auch gemerkt, dass "Test_Cpp_1.hex" automatisch
hinzugefügt wird. Könntest du das Plug-in so umändern, dass nur

arm-elf-objcopy -O ihex Test_Cpp_1.elf Test_Cpp_1.hex

herauskommt (Ich habe versucht, aber ohne Erfolg), denn es werden dann
alle Sektionen kopiert -> wenn man viele Sektionen definiert hat, muss
man diese nicht eintippen. :-)

2. bei der Option "Optimization Level" kommt bei mir folgendes vor:
      None (-O0)
      Optimize more (-O2)
      Optimize most (-O3)
      Optimize most (-O3).
Ich weiss nicht, ob der Fehler auch bei dir auftritt??

3. Die Erzeugung einer .map-Datei beim Linken meiner Meinung nach ist
meistens hilfsreich. Deshalb habe ich in der neu veränderten Version bei
"Linker flags" -Map=${BuildArtifactFileBaseName}.map als default mit
übergeben.

Also, im Anhang ist die neue Version mit "-Map=..." und ohne "-j
.intvect".
Schöne Grüße,
Le Viet Bach

PS. Es kommt wahrscheinlich noch einiges von mir :-)

D.h. ich muss nur wieder den Inhalt von "plugin.xml" übernehmen?

Hallo nochmal,
das Problem mit dem "Optimization level" wurde gelöst. Im Anhang ist die
korrigierte Version. Ich denke, das Plug-in ist jetzt auf einem guten
Stand und muss nicht viel geändert werden, außer Punkt 1, was ich oben
erwähnt habe. Ok Wilfried, schaust du bitte nochmal das Plug-in an.

Schöne Grüße,
Le Viet Bach

Re: D.h. ich muss nur wieder den Inhalt von "plugin.xml" übernehmen?

Ja.

Ok, ich übernehm das ... und bei dem andern bin ich gerade bei.
Da wollte ich gerade einfach ein paar Auswahlen machen:

 ( ) -j .text
 ( ) -j .data

und dazu noch eine Box in der man noch neue eingeben kann...

D.h. man nichts auswhählen oder die vorgegebenen oder eigene neue.

Wäre das das was Du brauchst?

Funktioniert das Plugin jetzt auch unter Windows?

mfg danke

Ja, das ist auch eine Möglichkeit. Aber ich denke, wenn man nichts
auswählt, wird es Probleme geben. Denn ich habe erwähnt, dass
"Test_Cpp_1.hex" automatisch hinzugefügt wird -> Fehler. Probierst du
mal bitte.

Unter Windows funktioniert es einwandfrei.

Super danke dann werde ich es gleich mal testen.

Wo findet man eigentlich eine Beschreibung? Oder gibt es sowas nicht?

mfg danke

So viel ich weiss, es gibt noch keine Beschreibung dafür.

Schöne Grüße,
Le Viet Bach

Ja zur Zeit gibts keine Beschreibung, es verhält sich halt wie die CDT
für C(++) für andere Architekturen nur das es hier spezielle
Einstellungen für ARM gibt. Ich dachte es wäre selbst erklärend, aber
wenns fragen gibt her damit, dann erstelle ich auf der Sourceforge Seite
eine FAQ =).

Hallo Wilfried,
im Anhang ist das plugin.xml. Ich hab etwas geändert und zwar:
Es gibt keinen C/C++ Assembler bzw. C/C++ Linker mehr (da es nur einen
Assembler/Linker gibt, war blöd von mir ) :-).

  "natureFilter = both" ; C++ Assembler/Linker tool gelöscht
 (in beiden Linux und Windows Versionen)

Schöne Grüße,
Le Viet Bach

>> Ja, das ist auch eine Möglichkeit. Aber ich denke, wenn man nichts
>> auswählt, wird es Probleme geben. Denn ich habe erwähnt, dass
>> "Test_Cpp_1.hex" automatisch hinzugefügt wird -> Fehler. Probierst du
>> mal bitte.

Habs mir angeschaut, lösen kann man es in dem in den "Expert Settings"
"${OUTPUT}" herausnimmt.

Ok, ändere auch das mit dem Assembler =).

Danke, es funktioniert.

1/ Wie unterscheidet sich dein CDT von dem CDT, das z.B. unter
http://www.eclipse.org/cdt/ vorgestellt wird?

2/ Wie unterscheidet sich dein CDT von dem Zylin CDT, das bei der
Kombination Eclipse / YAGARTO GNU ARM benutzt wird?

3/ Ist es möglich, (selbst) Anpassungen für weitere Toolchains
einzubauen?
Beispielsweise, wenn man AVR, ARM, R8C, MSP430 mit GCC-Toolchains
programmiert und Eclipse als "Universal"-IDE verwenden will.

4/ Wie gestaltet sich der Wechsel zwischen verschiedenen Toolchains?
Sind jeweils andere CDTs zu installieren oder sind nur Configfiles für
eine CDT erforderlich? Kann ein Wechsel innerhalb Eclipse durchgeführt
werden (also "hot") oder ist ein Restart der IDE mit geänderterter
Konfiguration (Pfade, Plugins) erforderlich?

zu 1: Meins ist eine erweiterung vom CDT für ARM.

zu 2: Soweit ich weiß ist das von Zylin mehr fürs Debugging, bin mir
aber nich sicher.

zu 3: Ja, es ist möglich, ein AVR Plugin gibts hier schon im Forum von
Peter Winter.

zu 4: Wenn Du das Plugin für eine Toolchain gebaut hast, dann kannst Du
beim erstellen eines Projektes auswählen was Du erstellen möchtest.. ich
kann wäheln zwischen:

Executable (GNU) - Linux Program
...
Executable (AVR) - Atmel uC Program
Library    (AVR) - Atmel uC Lib
Executable (ARM) - ARM Programm

Noch zu 4: Man wählt beim erstellen eines Projektes die Konfiguration.
Damit wird dann das Projekt verwaltet, man kann aber ein zweites Projekt
im geichen Workspace für eine andere Architektur erstellen.

Eclipse unerscheidet da zwischen verschiedenen Views: Java, CDT für C
und C++ usw.

So alle Änderungen seit der Version 0.0.7 die hier vorgeschlagen wurden
sind nun im SVN und als Version 0.0.8 auf Sourceforge zum Download
bereit.

Hi Wilfried,
basierend auf deinem Plug-in habe ich ein Static library Plug-in für ARM
erstellt. Falls du Interesse hast bzw. Wenn du mir die Erlaubnis
erteilt, werde ich das Plug-in hier hochladen.

mfg

Noch eine Bitte, wenn jemand Änderungen vornimmt bitte die .jar Datei
mit eine Revisionsnummer erweitern um Verwechslungen zu vermeiden. Im
folgenden z.B. org.eclipse.cdt.gnuarm_0.0.8-r1.jar oder einfach nur
plugin-0.0.8-r1.xml.

>> Hi Wilfried,
>> basierend auf deinem Plug-in habe ich ein Static library Plug-in für ARM
>> erstellt. Falls du Interesse hast bzw. Wenn du mir die Erlaubnis
>> erteilt, werde ich das Plug-in hier hochladen.

Gern =).

Im Anhang ist das Plugin getestet in Windows.
Viel Spaß beim Testen :-) wünsche ich euch.

mfg

Was muss dann im Source alles drin sein um eine Lib zu erstellen?
Dann teste ich das auch gleich mal unter Linux.

Beispiel:
Du erstellst ein Static-Library-Projekt mit folgenden Dateien:
wait.c, wait.h

In "wait.c":

#include <wait.h>
void WaitAWhile()
{
  unsigned int ui_count = 100000;
  while( ui_count-- != 0);
}

In "wait.h":
extern void WaitAWhile();

Dann 1. Project->Properties->C Compiler-> Directories->"Pfad zu wait.h"
(-I Option )
     2. Build Settings -> Artifact name: libwait
     3. Build Project
  --> libwait.a

mfg

Hmm, da scheint irgendwas noch nicht zu laufen...


**** Build of configuration Release for project libwait ****

make -k all
Building target: libwait.elf
Invoking: Archiver
arm-elf-linux-gnu-ar  "libwait.elf"
arm-elf-linux-gnu-ar: illegal option -- w
Usage: arm-elf-linux-gnu-ar [emulation options]
[-]{dmpqrstx}[abcfilNoPsSuvV] [member-name] [count] archive-file file...
       arm-elf-linux-gnu-ar -M [<mri-script]
 commands:

...

Sorry, kannst du diese Version testen??

Anscheinend fehlt das Flag -r hinter arm-elf-ar.

Ja, wenn ich das "-r" hinzufüge gehts.

Steht es bei dir nicht unter Archiver/General/Archiver flags = -r
nachdem du ein neues Projekt erstellt?

Unter Windows habe ich dieses Problem nicht.

Das "General" taucht bei mir nicht auf, ich kann aber in der Datei
plugin.xml gerade auch keinen Fehler finden.

Versuchst du bitte nochmal mit der neuen Datei hier im Anhang. Ich habe
alle "org.eclipse.cdt.gnuarm" mit "org.eclipse.cdt.arm" ersetzt. Das
Problem muss gelöst sein (hoffentlich :-) ).

Funktioniert =).

Wilfried, könntest du dann das Plug-in auch ins Netz stellen, damit alle
auch etwas davon profitieren?
Danke dir.

mfg

Ja kann ich machen, man könnte noch überlegen, das in das bestehende mit
einzubauen so wie es bei dem AVR-Plugin ist.

Wenn Du damit einverstanden bist würde ich das machen. Ich kann Dich
dann auch gern als Developer mit bei dem Sourcrforge-Projekt eintragen,
dann kannst Du auch Änderungen auch gleich ins SVN hochladen(?).

Danke, sehr nett von dir. Das mit dem SVN habe ich noch keine Ahnung was
das ist bzw. wie es funktioniert. Sich als Developer anzumelden will ich
jetzt deshalb noch nicht. Wie du mit dem neuen Plug-in machst, das
bleibt dir überlassen.

mfg

Ok, dann werde ich die beiden versionen zusammen setzen, dann kann ich
das über die Seite verwalten. Werde mich da am We mal ransetzen.
Wenn Du intresse bzgl. der direkten Mitarbeit hast sag bescheid.
Ansonsten pflege ich das weiterhin und nehme natürlich auch gern weiter
Vorschläge an. Ich erwähne logischerweise die Namen der Beteiligten.

Du setzt die Versionen zusammen und ich werde weiterhin Voschläge geben.
Eine Zusammenarbeit ist ein bisschen schwierig, denn zu Hause hab ich
noch keinen Internetanschluss :-).

Viele Grüße und schönes Wochenende,
Le Viet Bach

ok =)

So ich hab die Toolchain zum Bauen von "static library" mit in das
Plugin integriert, außerdem hab ich inzwischen support für "OS-X"
eingebaut. Das ganze ist dann als Version 0.1.0 zum download bereit.

Aufgrund eines kleinen Bugs gibts jetzt auch Version 0.1.1 ;).

Hi Wilfried!

Danke für das feine Plugin. Mir ist da noch ein Bug aufgefallen. Wenn
man unter einer Windowsumgebung ein Linker Scriptfile angibt, wird das
korrekt mit den \ im Pfad übernommen. Der Linker beschwert sich
hinterher allerdings, dass er das Scriptfile nicht findet. Problem:
sämtliche \ wurden intern aus dem Pfad entfernt. Als Workaround hilft
es, im eingegebenen Pfad alle \ durch / zu ersetzen. Wäre toll, wenns
trotzdem direkt funktionieren würde.

Hallo kann mir mal einer bitte erklären wie ich mit dem Plugin Richtig
Arbeite? Ich Arbeite zur Zeit mit Yagarto was genau erleichtert mir das
Plugin

danke im voraus

mgiaco

Wenn Du mit Eclipse arbeitest, erstellt das Plugin das Makefile.

Btw: Das Problem mit den "\", schau ich mir mal an.

hallo, ja arbeite mit Eclipse. Okay werde das mal probieren.

mfg mgiaco

@ Michael:

Welches Windows und welche Eclipse Version verwendest Du?

Hat jemand anders noch das Problem mit den "/"?

Hi Wilfried,

wir haben das Plugin gerade auf das vorhanden Eclipse 3.2 unter Windows
getan und es funktioniert auch "etwas".
Beim compilieren kommt allerdings die Fehlermeldung:
make -k all
'Building file: ../source/main.c'
'Invoking: GNU ARM C Compiler'
arm-elf-gcc -mcpu=arm7tdmi -O3 -gdwarf-2 -Wall -c -o"source/main.o"
"../source/main.c" && \
  echo -n 'source/main.d' source/ > 'source/main.d' && \
  arm-elf-gcc -MM -MG -P -w -mcpu=arm7tdmi -O3 -gdwarf-2 -Wall -c
"../source/main.c" >> 'source/main.d'
Das System kann den angegebenen Pfad nicht finden.
make: *** [source/main.o] Error 1
make: Target `all' not remade because of errors.

Die Vermutung ist, dass es an den Hochkommas (') liegt, die unter
Windows nicht richtig aussortiert werden. Vielleicht könntest Du Dich
des Problems annehmen? Wir müssen hier (im Fachbereich) "leider" mit
Windows arbeiten, da es kein Linux gibt...

Wo findet man die Sourcen? Ich habe bei Sourceforge nicht wirklichen
"Inhalt" finden können... (oder Besteht das nur aus dem plugin.xml?)

Schöne Grüße und vielen Dank für Deine Mühe,
Clemens Helfmeier

Hallo nochmal,

irgendwie hab ich jetzt ein anderes Problem:
Er kompiliert zwar (mit Hochkomata!) aber wenn er die HEx-Dateien
extrahieren soll, schafft er's nicht, weil er den Ausgabeparameter
(Dateinamen) doppelt auf der Kommandozeile hat.

Hat jemand eine Idee?
Grüße,
Clemens

Das Plugin besteht aus der JAR-Datei und alles wichtige steht in der
Plugin.xml. Du solltest ein als neues Plugin-Project dieses Plugin auch
importieren können, dann kannst Du das ganze besser editieren.

@ Clemens: Vielleicht hilft Dir meine FAQ unter Documentation auf der
Sourceforge Seite.

Servus,

ich gehe gerade meine ersten Schritte mit GNUARM(Eclipse).

Leider will meine simple Testdatei (Hello-World mittels printf) nicht
backen:



**** Build of configuration Release for project test03 ****

make -k all
Building file: ../test03.c
Invoking: GNU ARM C Compiler
arm-elf-gcc -mcpu=arm7tdmi -O0 -gdwarf-2 -Wall -c -o"test03.o"
"../test03.c" && \
echo -n 'test03.d' ./ > 'test03.d' && \
arm-elf-gcc -MM -MG -P -w -mcpu=arm7tdmi -O0 -gdwarf-2 -Wall -c
"../test03.c" >> 'test03.d'
Finished building: ../test03.c

Building target: test03.elf
Invoking: GNU ARM C Linker
arm-elf-ld  ./test03.o
-T/Users/chris/Documents/Development/ARM/ldscripts/AT91SAM7X256-ROM.ld
-nostdlib -static -Map=test03.map -o"test03.elf"
./test03.o: In function `main':
../test03.c:4: undefined reference to `puts'
make: *** [test03.elf] Error 1
make: Target `all' not remade because of errors.
Build complete for project test03


Ein simples arm-elf-gcc test03.c in der Konsole funktioniert jedoch. An
welcher Schraube muss ich noch drehen?

Gruß,
Christophe

Kannst Du mal bitte den Inhalt der Datei "test03.c" schicken, dann guck
ich mir das mal an.