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
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.
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.
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.
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
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 :-)
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
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?
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.
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.
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: ...
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 :-) ).
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
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.
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
@ 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.
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
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.
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
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/user/Reference%20Documents/Managed_Build/Managed_Build_Extensibility.html?root=Tools_Project&view=co#_TocSection1 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.
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
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.
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.
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
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
Danke, ich werde mir das anschauen. Darf ich das mit in das SF.Net Projekt übernehmen?
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
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.
Hm, bei mir läuft das Plugin wunderbar und ohne Anpassungen unter OS X. Christophe
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
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.
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
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
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?
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.
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=/tools/cdt/releases/callisto/dist/3.1.2/org.eclipse.cdt.sdk-3.1.2-win32.x86.zip> 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.
Das steht auch direkt im Netz: http://dev.eclipse.org/viewcvs/indextools.cgi/org.eclipse.cdt-doc/org.eclipse.cdt.doc.isv/guide/mbs/extensibilityGuide/Managed_Build_Extensibility.html
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
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.
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.
Also dann fang ich mal an! Eclipse 3.3/CDT4.0 lauft bei mir schon. Leider ohne deinem Plugin :-((
Hallo, ich würde Dein Plugin auch gerne unter Eclipse 3.3 nutzen wollen! Viele Grüße Thoralt
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.
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 =).
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?
1 | shell ftp -u ftp://root:mypass@dil02/SSV/HelloWorld_01 \ |
2 | ~/SSV/HelloWorld_01/Debug/HelloWorld_01 |
3 | shell ssh -t -l root dil02 chmod +x ./SSV/HelloWorld_01 |
4 | shell ssh -t -l root dil02 ./SSV/gdbserver 192.168.0.121:2222 ./SSV/HelloWorld_01 |
5 | file ~/SSV/HelloWorld_01/Debug/HelloWorld_01 |
6 | shell sleep 2 |
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.
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
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
@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.
Hallo nochmal, danke für die schnelle Antwort! Hat jetzt funktioniert, besten Dank!! Dann kann ich ja jetzt mal testen...*freu* Gruß, Timo
@ 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
@ 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.)
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:
1 | **** Build of configuration Debug for project First **** |
2 | |
3 | make -k all |
4 | Building target: First.elf |
5 | Invoking: C Linker |
6 | arm-elf-linux-gnu-ld ./crt.o ./main.o -o"First.elf" -static -lc -lgcc -Map=First.map |
7 | arm-elf-linux-gnu-ld: cannot find -lgcc |
8 | make: *** [First.elf] Fehler 1 |
9 | 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
In den Einstellungen kannst Du den Parameter rausnehmen, musste ich bei mir bei einem Projekt auch machen. Dann gings.
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
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.
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
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.
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
@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...
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:
1 | timo@ubuntu2:~/workspace/4/Debug$ ls |
2 | 4.map main.d makefile sources.mk subdir.mk |
3 | crt.o main.o objects.mk startfiles |
4 | 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 |
5 | timo@ubuntu2:~/workspace/4/Debug$ ls |
6 | 4.map main.d makefile sources.mk subdir.mk |
7 | crt.o main.o objects.mk startfiles |
8 | 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
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...
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.
Guck mal unter "Help" -> "About Eclipse SDK" -> "Plugin-Details" ob das Plugin gefunden wurde.
@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).
Wem sagt dieser Fehler etwas? Bin vorgegangen wie in FAQ beschrieben (WinARM, eclipse, cdt, plugin).
1 | **** Build of configuration Debug for project test **** |
2 | |
3 | make -k all |
4 | Building target: test.elf |
5 | Invoking: GNU ARM C Linker |
6 | arm-elf-ld ./src/test.o -o"test.elf" -static -lc -Map=test.map |
7 | d:\ARM\WinARM-20060606\WinARM\bin\arm-elf-ld.exe: warning: cannot find entry symbol _start; defaulting to 00008000 |
8 | d:\arm\winarm-20060606\winarm\bin\../arm-elf/lib\libc.a(freer.o): In function `_malloc_trim_r': |
9 | mallocr.c:(.text+0x48): undefined reference to `_sbrk_r' |
10 | mallocr.c:(.text+0x64): undefined reference to `_sbrk_r' |
usw...
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!
Das mit dem _start hat KEIL(mit GNUARM) bei mir immer gebracht, wenn ich die Startup Datei von Keil benutzt hab, glaub ich.
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.
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
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?
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 =).
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
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... =)
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
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.
Okey ist ja kein Problem, machst es ja schließlich freiwillig. Wenn du Zeit findest, schreibst einfach hier rein. Gruss
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.
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
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
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
Das ist beim Plugin bisher so eingestellt, wenns Probleme gibt, muss ich den C-Compiler für C++ Projecte noch eintragen.
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.
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,
>>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.
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,
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.
Bei der Linker Kommandozeile könnte man noch mal gucken ob das ein spezieller Befehl benutzt wird.
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.
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.
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?
Welches Plugin hast Du runtergeladen? Welches CDT verwendest Du? Welches OS (Windows, Linux, MacOS) verwendest Du? Wird das Plugin auch erkannt?
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.
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.
Hi, ok scheint doch zu funktionieren, habe nochmal alles neu installiert. Danke trotzdem für die Mühe!
Wie kann man *.s Dateien kompilieren bei Managed Projects ? Ich habe das Problem das mein crt.s nicht kompiliert wird. thx
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
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.
> 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.
Man lernt nie aus ;)... ich habs gerade mal geschaut und ja man kann für einzelne Dateien separate Einstellungen machen.
rechts klick auf die Datei -> properties -> C(++) build -> settings -> Target -> generate 16 Bit thumb code hth =)
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 :(
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.
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?
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
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.
>> 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
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.
>> 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
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
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... =)
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.
Bugs bitte auf der Sourceforge.net Seite im Bugtracker eintragen... Den Post werde ich mir mal durchlesen...
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!
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.
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!
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...
Eben mal mit Galileo probiert. Geht auch nicht (CDT Plugin ist installiert)...
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.