mikrocontroller.net

Forum: Compiler & IDEs GNUARM Eclipse Plugin


Autor: Wilfried Holzke (ucontroller)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wilfried Holzke (ucontroller)
Datum:

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

Autor: Wilfried Holzke (Gast)
Datum:

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

Autor: Stefan (Gast)
Datum:

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

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wilfried Holzke (Gast)
Datum:

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

Autor: Fritz Praus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: nemesis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich werds mir mal anschauen und versuchen das Problem zu lösen.

Autor: Fritz Praus (fritzchen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Fritz Praus (fritzchen)
Datum:

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

Autor: Günther Schmidt (guenther)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
klar =)

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

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Günther Schmidt (guenther)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ö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

Autor: Wilfried Holzke (Gast)
Datum:

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

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wilfried Holzke (Gast)
Datum:

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

Autor: Karsten Brandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wilfried Holzke (Gast)
Datum:

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

Autor: Wilfried Holzke (Gast)
Datum:

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

Autor: Wilfried Holzke (Gast)
Datum:

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

Autor: Le Viet Bach (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wilfried Holzke (Gast)
Datum:

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

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 =).

Autor: Le Viet Bach (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Wilfried Holzke (Gast)
Datum:

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

Autor: Le Viet Bach (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Le Viet Bach (Gast)
Datum:

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

Ja.

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Funktioniert das Plugin jetzt auch unter Windows?

mfg danke

Autor: Le Viet Bach (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Le Viet Bach (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unter Windows funktioniert es einwandfrei.

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Super danke dann werde ich es gleich mal testen.

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

mfg danke

Autor: Le Viet Bach (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So viel ich weiss, es gibt noch keine Beschreibung dafür.

Schöne Grüße,
Le Viet Bach

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 =).

Autor: Le Viet Bach (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

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

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, ändere auch das mit dem Assembler =).

Autor: Le Viet Bach (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke, es funktioniert.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Le Viet Bach (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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 =).

Autor: Le Viet Bach (Gast)
Datum:
Angehängte Dateien:

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

mfg

Autor: Wilfried Holzke (Gast)
Datum:

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

Autor: Le Viet Bach (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:

...

Autor: Le Viet Bach (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, kannst du diese Version testen??

Autor: Le Viet Bach (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anscheinend fehlt das Flag -r hinter arm-elf-ar.

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, wenn ich das "-r" hinzufüge gehts.

Autor: Le Viet Bach (Gast)
Datum:

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

Unter Windows habe ich dieses Problem nicht.

Autor: Wilfried Holzke (Gast)
Datum:

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

Autor: Le Viet Bach (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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 :-) ).

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Funktioniert =).

Autor: Le Viet Bach (Gast)
Datum:

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

mfg

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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(?).

Autor: Le Viet Bach (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Le Viet Bach (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok =)

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aufgrund eines kleinen Bugs gibts jetzt auch Version 0.1.1 ;).

Autor: Michael Löffler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: mgiaco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du mit Eclipse arbeitest, erstellt das Plugin das Makefile.

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Btw: Das Problem mit den "\", schau ich mir mal an.

Autor: mgiaco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo, ja arbeite mit Eclipse. Okay werde das mal probieren.

mfg mgiaco

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Michael:

Welches Windows und welche Eclipse Version verwendest Du?

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

Autor: Clemens Helfmeier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Clemens Helfmeier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Clemens: Vielleicht hilft Dir meine FAQ unter Documentation auf der 
Sourceforge Seite.

Autor: Christophe Thil (chrisjt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wilfried Holzke (Gast)
Datum:

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

Autor: Christophe Thil (chrisjt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat sich erledigt. Mir war nicht bewusst, dass ich im Gegensatz zum 
AVR-Plugin noch manuell die Pfade zu den ARM-Libs eintragen und 
entsprechende -l-Flags setzen muss.

Gruß,
Christophe

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, ich werde das mal in meine FAQ aufnehmen.

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welche Libs hast Du eingetragen?

Autor: Christophe Thil (chrisjt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
libc, libgcc, libm.

Christophe

Autor: Martin Thomas (mthomas) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wäre wahrscheinlich geschickter, den Linker über das Compiler-Frontend 
(arm-*-gcc) aufzurufen. Dieses "weiss" wo libc libm etc. zu finden sind. 
So -nostdlib eine Standardeinstellung ist, kann das ebenfalls eine Hürde 
sein. Eher -nostartfiles als Standardeinstellung, startup-Code wird ja 
in aller Regel innerhalb des Projekts vorgegeben. Die default crt0.s 
"passt" meist nicht. -nostdlib kann man dann falls wirklich gewünscht 
später immer noch von Hand nachtragen, düfte aber eher selten 
erforderlich sein.

Autor: Michael Löffler (ml31415)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich hab mal auf Basis von deinem GNUARM Plugin angefangen, ein Plugin 
für Fujitsu 16bitter zu schreiben. Soweit lässt sich das meiste 1:1 
anpassen, von daher ist das Teil prinzipiell lauffähig. Einziger 
Wehrmutstropfen: Die Auswahl des genauen Controllers. Die möchte ich a) 
nicht alle in eine einzige dropdown Liste packen, sondern diese Listen 
anhand einer separaten Liste für die Prozessorfamilie erst deutlich 
verkleinern und b) nicht für Assembler, C Compiler und Linker jedesmal 
neu angeben. Diese Änderungen wären für das GNUARM Plugin  wohl auch der 
usability zuträglich, für die über 600 Fujitsu Chips aber auf jeden fall 
unerlässlich.

Ich hab nur leider keine Ahnung, wie ich das in diese XML Struktur 
packen kann. Wenn da jmd. ein gutes howto oder konkrete 
Lösungsvorschläge hat, wäre ich sehr dankbar.

Grüße,

Michael

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem mit der Auswahl der CPU konnte ich auch bisher nicht anders 
lösen und hab bisher auch kaum was an Dokumentation gefunden. Das 
einzige war folgendes: 
http://dev.eclipse.org/viewcvs/index.cgi/cdt-home/...

Mit dem aufruf der Programme über "arm-*-gcc" hatte ich beim 
Atmel-Plugin probleme, deshalb hab ich das hier so gelöst. Man kann das 
auch für jedes Projekt ändern, das wird dann gespeichert.

Ich hab zur Zeit leider keine Zeit mich mit ARM-uC zu beschäftigen, 
weshalb ich selber solche Probleme nicht unbedingt finde. Ich nehme aber 
gern Verbesserungen in das Plugin auf.

Autor: Niklas Borns (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Michael Löffler,
habe mit Begeisterung deinen Beitrag gelesen.
Ich dachte ich währe der einzige der sich mit Fujitsu 16-bittern
auseinandersetzt. Da Softune wirklich grottig ist, bin ich an deiner 
Portierung sehr interessiert. Probiere gerade selbst ein Plugin für CDT4 
und Eclipse 3.3 zu erstellen.

Gruß, Niklas

Autor: Michael Löffler (ml31415)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi Niklas,

freut mich, dass hier noch jemand mit den Teilen zu tun hat.

Soweit steht das Plugin jetzt eigentlich. Der produzierte Code macht 
allerdings nur teilweise das, was er soll. Sprich, irgendwo an den 
Compiler/Linker/Flash Einstellungen werd ich wohl noch etwas drehen 
müssen. Ich hab das unfertige Plugin mal angehängt. Mal sehn ob ich das 
heut noch endgültig zum Laufen bekomm.

Autor: Michael Löffler (ml31415)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab für das Fujitsu Plugin mal nen neuen Thread aufgemacht.

Beitrag "Eclipse Plugin für Fujitsu 16bit µcs"

Der letzte Fehler von heute Morgen ist ausgemerzt und das Ding tut 
soweit zuverlässig seinen Dienst. Das GNUARM Plugin werd ich mir auch 
nochmal kurz vornehmen, um einige der Punkte aus der FAQ abzustellen.

Autor: Christophe Thil (chrisjt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Servus,

gibt es eine Möglichkeit mit dem Plugin Dateien im Thumb-Mode zu 
kompileren/assemblieren? FreeRTOS mischt das (leider?) zusammen, und ich 
habe noch nicht herausgefunden wie man daraus ein schönes Managed 
Make-Projekt dengelt.

Grüße,
Christophe

Autor: Michael Löffler (ml31415)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Die Version hier fixt die Punkte 3, 4 und 6 aus der FAQ und reduziert 
den internen Overhead durch die Listen für die genaue mcu. Ansonsten hab 
ich noch ein paar Tooltips eingefügt, die z.B. die Sache mit den libs 
kurz erklären.


3. On the linker commandline the user defined libs are added before the 
input files. This results in missing external declaration. -fixed, die 
Reihenfolge ist jetzt per default passend eingestellt

4. If I do not select a section at the "ObjCopyFlash" command, it does 
not work. -fixed, die output-Datei wird nicht mehr doppelt angegeben.

6. While linking the project I got an error, because the backslashes 
("\") in the linker script path are gone. -fixed, der Pfadstring wird 
jetzt automatisch mit Anführungszeichen versehen

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke, ich werde mir das anschauen. Darf ich das mit in das SF.Net 
Projekt übernehmen?

Autor: Michael Löffler (ml31415)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klar.

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So habs die Plugin.xml übernommen und ins SVN hochgeladen sowie ein 
neues Release gemacht.

Autor: Thoralt Franz (thoralt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

erstmal DANKE für das Plugin! Ich hab's natürlich installiert und 
ausprobiert und mal eines unserer Projekte damit neu übersetzt. Viele 
kleine Fehler (meinerseits) habe ich mittlerweile beseitigt, dennoch 
bleibt eine letzte Sache, welche mir das Leben schwer macht: 
arm-elf-objcopy findet keine Eingabedatei. Hier mal die Ausgaben des 
Linkers und von arm-elf-objcopy:

Building target: iP.cardreaderGEN2-eclipse.elf
Invoking: GNU ARM C Linker
/opt/local/bin/arm-elf-ld  ./blockdev_sd.o ./console.o ./hid_int.o 
./lpc2000_spi.o ./main.o ./msc_bot.o ./msc_scsi.o ./printf.o ./startup.o 
./syscalls.o ./usbcontrol.o ./usbhw_lpc.o ./usbinit.o ./usbstdreq.o 
-o"iP.cardreaderGEN2-eclipse.elf" -T"../lpc2148-rom.ld" -nostartfiles 
-static -lgcc -lc -L/opt/local/arm-elf/lib 
-L/opt/local/lib/gcc/arm-elf/4.1.1 -Map=iP.cardreaderGEN2-eclipse.map
Finished building target: iP.cardreaderGEN2-eclipse.elf

Invoking: GNU ARM Object Copy Flash
/opt/local/bin/arm-elf-objcopy -O ihex iP.cardreaderGEN2-eclipse.elf 
"iP.cardreaderGEN2-eclipse.hex"
/opt/local/bin/arm-elf-objcopy: 'iP.cardreaderGEN2-eclipse.elf': No such 
file
/opt/local/bin/arm-elf-objcopy: error: the input file 
'iP.cardreaderGEN2-eclipse.elf' is empty
make: *** [iP.cardreaderGEN2-eclipse.hex] Error 1
make: Target `all' not remade because of errors.

Der Linker scheint ja alles soweit zu machen, wie er soll (wenn man den 
Ausgaben glaubt). Ich kann allerdings die Ausgabedatei (.elf) nirgends 
im Dateisystem finden. So ist natürlich auch klar, warum arm-elf-objcopy 
fehlschlägt. Kann mir vielleicht jemand einen Tip geben, warum der 
Linker keine .elf-Datei erstellt? (Mein System ist übrigens MacOS X 
(intel)).

Viele Grüße
Thoralt

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab leider kein Mac OS zur Hand wo ich das mal testen könnte...

Gibts das Verzeichnis "Release" oder "Debug"?
Evlt. mal "clean" ausführen.

Autor: Christophe Thil (chrisjt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, bei mir läuft das Plugin wunderbar und ohne Anpassungen unter OS X.

Christophe

Autor: Thoralt Franz (thoralt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Wilfried,

ja, "Release" exisitiert und dort sind auch alle objects abgelegt. Nach 
vielem Probieren habe ich herausgefunden, dass ich die Option 
"-nostartfiles"  für den Linker deaktivieren muss. Eigentlich ist mir 
das nicht recht, da ich ja mein eigenes Startfile (startup.s) 
geschrieben habe. Ob das Programm trotzdem funktioniert, kann ich leider 
erst morgen auf Arbeit ausprobieren (hab das JTAG-Board nicht hier zu 
hause).

Kann sich irgendjemand erklären, wieso das Weglassen von "-nostartfiles" 
zwingend nötig ist, um ein .elf zu erhalten?

Möglicherweise ist auch meine gcc-Installation vermurkst. Ich werde das 
morgen nochmal überprüfen und ein ganz einfaches Testprojekt einrichten.

Viele Grüße
Thoralt

Autor: Michael Löffler (ml31415)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oha, kann sein, dass sich das in der neuen Version mit reingeschlichen 
hat. Ich hab da etwas rumexperimentiert mit -nostdlib und -nostartfiles. 
Bei mir läuft die jetzige Defaulteinstellung gut, aber wenn das Ärger 
macht, sollten wirs besser wieder ändern.

Edit: Hab grad nachgeschaut. Das Plugin gibt für -nostartfiles keinen 
Defaultwert vor, CDT sollte daraus normalerweise false machen. Hast du 
die Option von Hand gesetzt? Wieso danach kein .elf erzeugt wird, kann 
ich dir aber auch nicht erklären.

Autor: Thoralt Franz (thoralt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

ich glaube, ich hab's jetzt!

Daß -nostartfiles keine .elf-Datei erzeugt, bleibt zwar ein Mysterium, 
aber ich habe mein Programm nun doch noch übersetzen können (es waren 
noch ein paar andere Inkompatibilitäten zu beseitigen).

"-nostartfiles" sollte ich für mein Projekt also nicht nutzen. Ich hatte 
fälschlicherweise angenommen, daß dies nötig ist und die 
default-Einstellung des Eclipse-Plugins geändert.

Danke für die Antworten und sorry, daß ich hier die Pferde scheu gemacht 
habe :)

Viele Grüße
Thoralt

Autor: Gerhard Lohmeyer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thoralt Franz,

bei mir wird auch kein elf File erzeugt, wenn die "-nostartfiles" Option 
eingeschaltet ist. Testweise habe ich in der Menüzeile "Command Line 
Pattern" manuell den Eintrag vorgenommen:
${COMMAND} -nostartfiles ${INPUTS}...

Wichtig scheint zu sein, an welcher Stelle -nostartfiles steht. Daher 
suche ich derzeit noch nach einer sauberen Lösung, die Position der 
Optionen in der Kommandozeile beeinflussen zu können.

In der Variante, die Du einsetzt, wird interessanterweise ein File 
namens "startfiles" anstelle des .elf Files angelegt. Es scheint so, als 
würde der Linker die Option falsch interpretieren.

Ein weiteres Problem habe ich mit dem Kompilieren von Assemblerfiles. 
Ich habe mein Assemblerfile mit der Endung .S (großgeschrieben) 
angelegt, da es so durch den Preprozessor des C-Compilers bearbeitet 
wird und z.B. c-Header Files verwendet werden können. In dem Plugin 
werden allerdings .s und .S Files gleich behandelt. Gibt es die 
Möglichkeit, neben C, CPP und ".s-Assembler" auch einen ".S-Assembler" 
Eintrag zu generieren?

Gruß
Gerhard

Autor: Michael Löffler (ml31415)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem müsste meiner Meinung nach irgendwo beim arm-elf-ld liegen. 
Ich hatte den default commandline pattern in der Version 0.1.2 von

${COMMAND} ${OUTPUT_FLAG}${OUTPUT} ${FLAGS} ${INPUTS}

wie es eigentlich gemäß Usage: arm-elf-ld [options] file... sein sollte 
auf

${COMMAND} ${INPUTS} ${OUTPUT_FLAG}${OUTPUT} ${FLAGS}

geändert. Mit der alten Zeile spuckt der Linker bei mir nur sinnlos 
Fehlermeldungen, so als ob er keinerlei Flags und Include-Pfade bekommen 
hätte. Wirklich separieren lässt sich die FLAGS-Variable nicht. Es wäre 
auch sinniger dafür zu sorgen, dass der Linker sich ordnungsgemäß seiner 
Syntax entsprechend verwenden ließe. Mit der neuen Zeile tut er 
zumindest weitgehend das, was man von ihm erwartet.

Zu der Assemblergeschichte:
Ein eigener Werkzeugeintrag dafür wäre schon machbar, aber vermutlich 
ziemlicher overkill. Gibt es für die Präprozessorverarbeitung nicht 
einfach irgendein flag, das man setzen kann?

Autor: Gerhard Lohmeyer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich werde mein Assemblerfile wieder als .s durch den Assembler schicken. 
Das ist im Endeffekt einfacher. Der Nutzen per Compiler zu assemblieren 
rechtfertigt den Aufwand nicht.

Autor: Gerhard Lohmeyer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zum Thema Dokumentation:

Hier kommt ein Link auf die aktuelle Versiondes der von Wilfried Holzke
am 22.05.2007 geposteten Dokumentation.

<http://www.eclipse.org/downloads/download.php?file...;

ZIP File öffnen und folgendes File entpacken:

eclipse/plugins/org.eclipse.cdt.doc.isv_3.1.2.200702150621.jar

im Verzeichnis: guide/mbs/extensibilityGuide
befindet sich das File: Managed_Build_Extensibility.html

in der Details zum Thema Managed Build zu finden sind.

Autor: Michael Löffler (ml31415)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: ch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo alle zusammen!

hab das plugin mit eclipse 3.3 und cdt 4.0 ausprobiert und es tut nicht 
wirklich richtig. und zwar liegt das problem bei der auswahl der 
toolchain, wenn ein neues projekt angelegt wird. die einträge sind 3 
fach vorhanden (3 mal executable, 3 mal lib wobei jeweils 2 einträge ein 
leere toolchain haben) und dort wo die toolchain ausgewählt wird, stehen 
die build configurations (debug und release). die konfiguration der 
toolchain (woher die dann letztendlich kommt weiss ich nicht) 
funktioniert aber!

ch

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist zur Zeit auch nur für Eclipse 3.2 geschrieben. Ich denke mal zur 
Version 3.3 hat sich einiges genändert, was bedeutet, das auch das 
Plugin angepaßt werden muss.

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mich interessiert mal, wer denn schon mit Eclipse 3.3/CDT 4.0 arbeitet 
oder wann ihr darauf umsteigt. Wenn Bedarf besteht, würde ich mich mal 
ransetzen und das ganze Plugin an CDT 4.0 anpassen.

Autor: ch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also dann fang ich mal an! Eclipse 3.3/CDT4.0 lauft bei mir schon. 
Leider ohne deinem Plugin :-((

Autor: Thoralt Franz (thoralt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich würde Dein Plugin auch gerne unter Eclipse 3.3 nutzen wollen!

Viele Grüße
Thoralt

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, dann werde ich mich da mal mit beschäftigen =).

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab mir das gerade mal angeschaut, scheint zumindest auf den ersten 
Blick nicht so viel geändert werden zu müssen. Denke mal das ich nächste 
Woche die erste Testversion veröffentlichen kann.

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, wie versprochen, hab ich gerade die Version 0.4 beta hochgeladen. 
Von der Menustruktur hab ich das dem CDT 4.0 angepaßt. Ich hoffe der 
Rest läuft wie bisher. Ich könnt ja mal berichten =).

Autor: wazzzup (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe dein Plugin ausprobiert und kann jetzt mit Erfolg meine 
ARM-Programme erstellen. Allerdings kann ich diese nur auf einem Target 
ausführen. Was muss ich machen, dass bei "RUN" das Programm direkt auf 
das Target kopiert wird und dort gestartet wird? Und wenn man auf 
"Debug" klickt automatisch das Programm auf das Target kopiert und mit 
dem gdbserver gestartet und somit im eclipse gedebuggt werden kann?


Habe für das autoamtische Debuggen das folgende Skript gefunden aber wo 
kann ich das einbinden?
shell ftp -u ftp://root:mypass@dil02/SSV/HelloWorld_01 \
~/SSV/HelloWorld_01/Debug/HelloWorld_01
shell ssh -t -l root dil02 chmod +x ./SSV/HelloWorld_01
shell ssh -t -l root dil02 ./SSV/gdbserver 192.168.0.121:2222 ./SSV/HelloWorld_01
file ~/SSV/HelloWorld_01/Debug/HelloWorld_01
shell sleep 2

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Diese Funktionen bietet das Plugin bisher nicht. Beim Atmel-uC hab ich 
mir unter Tools eine Funktion zum kopieren eingerichtet. Mit dem 
Debuggen hab ich mich auch noch nicht beschäftigt.

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nebenbei.. welche Version des Plugins benutzt Du, für CDT 3.1 oder 4.x?

Autor: Ferdl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
bin neu auf dem ARM sektor und nun auf Eclipse als Entwicklungsumgebung 
gestoßen. Muss aber dazu sagen, das ich seit langem in der 8-bit 
Fraktion unterwegs bin.

- Ich habe mir Eclipse IDE 3.3(c/c++) und CDT4.0 gezogen.
- CDT von der Platte in Eclipse installiert
- WinARM entpackt, abgelegt und den [Path] in die Windows 
Umgebungsvariable eingetragen 
"C:\Development\WinARM\bin;C:\Development\WinARM\utils\bin;"
- "gnuarm.0.4.0_beta.jar" in das plugin-Verzeichniss abgelegt
- neues ANSI C-Projekt "Hallo World" mit Toolchain "WINARM" gewählt

Nach dem build bekomm ich folgende Meldung: cannot find -lc

hier der Consolentext:

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

Building target: TestARM.elf
Invoking: C Linker
arm-elf-ld  ./src/TestARM.o    -o"TestARM.elf" -static -lc -lgcc 
-Map=TestARM.map
/cygdrive/c/programme/gnuarm/bin/arm-elf-ld: cannot find -lc
make: *** [TestARM.elf] Error 1
make: Target `all' not remade because of errors.

Was habe ich übersehen einzutragen/zu ändern?
Als Target will ich einen LPC2294 verwenden. Wie kann ich dieses device 
einbinden?

Vielen Dank
Ferdl

Autor: Timo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Möchte mich erstmal für das Plugin bedanken.
Ich habe nur ein kleines Problem:
Ich kann das Plugin von Sourceforge nicht downloaden.
Die geladene Datei ist immer leer, hat aber den richtigen Namen.
Ist da evtl. was auf der Page kaputt?

Gruß, Timo

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ferdl: Wenn ich das richtig verstehen fehlt der Pfad zur "c" library.

@Timo: Ich hab das gerade mal herunter geladen und es geht. Versuchs 
noch mal ggf. nimm einen anderen Mirror.

Autor: Timo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo nochmal,

danke für die schnelle Antwort!
Hat jetzt funktioniert, besten Dank!!
Dann kann ich ja jetzt mal testen...*freu*

Gruß, Timo

Autor: wazzzup (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Wilfried Holzke:
Das Debugging klappt so weit schon... nur muss ich jetzt noch manuell 
auf dem Target folgende Zeile schreiben: gdbserver host:1000 hello
und unter eclipse kann man als debug art den gdbserver mit der adresse 
vom target und der portnummer 1000 wählen. jetzt kann ich im eclipse auf 
debug klicken und es geht...

Die Frage ist nur: Wie kann ich das ganze automatisieren? Ich will (am 
liebsten) nur auf Debug klicken müssen und dann geht alles automatisch.

ausserdem habe ich noch ein anderes Problem: Mein programm hat mehrere 
Threads (multi-threading) und ich habe es bis jetzt nicht hingekriegt, 
das mein gdb mutli-threading programme vom target debuggen kann... ich 
werde es mal ausprobieren.

mfg

Autor: wazzzup (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Wilfried Holzke: Nebenbei... Ich benutze CDT 4.x und Eclipse 3.3 (am 
25.07.2007 zum ersten mal heruntergeladen) (kenne eclipse und CDT bisher 
noch nicht.)

Autor: Timo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich bin heute mal dazu gekommen, Eclipse mit dem ARM-GCC-Plugin 
auszuprobieren und habe leider noch ein Problem, welches ich nicht 
beseitigen kann.
Ich muss dazu sagen, dass ARM-Controller und C-Programmierung noch 
ziemliches Neuland für mich sind, hab da noch nicht den Durchblick.

Wenn ich ein Projekt kompilieren möchte, bricht er beim Linken ab.
Hier die Ausgabe:
**** Build of configuration Debug for project First ****

make -k all 
Building target: First.elf
Invoking: C Linker
arm-elf-linux-gnu-ld  ./crt.o ./main.o    -o"First.elf" -static -lc -lgcc -Map=First.map
arm-elf-linux-gnu-ld: cannot find -lgcc
make: *** [First.elf] Fehler 1
make: Das Target »all« wurde wegen Fehlern nicht aktualisiert.


Er kann scheibar mit dem Parametet "-lgcc" nix anfangen
Sagt das jemandem etwas?
Was habe ich da falsch gemacht?


Vielen Dank im Voraus,

Timo

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In den Einstellungen kannst Du den Parameter rausnehmen, musste ich bei 
mir bei einem Projekt auch machen. Dann gings.

Autor: Timo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Danke für den Tipp, war mir nicht sicher, ob die Option wichtig ist.
Jetzt kriege ich nur leider nicht raus, wie ich den Parameter in den 
Einstellungen rausnehmen kann.
In den Properties fürs aktuelle Projekt hab ich den gelöscht, aber 
Eclipse mukiert immer noch den Parameter.
Kann ich irgendwo das Plugin global dahingehend editieren, finde einfach 
nichts.
BTW, wenn ich das Projekt mit einem Makefile baue, fluppt alles.
Habe ich da evtl einen Denkfehler und muss immer ein Makefile-Projekt 
bauen??


Danke für eure Geduld,

Timo

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
in den Einstellungen: C linker -> Libraries -> c und gcc raus löschen
in dem Du die Einträge markierst und dann auf das kleine rote kreuz 
klickst.
So kann ich den obigen fehler bei mir beheben.

Autor: Timo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo nochmal.

Nu hab ich 's mal am Laufen ;-)
Nach nem Neustart lief alles, wie es sollte.
Bedankt.
Kann ich in irgend einem Menü die geänderten Einstellungen für das 
Plugin global machen?
Wär ja schon komfortabel.

Schönen Abend,

Timo

Autor: Sinx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jungs,

ich habe gerade vier Stunden lang versucht irgendwie das ganze 
Eclipse-Zeugs mit WANARM und einem Wiggler zum laufen zu bringen. Dazu 
habe ich mir alles mögliche heruntergeladen und mehrere Tutorials 
durchgemacht und nix will laufen. Ich hab ja sooo einen Hals.. ;((

Also zum gegenwärtigen Zeitpunkt (31.7.2007) kann ich keinem Bastler und 
besonders auch keinem professionellen Entwickler zu diesem 
Eclipse-Freeware-Hack raten. Die Installation und Einrichtung ist noch 
viel zu kompliziert. Ich würde das fast schon Eclipse-Hacking nennen!

Ich werde versuchen ein Download+Install+Play-Paket zusammen zu stellen, 
falls ich es irgendwann mal zum laufen bekommen sollte!

Sinx.

Autor: Timo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zwei letzte Fragen hätte ich noch:

Wie bekomme ich Eclipse dazu, die herausgenommenen Parameter -lc + -lgcc 
für den Linker wenigstens für das laufende Projekt zu speichern?
Ich gehe im akt. Projekt auf Properties-> c/c++ Build-> Settings und 
ändere es da, aber nach Neustart sind die Parameter wieder da...

Gibt es außerdem eine Möglichkeit, mit der Option -nostartfiles zu 
linken.
Wenn ich hier ein Häckchen setze, erstellt der Linker mir kein elf-File 
mehr...

Danke und Gute Nacht,

Timo

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Timo: Also die Einstellungen werden bei mir permanent gespeichert wenn 
ich in den Einstellungen auf "Apply" klicke.

Die Option "-notstartfiles" hat bei jemand anderes auch schon Probleme 
gemacht. Leider kann ich Dir da nicht weiter helfen. Was Du mal bitte 
testen könntest ist "nostartfiles" einzuschalten und dann die 
Kommandozeile wie sie von Eclipse ausgeführt wird, manuell zu starten 
und zu schauen ob das funktioniert, dann könnten wir mal weiter gucken, 
woran das wohl liegt. Also um zu schauen ob es am arm-gcc, ARM-Plugin, 
CDT oder Eclipse liegt.

@Sinx: Es gibt z.B. bereits YAGATO...

Autor: Timo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf "Apply" hab ich natürlich gedrückt.....
Muss ich mal sehen, was bei mir falsch ist.

Zum anderen Thema:
Hab ich mal so durchgeführt, hier mal der Auszug aus der Konsole:
timo@ubuntu2:~/workspace/4/Debug$ ls
4.map  main.d  makefile    sources.mk  subdir.mk
crt.o  main.o  objects.mk  startfiles
timo@ubuntu2:~/workspace/4/Debug$ arm-elf-linux-gnu-ld  ./crt.o ./main.o    -o"4.elf" -T"/home/timo/workspace/4/lpc2103_flash.cmd" -nostartfiles -nostdlib -static -Map=4.map
timo@ubuntu2:~/workspace/4/Debug$ ls
4.map  main.d  makefile    sources.mk  subdir.mk
crt.o  main.o  objects.mk  startfiles
timo@ubuntu2:~/workspace/4/Debug$ 

Es gibt also keine Fehlermeldung, die .elf-Datei wird aber tatsächlich 
nicht erstellt.

Hab gerade nochmal nachgeschaut, werden die Parameter -Nostartfiles und 
-nostdlibs nicht beim compilieren angehängt anstelle beim linken 
angefügt?

Grüße, Timo

Autor: Timo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:

Beim Gcc kann ich die Parameter unter Miscellaneous angeben, das funkt.

Übrigens speichert Eclipse schon meine Änderungen, bis auf das Löschen 
der verlinkten Libs, seltensam, aber kein Drama...

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Entschuldigt die fragen, aber ich bekomme das Plugin nicht ans laufen.
Nachdem ich die Files in das Plugin Verzeichnis kopiert habe, kann ich 
nicht den entsprechenden Projekt-Type auswählen.

Muss ich irgendwas beachten  eintragen  etc. Entsprechend benötigte 
Versionen werden von mir verwendet.

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guck mal unter "Help" -> "About Eclipse SDK" -> "Plugin-Details" ob das 
Plugin gefunden wurde.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter: Bei mir langs an einer alten Java Version. Installier mal die 
neuste (also falls das Plugin zu finden ist wie von Wilfried beschrieben 
und es immer noch net geht).

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wem sagt dieser Fehler etwas?
Bin vorgegangen wie in FAQ beschrieben (WinARM, eclipse, cdt, plugin).
**** Build of configuration Debug for project test ****

make -k all 
Building target: test.elf
Invoking: GNU ARM C Linker
arm-elf-ld  ./src/test.o    -o"test.elf" -static -lc -Map=test.map
d:\ARM\WinARM-20060606\WinARM\bin\arm-elf-ld.exe: warning: cannot find entry symbol _start; defaulting to 00008000
d:\arm\winarm-20060606\winarm\bin\../arm-elf/lib\libc.a(freer.o): In function `_malloc_trim_r':
mallocr.c:(.text+0x48): undefined reference to `_sbrk_r'
mallocr.c:(.text+0x64): undefined reference to `_sbrk_r'
usw...

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich habe mir das PlugIn ebenfalls heruntergeladen.
Die ersten Tests haben auch sehr vielversprechend (mit lauffähigem 
Programm am ARM) begonnen.

Jetzt habe ich allerdings ein Projekt, in dem eine *.s Datei dabei ist.
Das PlugIn verucht diese Datei aber als C-Datei zu übersetzen, und 
bemerkt dabei natürlich, dass es sich nicht um eine C Syntax handelt.

Kann man das irgendwie umgehen, oder irgendwie einstellen, dass diese 
Files keinen C-Code enthalten?


dake euch!

Autor: Icke Muster (Firma: my-solution) (hendi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit dem _start hat KEIL(mit GNUARM) bei mir immer gebracht, wenn ich 
die Startup Datei von Keil benutzt hab, glaub ich.

Autor: Icke Muster (Firma: my-solution) (hendi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, muss mich korrigieren, das mit dem _Start tritt mit einer Startup 
von Martin Thomas. Hat aber wohl definitiv etwas mit der startup zu tun, 
falls nicht möge man mich korrigieren.

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
????

Autor: Thoralt Franz (thoralt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

ich bin nun endlich auf Eclipse 3.3 umgestiegen und habe daher auch mal 
wieder das GNUARM Eclipse Plugin in der neuesten Version installiert. 
Ich bin begeistert - es mußten nur die Pfade für den Compiler angepaßt 
werden (ich arbeite am Mac), danach ließen sich alle Projekte wieder 
korrekt übersetzen.

Eine Frage habe ich allerdings (dies ist möglicherweise kein direktes 
Problem des Plugins, aber es ist mir hier das erste Mal aufgefallen): In 
meiner vorherigen Umgebung (Eclipse 3.2+CDT) wurde jedes Mal, wenn ich 
eine Quelltextdatei gespeichert habe, das Projekt neu übersetzt ("Build 
Automatically" aktiviert). Das war eine sehr bequeme Sache. In der neuen 
Version klappt das allerdings nicht mehr - ich muß "Build" explizit 
starten. Es macht keinen Unterschied, ob "Build Automatically" aktiviert 
ist oder nicht. Weiß jemand, wie man das wieder in den Griff bekommt?

Nochmals vielen Dank für die Arbeit an dem Plugin!

Viele Grüße
Thoralt

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, das muss man einstellen, das hab ich auch hin und wieder suchen 
müssen... moment ich schau mal...

Rechts Klick auf das Project... -> Properties -> C/C++ Build -> 
Karteikarte Behaviour -> haken bei "Build Resource on save (auto build)

Ich freue mich immer wieder das meine Arbeit auch anderen Hilft =).

Btw: Welche Pfade hast Du angepaßt?

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
btw: Wenn Ihr lust habt, könnt ihr das Projekt ja mal bei

  http://freshmeat.net/projects/gnuarmeclipse/

und/oder

  http://www.ohloh.net/projects/6996?p=GNUARM+Eclipse+Plugin

bewerten =).

Autor: Thoralt Franz (thoralt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wilfried Holzke wrote:
> Ja, das muss man einstellen, das hab ich auch hin und wieder suchen
> müssen... moment ich schau mal...
>
> Rechts Klick auf das Project... -> Properties -> C/C++ Build ->
> Karteikarte Behaviour -> haken bei "Build Resource on save (auto build)

Vielen vielen Dank! Ich hatte schon befürchtet, daß dieses Feature einem 
Bug in Eclipse zum Opfer gefallen ist :)

Kleine Ergänzung: Man muß als Target noch "all" eintragen, damit es 
funktioniert.

> Ich freue mich immer wieder das meine Arbeit auch anderen Hilft =).

Das tut sie!

> Btw: Welche Pfade hast Du angepaßt?

Für den Assembler, Compiler, Linker usw. sind per default keine Pfade, 
sondern nur die Programmnamen eingetragen. Meine arm-elf-Installation 
liegt in /usr/local/arm/bin/ und ist auf der Kommandozeile auch ohne 
Pfadangabe ausführbar (PATH ist entsprechend gesetzt). In Eclipse findet 
er aber Compiler & Co. nur, wenn ich den Pfad ergänze. Damit kann ich 
aber leben :)

Viele Grüße
Thoralt

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, wäre dann wohl auch eher eine Sache herauszufinden warum es aus der 
Eclipse-Umgebung nicht gefunden wird. Soweit ich das beurteilen kann ist 
es kein Problem des Plugins. Aber schon irgendwie komisch, bei mir 
liegen die Programme in "/usr/bin" (linux) und sind sowohl aus einem 
Terminal als auch aus Eclipse erreichbar.

Aber Du hast ja eine Lösung von daher, mach ich mir da erstmal keine 
Kopf drum... =)

Autor: wildcard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi danke für das Plugin,
habe es heute mal mit der neusten Version von Yagarto ausprobiert. 
Leider möchte er die Einstellungen für das objcopy nicht übernehmen. Es 
ist mit mit der Beta Version nicht möglich das Ausgabe Format auf 
"binary" umzustellen, auch kann ich den "experten"-Übergabestring zwar 
ändern, aber gespeichert wird er leider dann nicht. (so wollte ich mir 
das bin file selbst erstellen)

Desweiteren läßt sich das Projekt nach Änderungen an dieser Stelle nicht 
mehr kompilieren - möchte plötzlich meine .c Datei als .d Datei 
kompilieren und das schlägt dann fehl.

Wäre schön, wenn diese Dinge noch behoben werden könnten, aber soweit 
genau das was ich gesucht habe (nutze bisher Devcpp, um keine Makefiles 
selber schreiben zu müssen, bin vom IAR zu verwöhnt)

Danke!
Tobi

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Ich schau mir das mal an... =)

Autor: wildcard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Super, Danke!

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin leider zur Zeit beruflich gut ausgebucht, somit bitte ich um 
etwas Geduld. Ich hoffe ich schaff das im laufe der nächsten Woche.

Autor: wildcard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okey ist ja kein Problem, machst es ja schließlich freiwillig. Wenn du 
Zeit findest, schreibst einfach hier rein.

Gruss

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, ich hab mir das gerade mal angeschaut, ich kann bei mir bei 
"objCopyFlash" auf Binary umstellen und gespeichert wird es auch.
Welche Version von Eclipse verwendest Du?

Ich hab Eclipse 3.3.1 unter Linux und CDT 4.0.1.

Kannst Du bitte einen Bugreport auf der SF.net-Project Seite Schreiben, 
ich will mal versuchen noch ein paar Leute zu finden die an dem Projekt 
mit entwickeln, damit Fehler schneller behoben werden können.

Autor: Thoralt Franz (thoralt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

ich bin gerade einem geradezu unglaublichen Problem auf der Spur.

Ganz kurz die Zusammenfassung: Sobald ein Quelltext-Dateiname mit einem 
großen "A" beginnt, ist mein Projekt nicht mehr lauffähig.

Die Details: Ich habe jetzt mehrfach das Problem gehabt, daß das 
erzeugte Programm sich schon ganz am Anfang aufhängt, wenn das Projekt 
eine Datei enthält, die z. B. "ADC.c" oder "AES.c" heißt. Außerdem muß 
die Datei mindestens eine Funktion enthalten (die muß aber nicht 
aufgerufen werden, damit das Problem auftritt). Es dürfen Variablen und 
auch const-Arrays enthalten sein, ohne daß es Probleme gibt. Wenn ich 
die Datei umbenenne (z. B. "xAES.c"), dann funktioniert alles wie 
erwartet. Sobald ich den Name wiederherstelle (inkl. make clean), bleibt 
der Controller im Init hängen.

Ich weiß, daß dies möglicherweise kein Problem von gnuarmeclipse ist, 
aber ich habe trotz intensiver Google-Suche nichts gefunden, was 
irgendwie auf diesen Sachverhalt paßt (nebenbei bemerkt, ist es 
schwierig, überhaupt eine Suchanfrage dafür zu erstellen).

Kann das irgendjemand nachvollziehen? Wo könnte ich dazu Hilfe bekommen?

Übrigens: Eclipse 3.3, gcc 4.1.0, MacOS und Windows.

Viele Grüße
Thoralt

Autor: Thoralt Franz (thoralt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch ein Nachtrag:

Ich konnte das Problem zumindest soweit eingrenzen: Sobald eine Datei im 
Alphabet vor meiner "CStartup.c" und "CStartup.s" liegt, startet der 
Controller nicht mehr. Wieso hat die alphabetische Reihenfolge etwas mit 
der Ausführbarkeit zu tun?

Ratlos,
Thoralt

Autor: franzi f. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo an alle.

Habe gestern das Plugin installiert, um damit ein bischen 
rumzuprobieren.
Dabei ist mir aufgefallen, daß in einem C-Projekt bei den Tool-Settings 
der C-Compiler verfügbar ist (was ja auch normal ist).
Bei einem C++ Projekt ist hingegen der C++ Compiler verfügbar (auch 
normal), der C-Compiler aber NICHT!
In meinem C++ Projekt gibt es aber C++ und C-Files?

Mach ich da was falsch?

Mfg
  Franzi

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist beim Plugin bisher so eingestellt, wenns Probleme gibt, muss ich 
den C-Compiler für C++ Projecte noch eintragen.

Autor: franzi f. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wäre spitze wenn das machbar wäre!

Mfg
  Franzi

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So ich hab das jetzt mal eingebaut, ich hoffe es funktioniert auch bei 
Dir. Ist zur Zeit nur in der Version 0.4.3_beta also für CDT 4.0.

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
btw: Das mit der Reihenfolge der Dateien konnte ich noch nicht testen.

Autor: Tilo L. (katagia)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Ich habe bisher das Plugin nur für die Erstellung des Projekt verwendet. 
Zum Compilieren habe ich bisher eine eigene Makefile verwendet. Darauf 
will ich nun verzichten und ich habe mir das Plugin genauer angesehen. 
Dabei haben sie ein paar Fragen ergeben:

Ich verwende 2 Startup-Codes. Der 2. Code dient zum debuggen, bei ihm 
soll das Programm nicht von selbst starten. Der Reset-Handler an Adresse 
0x00 springt in diesem Fall immer auf sich selbst in eine 
Endlosschleife.

Im Release-Code wird statt dessen der richtige Reset-Handler aufgerufen.
Das ganze wurde deshalb nötig, da sonst das Programm direkt gestartet 
wird und es dann über JTAG schon öfters passiert ist, dass sich der uC 
nicht mehr fangen lässt. (Crossworks macht es genau so).

Ich weiß nicht, wie ich das ganze umsetzen soll. Wenn ich das Plugin 
richtig verstanden habe, wird der Assembler Code alphabetisch an den 
Anfang gelegt. aaa.s kommt dann vor bbb.s.



Als nächstes habe ich 2 unterschiedliche Linkerskripte, je nach dem, ob 
das Programm im Ram oder Flash laufen soll. Ich würde hierfür auch gerne 
eine Auswahlmöglichkeit haben.




Ich habe kurz in das Plugin reingesehen. Ich denke meine 
Programmierkenntnisse reichen aus, die zusätzlichen Menüpunkte 
aufzunehmen. Als erstes würde ich unter Target eine Option "Model" 
einfügen, bei dann der entsprechende uC ausgewählt werden kann. Nach der 
Auswahl des Model sollen die Auswahldialoge für den Startupcode und 
Linkerskript erscheinen.


Lange Vorgeschichte, jetzt die Fragen:

Das Plugin muss den Pfad zu Startup-Codes, Linkerskripte usw. kennen. Wo 
kopiere ich die Dateien am geschicktesten hin?

Wie kann ich ich die 2 neuen Menüpunkte einblenden, wenn das 
entsprechende uC-Modell ausgewählt wird?

Wo können Defaultwerte gesetzt werden, damit diese bei einem neuem 
Projekt verwendet werden?


Vielen Dank,

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Das Plugin muss den Pfad zu Startup-Codes, Linkerskripte usw. kennen. Wo
>>kopiere ich die Dateien am geschicktesten hin?

In ein Unterverzeichnis des Projektes?

>>Wie kann ich ich die 2 neuen Menüpunkte einblenden, wenn das
>>entsprechende uC-Modell ausgewählt wird?

Das kann ich Dir auch nicht sagen wie das geht. Ich hab auf der SF.Net 
Seite im Wiki ein paar links gesammelt, vielleicht findest Du da was.

>>Wo können Defaultwerte gesetzt werden, damit diese bei einem neuem
>>Projekt verwendet werden?

Es gibt die Debug und Release Konfigurationen und dort werden je nach 
Konfiguration Werte gesetzt. Das sollte erklären wie es geht.

Autor: Tilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mir überlegt, dei Dateien nicht zum Projekt sondern beim 
Compiler beizulegen ... beides hat seine Vor- und Nachteile.

Ich hab das meiste hinbekommen, auch debuggen im Flash geht. Ich bin 
gerade dabei, eine kleine Einführung zu Eclipse mit einem ADUC7000 zu 
schreiben. So bald etwas brauchbares vorhanden ist, werde ich es 
veröffentlichen.

Ein Problem bleibt. Soll Code im Flash debuggt werden, darf der MCU 
nicht von selbst loslaufen. Es kann sonst, vor allem bei aktiven IRQs, 
dazu kommen, dass der uC über JTAG nicht angesprochen werden kann. Ich 
verwende für diesen Fall einen 2. Startupcode, bei dem der Reset-Handler 
(Adresse 0x0) sich selbst aufruft. Der richtige Startupcode sird dann 
von Hand an 0xd3 ausgeführt.

Wenn ich das Plugin richtig verstanden habe, wird die Ambler-Datei 
welche alphabetisch zu erst kommt, an Adresse 0x0 abgelegt. Wie kann ich 
die erste Datei von Hand festlegen?

Vielen Dank,

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gute Frage, ich denke da muss man noch mal genauer beim CDT-Plugin 
gucken wie man sowas einstellen kann. Ich vermute die Dateien werden 
einfach alphabetisch sortiert an den Linker übergeben.

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei der Linker Kommandozeile könnte man noch mal gucken ob das ein 
spezieller Befehl benutzt wird.

Autor: Tilo L. (katagia)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe keinen Befehl gefunden.

Der Linker linkt einfach alphabetisch. In meinem Fall hieß der Startup 
Code crt.s und eine andere Datei aduc.c. Das führte dazu, dass aduc bei 
0x0 anfing und der Code nicht mehr lief.

Ich habe das ganze dann so gelöst, dass ich im Linker-Skript eine eigene 
Section definierte, die ganz am Anfang liegt. Die selbe Section habe ich 
im Startup-Code verwendet. Das ganze sah dann so aus (Auszüge):

(crt.s) [...]
section .startup
.global  Reset_Handler
.global _vec_reset
.func _vec_reset

_vec_reset:

# Exception Vectors
_vectors:       b _vectors
                ldr     PC, Undef_Addr
                ldr     PC, SWI_Addr
[...]

und im Linker-Skript:

[...]
SECTIONS
{
  . = 0;                /* set location counter to address zero  */
  .text :                /* collect all sections that should go into 
FLASH after startup  */
  {
    *(.startup)          /* Startup Section must be placed at 0x0 */
    *(.text)            /* all .text sections (code)  */
    *(.rodata)            /* all .rodata sections (constants, strings, 
etc.)  */
    *(.rodata*)            /* all .rodata* sections (constants, strings, 
etc.)  */
    *(.glue_7)            /* all .glue_7 sections  (no idea what these 
are) */
    *(.glue_7t)            /* all .glue_7t sections (no idea what these 
are) */
    _etext = .;            /* define a global symbol _etext just after 
the last code byte */
  } >flash              /* put all the above into FLASH */
[...]


Mann muss sich eben nur zu helfen wissen );


Alles in allem benutze ich dein Plugin gerne. Ich finde es erleichtert 
gerade Anfängern die Einarbeitung deutlich.

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Freut mich das Du eine Lösung gefunden hast, ich werde das mal in die 
FAQ aufnehmen.

Wie bereits erwähnt pflege ich das ganze zur Zeit nur, aber die nächsten 
30 Euro werden auf jeden Fall in ein ARM-Board investiert, dann kann ich 
auch wieder aktiver an dem Plugin entwickeln, weil ich dann die Fehler 
auch besser nachvollziehen kann.

Autor: muor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe gerade versucht das Plugin mit Eclipse 3.4.1 zu nutzen.
Leider befindet sich unter New->Project usw. wenn ich C-Project auswähle 
unter Project Type und da Executable kein Eintrag für ARM.
Ich habe alles so installiert wie in der Hilfe angegeben. Weiß jemand 
woran das leigen könnte?

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welches Plugin hast Du runtergeladen?
Welches CDT verwendest Du?
Welches OS (Windows, Linux, MacOS) verwendest Du?
Wird das Plugin auch erkannt?

Autor: muor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pluginversion ist 0.5.0
CDT ist die aktuellste Version, also 5.1
ich benutzte Windows
wie kann ich erkennen ob das Plugin erkannt wurde? Wenn ich unter Help 
schaue welche Plugins alle vorhanden sind, dann wird es angezeigt.

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Komisch, dann müsste es laufen, ich werde das mal unter Windows testen, 
habs bisher nur unter Linux ausprobiert, da es sonst auch immer 
problemlos unter den andren OS lief.

Autor: muor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
ok scheint doch zu funktionieren, habe nochmal alles neu installiert.
Danke trotzdem für die Mühe!

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok =).

Autor: clonePhone82 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie kann man *.s Dateien kompilieren bei Managed Projects ?
Ich habe das Problem das mein crt.s nicht kompiliert wird.

thx

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welche Pluginversion benutzt Du?

Autor: clonePhone82 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Wilfried,

Es hat doch geklappt habe es weiter oben im Beitrag gefunden.
Bei Managed C Projects kann man nicht für jedes c File angeben wie es 
kompiliert wird, oder ?
Ich möchte einige in ARM Mode und andere in Thumb Mode kompilieren, geht 
das irgendwie ?

thanks

Autor: clonePhone82 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also in dem Fall geht es nicht oder :-)

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zur Zeit kann man nur die Einstellung für alle Dateien machen. Aber 
Verbesserungsvorschläge sind immer willkommen. Bitte schreib das mal auf 
der Sourceforge Seite als Feature Request, da ich die aktuelle Version 
nicht entwickle.

Autor: 900ss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich möchte einige in ARM Mode und andere in Thumb Mode kompilieren, geht
> das irgendwie ?

Das geht doch. Du mußt einen rechten Mausklick auf die Datei links im 
Projektbaum machen und Properties im Kontextmenu auswählen. Dort kannst 
du die Settings für diese eine Datei einstellen. Das sollte gehen. Hab 
ich gerade nicht probiert, ist aber eigentlich "Standard" in Eclipse.

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man lernt nie aus ;)... ich habs gerade mal geschaut und ja man kann für 
einzelne Dateien separate Einstellungen machen.

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und was muss man dann einstellen um thumb zu kompilieren ?

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rechts klick auf die Datei -> properties -> C(++) build -> settings -> 
Target -> generate 16 Bit thumb code

hth =)

Autor: jaipur24@gmx.de (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo zusammen,

ich habe erst vor kurzen diesem beitrag entdeckt und musste gleich mal 
eclipse und das gnuarm plugin ausprobieren. wie auf der sourceforge 
beschrieben habe ich mir ein tool nach dem anderen installiert.

ein neues projekt erstellt, eine datei main.c erstellt und das projekt 
erstellt, prompt kommen die ersten fehler:

Description  Resource  Path  Location  Type
ERROR: ./main.o uses FPA instructions, whereas GnuArm1.elf does not 
GnuArm1    line 0  C/C++ Problem
failed to merge target specific data of file ./main.o  GnuArm1    line 0 
C/C++ Problem
make: *** [GnuArm1.elf] Error 1  GnuArm1    line 0  C/C++ Problem
undefined reference to `__libc_fini_array'  GnuArm1    line 320, 
external location: 
C:\msys\1.0\home\yagarto\newlib-1.17.0\libgloss\arm\crt0.S  C/C++ 
Problem
undefined reference to `__libc_init_array'  GnuArm1    line 314, 
external location: 
C:\msys\1.0\home\yagarto\newlib-1.17.0\libgloss\arm\crt0.S  C/C++ 
Problem
undefined reference to `atexit'  GnuArm1    line 313, external location: 
C:\msys\1.0\home\yagarto\newlib-1.17.0\libgloss\arm\crt0.S  C/C++ 
Problem
undefined reference to `exit'  GnuArm1    line 320, external location: 
C:\msys\1.0\home\yagarto\newlib-1.17.0\libgloss\arm\crt0.S  C/C++ 
Problem
undefined reference to `memset'  GnuArm1    line 161, external location: 
C:\msys\1.0\home\yagarto\newlib-1.17.0\libgloss\arm\crt0.S  C/C++ 
Problem


allerdings kann in mit diesen meldungen nichts anfangen und mich 
verwirrt auch die pfadangabe c:\mysys\... diesen ordner gibt es auf 
meinem system nicht :(

Autor: Tilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Was für einen Sichpfad verwendest du?
Ich setze im Plugin den Library search path unter C Linker -> Libraries 
auf "C:\Programme\yagarto\lib\gcc\arm-elf\4.2.2"

Hast du den Compiler selbst übersetzt? Vermutlich sind die dir 
unbekannten Pfadangaben die Defaultwerte.

Benutzt du Befehle wie printf oder dynamische Speicherverwaltung? In 
diesem Fall wird die Standardlibrary nicht gefunden.

Autor: jaipur24@gmx.de (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,

betriebssystem: windows xp sp3, alles andere habe ich mir gestern abend 
von den entsprechende seiten herunter geladen als exe bzw install 
dateien. nichts selber kompiliert...

das einzige was ich geändert habe war der prozesser typ, damit ich sehen 
konnte ab den zumindest alles so aussieht wie beschrieben.

mein testprogramm:
void main()
{
}

seltsamer weise fing eclipse auch schon bei folgendem an zu meckern:
# include <stdlib.h>
# include <stdio.h>

meldung: "unresolved inclusion"


> "Ich setze im Plugin den Library search path"

was denn das? wo ist (war) das denn beschrieben? muss ich jetzt alle 
pfadangaben von hand eingeben?

Autor: Tilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du schonmal mit dem gcc etwas übersetzt? Das Plugin ist quasi ein 
ersatz für die Makefile, in der sonst alle Angaben drin sind. stdio und 
stdlib sind kein festes Bestandteil.

Da du uns nicht verrätst, was du alles wie installiert hast, was für 
eine cpu programmiert werden soll usw. wird dir niemand helfen können. 
Ließ dir am besten das ARM Tutorial von Lynch durch, da ist vieles 
erklärt. Wenn du danach noch Fragen hast, stell sie in diesem Forum 
(Wenn möglich in einem neuem Thread da es mit dem Plugin nichts direkt 
zu tun hat)

Viele Grüße, Tilo

Autor: Tilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Ich glaube ich habe einen kleinen Bug im Skript gefunden. Ich schreibe 
gerade mit dem Plugin code für einen arm7tdmi. In einem 
Projektunterordner liegt C-Code, der mit anderen Optionen übersetzt 
werden soll. Man kann diese mit dem Plugin wunderbar einstellen. Leider 
taucht in dem erzeugten Compileraufruf "-mthumb", obwohl das nirgends 
definiert ist.
Damit läuft mein Code leider nicht.

Autor: bine (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> rechts klick auf die Datei -> properties -> C(++) build -> settings ->
>> Target -> generate 16 Bit thumb code
>> hth =)

Bei CDT 6.0 geht das aber nicht, oder? Ich finds nicht.

lg

Autor: Tilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das geht schon. Wenn man auf den Projektorder rechtklick und properties 
wählt. Damit nimmt man Einstellungen für das ganze Projekt vor. Wählt 
man bei einem Unterordner properties, fehlt eine Option, mit der man 
thumb einstellen kann, -mthumb ist bei mir immer gesetzt.

Autor: bine (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Wählt man bei einem Unterordner properties, fehlt eine Option, mit der man
>> thumb einstellen kann, -mthumb ist bei mir immer gesetzt.

Ja eben also geht es ja nicht.

lg

Autor: Karsten Brandt (karstenbrandt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo @all

ich habe in diesem Forum (und nicht nur hier) ein wenig gelesen, um mit 
Eclipse und Gnu-arm (oder auch Gnu-AVR bzw. Gnu-MSP) zurechzukommen. Ich 
habe dasselbe Problem wie
jaipur24@gmx.de (und vermutlich jeder Anfänger). Das ist eine sehr 
komplexe und zeitraubende Materie. Bis man sein erstes Programm mit dem 
Pulgin von Wilfried Holzke vergeht viel Zeit. Ich arbeite nun schon 3 
Tage daran, ein einfaches
int main(void)
{
   return 0;
}
zum Laufen zu bringen. Das Tutorial von Jim Lynch ist von 2005. Eclipse 
hat sich seit dem weiterentwickelt. Ausserdem benutzt Jim Lynch die 
Zylin CDT und nicht die CDT von Eclipse direkt. Ob das alles kompatibel 
zueinander ist, kann ich nicht beurteilen. Die vielen Varianten sind für 
einen Anfänger sehr verwirrend.
Aus diesem Grunde habe ich einen neuen Beitrag unter
Beitrag "GCC-Toolchain mit IDE installieren" ins Leben gerufen

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, wenn Du ein fertiges Tutorial hast, würde ich mich freuen wenn Du es 
mir zu schickst, das würde dann anderen Deine Probleme ersparen. Wenn Du 
konkrete Probleme hast frag... =)

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Wilfried,

Karsten (er möchte eine Anleitung zu dem Plugin schreiben) hat scheinbar 
ein Bug in dem Plugin gefunden. Wenn Du Zeit und Lust hast, dann sieh 
dir das doch mal an.

Beitrag "Eclipse-Problem beim Dateiausschluss"

Danke.

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bugs bitte auf der Sourceforge.net Seite im Bugtracker eintragen... Den 
Post werde ich mir mal durchlesen...

Autor: Le_Q (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zunächst einmal VIELEN DANK für dieses tolle Plugin! :)

Ich habe allerdings ein Problem, das Plugin erwartet den GCC unter einem 
"falschen" Pfad (/usr/bin/sh). Ich verwende Windows und möchte gerne 
alle Tools im Ordner C:/WinARM/ halten. Wo kann ich den Pfad zum GCC 
einstellen?

Danke fuer jede Antwort!

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zur Zeit für jedes Tool selber.... Unter den Projekt Eigenschaften kann 
man für gcc, linker usw. Optionen einstellen, da kann man auch die Pfade 
ändern. Ggf. frag mal im Sourceforge.net forum, da ich zur Zeit das 
Projekt nicht betreue, kann sich da auch schon was geändert haben.

Hth.

Autor: Heiko Seidel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bisher dreht sich die Programmierung ja nur um Applikationen, die direkt 
auf einem ARM läufen.
Sind mit dem Plugin auch Programme möglich, die in einem Linux 
ausgeführt werden können, das auf einem ARM9 läuft?
Wenn ich eine erstellte Applikation in einem embedded Linux ausführe, 
kommt immer die Meldung "Segmentation fault". Ich nehme an, dass das 
Programm in eineme vom OS belegten Speicherbereich ausgeführt werden 
will.

Grüße!

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wollte heute Helios + AVR Eclipse 2.3.3 ausprobieren.

Installation des Plugins über die Plugin-Site bringt den/die Fehler:

>Cannot complete the install because one or more required items could
>not be found.
>Software being installed: AVR Eclipse Plugin 2.3.3.20100701PRD
>(de.innot.avreclipse.feature.group 2.3.3.20100701PRD)
>Missing requirement: AVR Eclipse Plugin 2.3.3.20100701PRD
>(de.innot.avreclipse.feature.group 2.3.3.20100701PRD) requires
>'de.innot.avreclipse.core [2.3.3.20100701PRD]' but it could not be found

Beim Versuch einer manuellen Installation des Plugins taucht beim 
erstellen eines neuen C-Projekts die Auswahl "AVR Cross Target 
Application" nichtmal auf ...

Hat jmd ne idee was ich falsch mache ?

Habs versucht unter Windows7...

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry für den Doppelpost, WinAVR-20100110 ist installiert ...

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eben mal mit Galileo probiert. Geht auch nicht (CDT Plugin ist 
installiert)...

Autor: Augen auf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du bist hier im GNUARM Thread. Hat nix mit WinAVR zu tun.
Da es bei dir grundsätzlich nicht geht machst etwas falsch. Bei mir 
läuft das GNUARM Plugin mit Galileo und unter Helios und das AVR-Plugin 
ebenfalls unter Galileo und Helios.
Beide Plugins mit den zugehörigrn Toolchains unter beiden 
Eclipse-Versionen einwandfrei.

Autor: Augen auf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja, die CDT mußt du nicht extra installieren. Du kannst dir das 
Eclipse mit eingebauter CDT runterladen und installieren. Ich hatte auch 
in der Vergangenheit mal Probleme mit Eclipse, wo ich die CDT extra 
installieren mußte. Danach hab ich dann das Eclipsepaket mit eingebauter 
CDT verwendet und alles wurde gut :-)

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Problem gelöst, vielen Dank für den Tip ... Eclipse mit bereits
integriertem CDT hat das Problem gelöst :-)
Sorry für die falsche Thread-Wahl, bin über die Suche draufgekommen
und hab gleich mit dem tippen losgelegt ...

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich hätte mal eine dumme Frage. Wie muss ich das Plugin konfigurieren 
für die Codesourcery toolchain wie muss ich das Verzeichnis der 
toolchain angeben?

Autor: 900ss D. (900ss)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Du mußt die Codesourcery Toolchain installieren, der Pfad zu den 
Binaries (z.B. Pfad zu arm-none-eabi-gcc.exe) muß bei dir im Systempfad 
stehen.

Wenn du danach Eclipse und ein neues C-Project anlegst, dann wählst du 
Project Type "ARM Cross Target Application". Unter Toolchains steht dann 
unter anderem "ARM Windows GCC (Sourcery G++ Lite). Siehe Scrrenshot im 
Anhang. Danach mußt du für die Toolchain eigentlich nichts spezielles 
mehr einstellen. Nur die projektspezifischen Einstellungen unter 
"Project->Properties->C/C++ Build->Settings" für Compiler/Linker u.s.w. 
mußt du vornehmen.

Autor: Fabian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo allerseits,
ich möchte nochmal eine frage aufgreifen die hier schon mal gestellt 
wurde aber bis jetzt nicht beantwortet.
ist es möglich mit eclipse für einen arm9 software zu compiliern die in 
einem, auf dem arm laufenden embedded linux, lauffähig ist?

fals nicht würde ich mich freuen wenn einer der profis unter euch einen 
tip hätte wie das am einfachsten zu machen wäre.

vielen dank im voraus

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Hier hab ich z.B. ein Howto gefunden, hab aber nur kurz einen Blick 
reingeworfen...

http://www.ailis.de/~k/archives/19-ARM-cross-compi...

Die Compiler-Befehle und Angaben für die Bibliotheken musst Du 
eigentlich nur in Eclipse entsprechend angeben und dann solltest Du ein 
Programm im elf-Format erhalten welches unter ARM-Linux laufen sollte.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hab ein Problem mit dem Plugin.

Ich habe hier ein Projekt, wo ich die Einstellungen unter
Project.Properties.C/C++Build.Settings.ToolSettings.AdditionalTools

für "Create Extended Listing" für "Debug" markiert und für "Release" 
abgeschaltet habe. Aber für Debug generiert er mir kein Listing. Wenn 
ich es in Release einschalte, macht er es dort. Ich habe schon ein paar 
Konfigurationen probiert, für Debug willl er kein Listing mehr 
generieren. Er hat es aber schon mal gemacht. Der Makefile der für Debug 
generiert wird, enthält die Anweisung für das Listing nicht. Die 
Release-Version schon.
Wilfried hast du eine Ahnung, was das ist?

Eine Unschönheit habe ich auch noch entdeckt. Für die Einstellungen beim 
Assembler und Compiler findet man unter Miscellaneous in "Assembler 
Listing" die Optionen zum generieren des Assemblerlisting vom Assembler 
oder Compiler ("-adhlns="$@.lst"). Das ist unschön (per default). 
Schöner wäre auch hier eine Option EIN/AUS. Beim Clean werden die 
generierten Assembler Listings auch nicht gelöscht.

Danke für Tips

900ss

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich kann leider nichts dazu sagen, ich hab zur Zeit leider kaum Zeit 
mich mit der Entwicklung zu beschäftigen. Glücklicherweise gibt es aber 
jemand der weiter daran arbeitet und auch das Forum betreut; allerdings 
nur auf der Sourceforge Seite. Für weitere Hilfe stelle Deine Fragen 
bitte im Projekt-Forum.

Grüße und einen guten Rutsch

  Wilfried

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.