Hallo zusammen, ich möchte hier einen neuen Beitrag im GCC-Forum eröffnen. In diesem Beitrag soll es darum gehen, wie eine GNU-Toochain für z.B. ARM, MSP430 oder AVR mit einer IDE (z.B. Eclipse oder NetBeans) auf einem Windows-Rechner installiert wird. Ich benutzte derzeit für die Programmierung meines ARM7(NXP LPC21xx)/ARM9(ST STR91xFxx) den Rowley Crossworks for ARM v1.7 und für den MSP430 den Rowley Crossworks for MSP v1.4. Da ich viel mit Klassen und Strukturen arbeite, vermisse ich Funktionen wie intelli sense (kontexbezogenes Anzeigen von Membervariablen oder Klassenfunktion) oder Auto code completion, wie Sie beispielsweise beim Visual Studio von MS, Eclipse oder auch NetBeans vorhanden sind. Ich habe auch Demoversionen von Keil (ARM) und IAR (ARM) ausprobiert - Ohne Erfolg! Es sind zwar gute Kompiler, aber die Codeeditoren lassen doch sehr zu wünschen übrig. Die Toolsuite ARM Realview von ARM (www.arm.com) kombiniert den GCC mit Eclipse und geht in die Richtung von dem, was ich mir vorstelle. Aber der Preis jendeits der einige 100 Euro ist für jeden privaten Softwareentwickler uninteressant. Also habe ich mir Eclipse und eine der vielen freien ARM-Toolchains heruntergeladen. Eclipse installieren war nicht schwer und funktioniert. Die Tollchain installieren war auch nicht schwer und funktioniert. Jedoch bei der Integration der Toolchain in Eclipse bin ich klaglos gescheitert (oder einfach zu blöd). Es gibt eine Flut von Beschreibungen, Plugins und vorgefertigten Editiionen von Eclipse und GNU-ARM Tollchains. Daraus ein funktionierendes Packet zu machen, ist nicht die einfachste Aufgabe. Die soll die Aufgabe dieses Beitrags sein: Eine Anleitung zu erstellen, die auch von Anfängern verstanden werden kann und auch auf andere Toolchains wie AVR oder MSP430 anwendbar ist. Am Ende der Anleitung sollte eine Toolchain-Packet (würde GNU-ARM vorschlagen) stehen. Die Beschreibung sollte enthalten: 1) Quelle und Installation der IDE 2) Quelle und Installation der Toolchain 3) Quelle und Installation eines Debuggers (FTDI-basierte Debugger sollten unterstützt werden) 4) Quelle und Installation eines Simulators 5) Quelle und Installation sonstiger Packete (bitte Vorschläge machen!!) 6) Integration der einzelnen Komponenten in die IDE 7) Einrichten eines MAKE-Files. 8) Erstellen eines hex-files 9) Programmieren 10) Anlegen von Prozessorprofilen (Typ,Aufbau des Speichers mit den Sektionen,usw.) 11) Einrichten einer AUTOMAKE-Funktion, die das Makefile automatisch generiert. Diese Punkte sollen an ausführlichen Beispielen beschrieben werden. Im Grunde sollte eine Funktionalität erreicht werden, wie sie bei Rowley, IAR oder ARM vorhanden sind. Diese Liste stellt sicher nur ein Grungerüst dar. Eine Erweiterung dieser Liste ist natürlich gewünscht. Vielleicht finden sich ja einige Freiwillige, die bei diesem Projekt mitwirken wollen. Ich selber bin Anfänger was das Einrichten solcher Programmierumgebungen anbelangt und nicht in der Lage diese komplexe Aufgabe alleine lösen. Wie schon gesagt, die Programm und Beschreibungen gibt an vielen Orten in verschiedenen Varianten. Ziel dieses Projektes soll sein, die Dinge hier zusammenzutragen und daraus eine funktionierende Toolchain zu erstellen und zu beschreiben, so dass jeder das Vorgehen nachvollziehen kann. Dinge wie Versionpflege und Aktualisierung der Software sind selbstverständlich. Dieses Vorgehen sollte sich auf andere Toolchains übertragen lassen. Ich biete an, das erstellte Packet auf meinem Rapidshare-Account als RAR-File zum allgemeinen Download bereitstellen. Andere Ablageorte sind natürlich auch möglich. P.S.Ich habe natürlich auch schon die Foren im microcontroller.net durchforstet. Es finden sich immer nur einzelne Probleme. Jedoch habe ich nirgens eine komplette Beschreibung von A-Z gefunden, die auch Anfängern einen leichten und schnellen Einstieg ermöglicht.
Hallo Karsten, >Toolchain-Packet (würde GNU-ARM vorschlagen) stehen. >Die Beschreibung sollte enthalten: >1) Quelle und Installation der IDE >2) Quelle und Installation der Toolchain >3) Quelle und Installation eines Debuggers (FTDI-basierte Debugger >sollten unterstützt werden) Schau mal hier, vielleicht ist das was für Dich? http://www.yagarto.de/howto.html Du schreibst das Du CrossWorks for ARM 1.7 getestet hast, wie sieht es denn in der Version 2.0 von CrossWorks aus? Hast Du schon mal Deinen Verbesserungswunsch an Rowley geschickt? Viele Grüße, Michael
Hallo, ich natürlich auch Crossworks 2.x getestet, Auch hier hat noch keine Implemtierung stattgefunden. Ich habe Rowley natürlich einen Vorschlag gemacht (gestern): "Is is possible to activate an intelli sense or auto code completion in Crossworks for arm? If you are look at the Eclipse code editor, there is an intelli sense. It is usefull if I working with classes. The intelli sense feature shows the members and variables in a contex menue which are available in the class. Many freeware compiler (e.g. Eclipse, Netbeans) support this. Or is it possible to implement the Rowley cross compiler in Eclipse? " mit der Antwort: "No, Intellisense is not yet implemented. If you want to use Eclipse, you're really on your own, we have no interest in supporting it." Vielen Dank für den Link. Den Yagarto habe ich auch schon durch. Ebenso wie WINARM. Ich habe das Eclipse GNUARM Plugin von Wilfried Holzke gefunden (http://sourceforge.net/projects/gnuarmeclipse/) und in Eclipse installiert. Ein Project kann ich erstellen, aber beim Kompillieren gibt es haufenweise Fehler. Soweit ich das verstehe, erzeugt das Plugin von Wilfried Holzke ein automatisch generiertes Makefile, da sich sämtliche kompileroptionen in seinem Plugin einstellen lassen. Ist ja nicht so verkehrt. Die Beispiele, die ich gefunden habe, verwenden entweder einen anderen Editor als Eclipse oder benutzen ein selbst geschriebenes Makefile. Ich habe mit dem Eclipse Plugin von W. Holzke ein Project erzeugt und ein main.c file erstellt mit folgendem Inhalt: int main(void) { return 0; } Dies lässt sich nicht fehlerfrei kompillieren. Als Eclipse verwende ich die aktuelle Version, die man herunterladen kann (http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/galileo/SR1/eclipse-cpp-galileo-SR1-win32.zip). Wie bereits in der Einleitung beschrieben ist mir das Vorgehen beim Erstellen eines Projektes mit automatisch generierten Makefile (hier durch das Plugin von W. Holzke) nicht ganz klar. Folgende Fragen stellen sich mir im Moment: 1) Welche Files benötige für ein Projekt mindestens und wie erstelle ich diese? 2) Wie binde ich die Dateien in das Programm ein (glaube hier ist das Stichwort Linkerscript)? 3) In welchem File teile ich dem Kompiler die Prozessorstruktur und die Speichersegmente mit (z.b. .text)? Wie gesagt, bisher haben das der Rowley Kompiler für mich übernommen. Die namenhaften Kompilerhersteller konzentrieren sich eher auf den Kompiler, nicht so sehr auf die Benutzerfreundlichkeit der Oberfläche. Wer aber schon mal mit MS Visual Studio gearbeitet hat, der weiss die Vorzüge von Features wie intelloie sense zu schätzen - insbesondere bei c++ und Klassen. Für absolute Profis ist GNU mit Eclipse sicher kein Problem. Für Anfänger wie mich schon ein ganz grosses. Ich denke, das für mich (und die anderen Anfänger) ein erster Schritt nach der Installation die Definition der minimalen Programmkomponenten ist. Kannst Du mir vielleicht erklären, was ein Minimalprogramm alles benötigt? Die Fehlermeldung und das Projekt habe ich angehangen. MfG Karsten
Hier von mir eine kleine Step by Step Anleitung für Eclipse "Galileo", also die im Moment aktuelle Version in Verbindung mit der Sourcery G++ Lite Version. Yagarto geht auch, aber dann bei (3d) aufpassen: 1) File -> New Project 2) Im erscheinenden Fenster.... C/C++ -> C Project wählen und Button "Next" 3) a) Projektname vergeben b) Default location markieren (dann entsteht das Projekt im Workspace) c) Project Type wählen: ARM Cross Target Application d) Toolchain: ARM Windows GCC (GNUARM, WinARM, Yagarto) oder.... ARM Windows GCC (Sourcery G++ Lite) Ich habe jetzt (Sourcery G++ Lite) gewählt. e) Button "Next" 4) Configurations auswählen, ich nutze immer "Debug" für Projekterstellung mit Debug Optionen für Compiler und Linker und "Release" dann für das fertige Produkt, wo Optionen für Compiler und Linker dann anders sein können. 5) Button "Finish" Jetzt entsteht im Projektbaum in Eclipse das Projekt. 6) Rechte Maustaste auf das Projekt und "New C Source File" wählen. 7) Im erscheinenden Fenster den Filename vergeben INKL.(!) Endung .c Es entsteht der File im Projekt. Dort habe ich jetzt folgendes eingegeben:
1 | |
2 | #include <stdio.h> |
3 | |
4 | int main( void ) |
5 | {
|
6 | return 0; |
7 | }
|
8) Es fällt auf, dass die include-Zeile gelb unterstrichen ist.
Das liegt daran, dass Eclipse diese Datei stdio.h nicht findet,
da es die Include-Pfade noch nicht kennt. Das richten wir jetzt
ein: Rechter Mausklick auf das Projekt und "Properties" wählen.
Da wir hier mit einem "Managed Project" arbeiten, nimmt Eclipse diese
Pfade und übergibt sie dem Compiler.
Bei einem nicht "Managened Project" haben wir einen Makefile. Dort
müssen dann die Pfade nochmal extra eingetragen werden, da ja dort
der Makefile für den Build-Prozess zuständig ist. Aber den Fall
beachten wir hier nicht.
9) Rechts Configuration "Debug" wählen.
10) In dem Fenster links C/C++ Build -> Settings wählen.
11) Jetzt rechts den Reiter "Tool Setting" wählen.
12) Hier kann man jetzt alle Möglichen Einstellungen vornehmen.
Bei mir:
a) Target processor: Processor: arm7tdmi
Thumb markiert (aktiv)
Thumb interwork deaktiviert
b) Debugging: Debug level: -g3
Debug format: stabs
Other: leer
c) Additional Tools: Create Flash Image aktivieren,
Rest wie beliebt, ich habe alle aktiv.
d) ARM Windows GCC C Compiler:
Directories: Hier die gewünschten Include-Pfade einstellen, in
diesem Fall mindestens zu der Datei stdio.h: Rechts gibt es einen
kleinen Button mit einem grünen '+'. Diesen klicken, dann geht
ein
Auswahldialogfenster auf. Jetzt den Pfad wählen.
Bei mir für (Sourcery G++ Lite):
"C:\Programme\CS_ARM\arm-none-eabi\include"
e) ARM Windows GCC C Linker:
General: Do not use standard start files (-nostartfiles)
aktivieren, Rest aus
Script file(-T): Hier das Linkerscript eintragen.
13) Unten "Apply" und "OK" klicken.
Die gelb unterstriche "include"-Zeile sollte jetzt nicht mehr
unterstrichen sein.
14) Jetzt oben im Menu (Hauptfenter) Project -> Build Project wählen.
Danach sollte alles gut sein. Die Pfade zu den Binaries des Compilers
und des Linkers müssen ein gerichtet sein. Sonst kann Eclipse den
Compiler bzw. den Linker nicht aufrufen.
Bei mir sieht die Ausgabe so aus:
1 | **** Build of configuration Debug for project ARMProject1 **** |
2 | |
3 | cs-make all |
4 | Building file: ../main.c |
5 | Invoking: ARM Sourcery Windows GCC C Compiler |
6 | arm-none-eabi-gcc -I"C:\Programme\CS_ARM\arm-none-eabi\include" -O0 -Wall -fsigned-char -c -fmessage-length=0 -MMD -MP -MF"main.d" -MT"main.d" -mcpu=arm7tdmi -mthumb -g3 -gstabs -o"main.o" "../main.c" |
7 | Finished building: ../main.c |
8 | |
9 | Building target: ARMProject1.elf |
10 | Invoking: ARM Sourcery Windows GCC C Linker |
11 | arm-none-eabi-gcc -T"D:\Projekte\EclipseWS\ARMProject1\AT91SAM7S256-ROM.ld" -nostartfiles -Wl,-Map,ARMProject1.map -mcpu=arm7tdmi -mthumb -g3 -gstabs -o"ARMProject1.elf" ./main.o |
12 | Finished building target: ARMProject1.elf |
13 | |
14 | Invoking: ARM Sourcery Windows GNU Create Flash Image |
15 | arm-none-eabi-objcopy -O ihex ARMProject1.elf "ARMProject1.hex" |
16 | Finished building: ARMProject1.hex |
17 | |
18 | Invoking: ARM Sourcery Windows GNU Create Listing |
19 | arm-none-eabi-objdump -h -S ARMProject1.elf >"ARMProject1.lst" |
20 | Finished building: ARMProject1.lst |
21 | |
22 | Invoking: ARM Sourcery Windows GNU Print Size |
23 | arm-none-eabi-size --format=berkeley ARMProject1.elf |
24 | text data bss dec hex filename |
25 | 16 0 0 16 10 ARMProject1.elf |
26 | Finished building: ARMProject1.siz |
Weitere C- bzw. Headerfiles können wie unter (7) beschrieben hinzugefügt werden. Ich setze Kenntnisse über Linkerskripte voraus. Am besten kommt man zurecht, wenn man in der Lage ist, mittels Make auf der Kommandozeile ein Projekt fehlerfrei zu kompilieren und zu linken. Dann versteht man dieses hier unter Eclipse auch. Viel Spaß. Joachim
Karsten Brandt schrieb: > 1) Welche Files benötige für ein Projekt mindestens und wie erstelle ich > diese? Siehe mein Posting oben... > 2) Wie binde ich die Dateien in das Programm ein (glaube hier ist das > Stichwort Linkerscript)? Du mußt ein Linkerscript haben und im Projekt mit angeben, siehe oben. > 3) In welchem File teile ich dem Kompiler die Prozessorstruktur und die > Speichersegmente mit (z.b. .text)? Diese Frage sagt mir, dass du nicht weißt, was ein Linkerscript ist. Dort steht das drin. Prozessor nicht, aber die Segmente. Besuche die Homepage von "Martin Thomas", der hat sehr viele Beispiele für ARM. Dort findest du auch Linkerscripte. http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ Das Thema ist wirklich nicht einfach und hat nichts mit Eclipse zu tun. Wenn du keine IDE hast, die dir das vorkaut, dann solltest du ein Linkerscript erstellen (ein vorhandenes anpassen) können. Eclipse kann kein Linkerscript erstellen. Das mußt du machen. Viel Spaß. Joachim Edit: Ach ja, mein Beispiel im Posting oben nutzt auch das Plugin, welches du benutzt. Sonst funktioniert der Prozess nicht so!
Was ich doch alles so auf meiner Platte habe :-)) Ein Howto als PDF. Ist zwar für Ubuntu, aber wenn man mal das Eclipse + Plugin installiert hat, dann ist der Rest ziemlich identisch. Nun, evtl. hilft es ja. Dort wird zum Debuggen das Zylin Plugin genutzt. Angeblich haben die CDT in Eclipse Fehler. Hmmm.... bei mir läuft es mit den CDT. Ach ja, einen Bug kenne ich, 32 Bit breite Variablen (entweder lokale oder globale) werden mit falschem Inhalt angezeigt. Vielleicht ist das gemeint. So nun ist Schluß für dieses Jahr ;-) Joachim
Hallo an alle Beteiligten. Wüsche euch ein frohes neues Jahr.
Vielen vielen Dank 900ss. Das Projekt lässt kompilieren (allerdings ohne
startup und linkerfile).
Inzwischen war ich auch nicht ganz untätig. Das ein Startup-Code
benötigt wird weiss ich von Crossworks. Es ist mit nun klar, dass ein
Linkerscript benötigt wird. Also werden für ein vollständiges
Minimalprojekt die folgenden Dateien benötigt:
1) Der Startupcode. Wird meist mit crt0.s, crt.s oder startup.s
bezeichnet.
2) Das Linkerscript. In diesem ist beschrieben, welche Programmteile in
welchen Speicherbreichen abgelegt werden.
3) Die Programmdatei main.c
1) Kapitel 1 - Der Startup-Code
--------------------------------
Als erstes beginne ich mit dem Startup-code. Wenn ich das richtig
verstehe, macht dieser folgendes:
1) Initialisieren der Exception Tabelle
2) Sonstige Hardwareinitialisierungen, z.B. PLL (falls erforderlich)
3) Vorbereiten C Runtime Environment
*Vorbereiten und initialisieren der Stacks.
*Kopieren von ROM ins RAM
*Initialisieren der nichtinitialisierte Variablen mit 0
(.bss-section)
*Initialisieren des Heaps.
*Call Konstruktoren
*Springen zum Hauptprogramm (nach int main(void))
*Aufruf der Destruktoren
*Aktion beim Verlassen des Hauptprogramms main() definieren, z.B.
Endlosschleife.
Ich habe mit verschiedene Startup-Codes angesehen(Beispiele von WINARM
von Martin Thomas, Keil, Rowley und ARM Realview von ARM direkt). Der
Startup-Code ist im Assembler geschrieben. Hinzukommt noch, dass die
Syntax der verwendeten Assembler voneinander abweicht. Beides macht das
Verstehen und Anpassen des Startup-Codes für einen Anfänger nicht
leichter. Auf meinen Streifzügen durch diverse Projekte und Foren habe
ich gesehen, dass viele den Startup-code adaptieren, aber teiweise auch
Schwierigkeiten beim Verständnis haben. Durch Probieren funktioniert es
bei den meisten aber. Die Erklärungen zu den Startup-code sind nicht so
ausführlich. Ich bin daher bestrebt, auch einige Hintergründe und
Erklärungen zum Erstellen des Startup-codes zu geben. Bin grad bei der
Erstellung eines Beispieles für einen startup-code, der für möglichst
viele ARM-Controller funktionieren soll (Konkret benutze ich derzeit
einen STR911FM44 von ST). Eine mögliche Version mit Beschreibung werde
ich demnächst posten (schätze 1-2 Tage).
Und wie gesagt, ich bin Anfänger und arbeite mich selber erst ein. Daher
etwas Nachsicht, wenn es nicht perfekt ist.
MfG
Karsten
Für MSP430 habe ich hier mal einige Screenshots für das erste Projekt: http://supachris.homeip.net/Eclipse_MSPGCC.zip Voraussetzung ist eine korrekte Installation des MSPGCC Paketes, einer Eclipse mit C/C++ Unterstützung sowie das MSPGCC-Plugin von hier: http://homepage.hispeed.ch/py430/mspgcc/ (das muss einfach in den Eclipse-Ordner entpackt werden). Debuggen klappt mit allen kompatiblen Debuggern, dazu müssen die msp430.dll und die hil.dll im bin Verzeichnis des mspgcc ausgetauscht werden. Die Debugger-Hersteller liefern die passenden Dateien ja mit. Ich nutze privat den Olimex USB JTAG Tiny. Damit kannst du gerne nochmal eine Schritt-für-Schritt Anleitung erstellen.
KarstenBrandt schrieb: > 1) Kapitel 1 - Der Startup-Code > -------------------------------- > Als erstes beginne ich mit dem Startup-code. Wenn ich das richtig > verstehe, macht dieser folgendes: > ..... Hier Beitrag "Re: STM32F10x mit Eclipse, yagarto (GCC) und J-Link (GDB)" gibt es einen Startupcode in 'C'. Allerdings ist dieses Modul in neueren Versionen von der STM-Lib auch in Assembler. Warum weiß ich leider auch nicht. Habe noch nicht sehr stark nach Unterschieden geforscht. 3 Postings unter dem (Link oben) habe ich auch ein PDF angehangen, der alles zu den ARMs ganz gut erklärt. Allerdings ohne Eclipse, aber eben Startup und Linkerscript u.s.w. *!!!* Du mußt für die AVRs keinen Startup-Code schreiben, da das die Toolchain alles mitbringt. Je nach verwendetem Controller wird automatisch der richtige Code dazugelinkt. Wie es bei dem MSP ist weiß ich auch nicht.
900ss D. schrieb: > *!!!* Du mußt für die AVRs keinen Startup-Code schreiben, da das die > Toolchain alles mitbringt. Je nach verwendetem Controller wird > automatisch der richtige Code dazugelinkt. Wie es bei dem MSP ist weiß > ich auch nicht. Natürlich bringt der MSPGCC auch die Startup-Codes mit. Wäre ja witzlos sonst...
Wg. IDE: gibt es auch Ansätze das MS VisualStudio zu Nutzen? Da ist ja auch einiges Konfigurierbar und über Schnittstellen zu erweitern. Andere Compiler können sich da auch einnisten, siehe z.B. Intel Compiler.
Christian R. schrieb: > Natürlich bringt der MSPGCC auch die Startup-Codes mit. Wäre ja witzlos > sonst... Nö, bei den ARM-Toolchains ist kein Startup-Code dabei. Jedenfalls wird er nicht automatisch dazugelinkt bzw. nichts funktionierendes.
900ss D. schrieb: > Christian R. schrieb: >> Natürlich bringt der MSPGCC auch die Startup-Codes mit. Wäre ja witzlos >> sonst... > > Nö, bei den ARM-Toolchains ist kein Startup-Code dabei. Jedenfalls wird > er nicht automatisch dazugelinkt bzw. nichts funktionierendes. Echt? Das ist ja blöd. Da muss man sich also den Startup Code selber schreiben bzw. einen funktionierenden irgendwo suchen und dazu linken? Wusste ich gar nicht.
Christian R. schrieb: > Echt? Das ist ja blöd. Da muss man sich also den Startup Code selber > schreiben bzw. einen funktionierenden irgendwo suchen und dazu linken? > Wusste ich gar nicht. Ob das auch bei den käuflichen IDEs so ist, kann ich nicht sagen. Ich glaube Codesourcery hat da was im Programm aber sicher bin ich mir nicht. Vielleicht weiß Martin T. da mehr und er liesst zufällig mit.
900ss D. schrieb: > Christian R. schrieb: >> Echt? Das ist ja blöd. Da muss man sich also den Startup Code selber >> schreiben bzw. einen funktionierenden irgendwo suchen und dazu linken? >> Wusste ich gar nicht. > > Ob das auch bei den käuflichen IDEs so ist, kann ich nicht sagen. Ich > glaube Codesourcery hat da was im Programm aber sicher bin ich mir > nicht. > Vielleicht weiß Martin T. da mehr und er liesst zufällig mit. Schon, aber so wirklich viel als Rekation auf "ist ja blöd" oder "witzlos sonst" kann ich auch nicht bieten. - Der eigentliche Startup-code für die jeweilige Familie (ARM7, CM-3) ist relativ ähnlich. Hat man einen, kann man recht einfach an andere anpassen. Schritte: Einrichten d. core-exceptions ("vector" evtl. mehrere), evtl. "frühe" Inits (z.B. Watchdog aus), stack-setup, data-copy, bss-clear, sprung zu main. Evtl. in der gleichen Quellcodedatei auch noch Interrupt-Handler (das ist dann eigentlich nicht mehr startup-code) - Codesourcery hat das "CM3" System, damit will man wohl startup-code (und auch linker-script) halbwegs universell und übersichtlich machen. Näheres dazu in der "Getting-started" pdf-Datei. CM3 bis dato nicht selbst ausprobiert. - Zumindest Keil/ARM RVMDK uVision und IAR EWARM kommt mit vielen startup-codes (in den Beispielen, selbst nur Evaluisierungsversionen angeschaut). Bei Keil/ARM sogar einige für GNU-Assembler, die meisten jedoch für Realview Assembler (Keil) oder den Assembler der EWARM (IAR). Von denen kann man sich zumindest "insprieren" lassen. - Viele Hersteller bieten startup-code für GNU ARM-tools: z.B. Atmel, Analog Devices, TI/Luminary Micro, STMicroelectronics (zumindest f. STM32), OKI, Sharp (deren ARM-basierte nun auch bei NXP). Für Controller anderer Hersteller mit gleichem ARM-core kann man sich davon auch wieder insprieren lassen.
Hallo @all, melde mich nach langer Zeit zurück. War dienstlich unterwegs und hatte deshalb keine Zeit. Die ganze letzte Woche habe ich mich mit Eclipse und GNU-Tools (WinARM) rumgeschlagen und bin fast völlig verzweifelt. Ich habe zwar meine Step-by-Step Anleitung für Dummies schon angefangen (derzeitiger Stand ist die Installation der Toolchain und Eclipse), muss diese aber noch überarbeiten. Das Thema startup-code und Linkerscript ist erst mal nach hinten verschoben. Es sind viel grundlegendere Probleme im Umgang mit Eclispe aufgetreten. Zwei möchte ich euch im folgenden schildern: Den Tipp von900ss D. (900ss) vom 30.12.2009 um 21:46 habe ich berücksichtigt und alles war wunderbar, bis ich irgenwann angefangen habe Dateien von zu Testzwecken Build-Prozess auszuschliessen und anschliesen wieder einzuschliessen. Dieses Problem hat mich eine geschlagene Woche gekostet. Das eine Problem habe durch propieren gelöst. Für das andere habe ich keine Lösung. Für beide Probleme habe ich keine wirkliche Erklärung. Meine Kenntnisse was die Hintergründe von ECLIPSE und dem GNUARM-Eclipse-Plugin sehr mager. Mein Versuch mich in die (Java-) Programmierung des Plug-ins einzuarbeiten bzw. zu verstehen was das Plug-in in Eclipse macht sind gnadenlos gescheiert. Habe keine Ahnung von Java-Programmierung bzw. Programmierung von Eclipse Plug-ins. Das Projekt, eine Beschreibung der Probleme und die Konsolenausgaben von Eclipse habe ich euch angehängt. Aus meiner Sicht macht es keinen Sinn sich an die Programmierung zu machen, wenn die Werkzeuge noch Fehlerhaft oder noch nicht richtig verstanden sind und der Quellcode möglicherweise nicht richtig kompiliert wird. Vielleicht habt ihr ja eine Erklärung (und idealerweise eine Lösung) für die beschriebenen Probleme. Für weitere (reprodzierbare) Probleme darf ich mich hoffentlich auch noch an euch wenden?
Karsten Brandt schrieb: > Die ganze letzte Woche habe ich mich mit Eclipse und GNU-Tools (WinARM) > rumgeschlagen und bin fast völlig verzweifelt. Glaub ich :-) Problem 1 ist keines bzw. nur zum Teil. Du hast versucht einen Headerfile von der kompilierung auszuschließen. Headerfiles werden nur kompiliert, wenn du sie mit #include <datei.h> mit in eine C-Datei einbindest (oder auch in eine Headerdatei, die vorher irgendwie ein Include erfahren hat). Wenn du diese Dateien in Eclipse ausschließt, hat das keine Wirkung, was normal ist und wie du auch festgestellt hast. Ein Fehler vom Plugin scheint es zu sein, dass nach Entfernen des Ausschlusses der Headerdatei die anderen Tools nicht mehr aufgerufen werden und du das erst über andere Menus beheben mußtest. Den Bug habe ich dem Autor des Plugins mitgeteilt. Hier: Beitrag "GNUARM Eclipse Plugin" Das Problem 2 scheint auch im Plugin zu liegen aber es könnte durch die "Spielerei" bei Problem 1 schon ins Projekt gekommen sein. Du solltest ein neues Projekt erstellen. Du scheinst dir viel Mühe zu geben für diese Anleitung. Aber es entsteht der Eindruck, dass dir C-Grundlagen fehlen, sonst hättest du nicht die Versuche mit der Headerdatei gemacht. Dein Eröffnungsposting hier "spricht" wieder anders. Warum dann der Versuch mit der Headerdatei?
Moin, Wenn es irgendwelche Probleme mit dem Plugin gibt, dann wäre es super, wenn diese auch auf der Sourceforge.net Seite eingetragen werden, das beschleunigt bzw. gibt uns (den Entwicklern) überhaupt erst die Möglichkeit das ganze zu beheben. Wenn ich das richtig verstanden habe, dann benutzt Du das Plugin (0.5.3) mit der aktuellen Eclipse 3.5.1/CDT 6.x Version. Für Eclipse Galileo sind wir gerade noch dabei das Plugin zu bauen. Die Version 0.5.3 des Plugins war für Eclipse Ganymede (Eclipse 3.4/CDT 5.x). Das Plug-in macht grundsätzlich genau das gleiche wie CDT in der Originalkonfiguration für C/C++ für das entsprechende OS, nur eben für die ARM Toolchain(s). Das Plug-in ist eine Erweiterung, die z.B. die Befehle austauscht, d.h. es wird nicht der gcc für das OS (Linux, Windows) aufgerufen sondern ein gcc der ARM Code erzeugt. Hinzu kommen natürlich ARM spezifische Konfigurationsmöglichkeiten. Um zu vertehen wie CDT funktioniert, sollte man vieleicht mal ein einfaches Commandozeilen Programm schreiben, dies dann mit einem Makefile zusammenbauen und dann das ganze mit CDT versuchen. Dann sollte man verstanden haben was CDT macht. Dann kann man auch weiter gehen zur Entwicklung mit ARM, da kommen dann eben Linkerscripte hinzu. Wenn ein fertiges Howto/Tutorial da ist und es es unter einer Creative Commons Lizens verfügbar ist dann würde ich es gern mit auf der Seite veröffentlichen.
Hallo zusammen, vielen Dank für die Kommentare. @900ss D. Die Grundlagen in C\C++ sind schon bei mir vorhanden. Die Sache mit den #includes sind mir natürlich bekannt. Ich schliesse zu Testzwecken oder Fehlerdiagnose manchmal Dateien aus. In diesem Zusammenhang sind mir die Fehler erst aufgefallen. Wie bereits erähnt, nutze ich fertige Kompiler wie den Rowley. Mich stört bei diesem Compiler lediglich, dass Dinge wie intellisense fehlen. Wer viel mit Klassen unter Microsofts Visual Studio gearbeitet hat wird das verstehen. Wie so ein Kompiler prinzipell funktioniert ist mir schon klar. GNU mit einer IDE sind aber für mich Neuland. Es wird einem eben nicht alles vorgekaut. Also muss ich mich mit den Werkzeugen beschäftigen und in die Materie einarbeiten. Macht aber Spass.Mühsam ernährt sich eben das Eichhörnchen :-). >Das Problem 2 scheint auch im Plugin zu liegen aber es könnte durch die >"Spielerei" bei Problem 1 schon ins Projekt gekommen sein. Du solltest >ein neues Projekt erstellen. Ich habe vorher ein neues Projekt erstellt. @Wilfried Holzke Den Test in meinem Post vom 17.01.2010 habe ich mit Ganymede gemacht. Die Versionen sollten aber im PDF stehen. Die Tutorial darfst Du natürlich veröffentlichen, kein Problem. Ihr habt aber recht. Ich werde zukünftig Fehler den Eclipse-Plugin Entwicklern mitteilen. So, nun werde ich mal weiter kreativ in dieser Sache tätig sein :-)
Karsten Brandt schrieb: > ie Grundlagen in C\C++ sind schon bei mir vorhanden. Die Sache mit den > #includes sind mir natürlich bekannt. Ich schliesse zu Testzwecken oder > Fehlerdiagnose manchmal Dateien aus. In diesem Zusammenhang sind mir die > Fehler erst aufgefallen. Mir stellt sich die dann Frage, warum du eine Änderung erwartest, wenn du die Headerdatei im Eclipseprojektbaum ausschließt. Da kann keine Änderung eintreten. Aber das wußtest du ja. Also was hast du erwartet?
Karsten Brandt schrieb: > ... > Wie bereits erähnt, nutze ich fertige Kompiler > wie den Rowley. Mich stört bei diesem Compiler lediglich, dass Dinge wie > intellisense fehlen. Wer viel mit Klassen unter Microsofts Visual Studio > gearbeitet hat wird das verstehen. > Der Compiler hat doch mit Intellisense nicht zu tun, sondern nur der Editor. Du brauchst deshalb nicht auf GNU umzusteigen, nur um Eclipse zu benutzen. Wenn man unter Eclipse C/C++ ein Makefile Projekt erstellt, kann man jeden Compiler verwenden den man will. Man muß nur das Makefile selber schreiben. Für Fortgeschrittene ist es sogar möglich, ein kleines Plugin zu schreiben, damit die Fehlerstellen beim compilieren erkannt werden, und man über Mausklick direkt an die Fehlerstelle springen kann. Ist gar nicht so kompliziert.
900ss D. schrieb: >Mir stellt sich die dann Frage, warum du eine Änderung erwartest, wenn >du die Headerdatei im Eclipseprojektbaum ausschließt. Da kann keine >Änderung eintreten. Aber das wußtest du ja. Also was hast du erwartet? Wie ich bereits sagte, Dateien schliesse zu Testzwecken aus. Es fördert auch die Übersichtlichkeit, wenn ich mich nur die momentan benötigten Dateien konzentrieren. Alles nicht benötigte wird ausgeblendet. Ich hatte lediglioch erwartet, dass bei einschliessen keine Fehler auftreten. Klaus Falser schrieb: >Der Compiler hat doch mit Intellisense nicht zu tun, sondern nur der >Editor. Sorry, da habe ich mich wohl falsch ausgedrückt. Ich meinte natürlich den Editor. Compiler wie der Rowley-ARM oder Keil-Arm sind eher schlecht dokumentiert. Diese basieren zwar auf dem GNU-Arm. Aber wie vergleichbar diese mit dem (original) GNU sind kann ich nicht einschätzen. Folglich kann ich den Aufwand und Erfolg für eine Integration in einen besseren Editor nicht abschätzen. GNU-Toolchains wie der WINARM, Yagarto, usw. werden in den Foren gut diskutiert und mit zeitlichem Suchaufwand findet man auch Lösungen für seine Probleme. Daher mein Versucht mit GNUARM und Eclipse. Aber wie gesagt, die Informationen sind weit im Web gestreut und man muss manchmal lange suchen. Da ich mich sowieso in diese Materie einanrbeiten möchte,kann ich das auch gleich für andere Anfänger dokumentieren. So ist das Wichtigste in einem zentralen Dokument mit Erläuterungen zusammengefasst. >Wenn man unter Eclipse C/C++ ein Makefile Projekt erstellt, kann man >jeden Compiler verwenden den man will. Man muß nur das Makefile selber >schreiben. Mit dem Makefile muss ich mich auch noch beschäftigen. Damit man jeden Komnpiler über ein Makefile steuern kann, muss dieser erstmal hinreichend dokumentier sein. Bei Rowley und Keil findet sich nicht so viel. >Für Fortgeschrittene ist es sogar möglich, ein kleines Plugin zu >schreiben, damit die Fehlerstellen beim compilieren erkannt werden, und >man über Mausklick direkt an die Fehlerstelle springen kann. Ist gar >nicht so kompliziert. Da mag ja stimmen. Davon bin ich aber noch Lichtjahre entfernt. Gibt es über dieses Thema irgendwelche tutorials? Falls nicht, könntest Du ja mal eines schreiben? Interessiert mich schon.
Ich beschäftige mich gerade mit dem Linker und Linkerscripte. Nach meinen Recherchen kennt der Linker von sich aus (d.h. ohne selbst definierte sections) die folgenden sections: Dem Linker Manual habe entnommen: .text (ausführbarer code im Flash) .data (initialisierte Daten) .bss (uninitialisierte Daten) Im Linker Manual nicht beschrieben, aber in Scripten oft verwendet .rodata (Read Only Data, z.B. Konstanten) .glue_7 (????) .glue_7t (????) Habe ich irgendwelche sections vergessen? Gibt es irgendwo eine Beschreibung über den GNUARM-Linker, in der die standard Sektionen beschrieben sind? Welche undokumentierten Sektionen gibt es noch? Danke
Karsten Brandt schrieb: > Mit dem Makefile muss ich mich auch noch beschäftigen. Damit man jeden > Komnpiler über ein Makefile steuern kann, muss dieser erstmal > hinreichend dokumentier sein. Bei Rowley und Keil findet sich nicht so > viel. Das Makefile (um genau zu sein, eigenlich das Programm make) automatisiert nur den Kompiliervorgang, d.h. man braucht die einzelnen Kommandos nicht mit der Hand eintippen. Die dazu nötige Dokumentation sind die üblichen Compiler-switches und das Format für die Kommandozeile. Wenn man diese nicht hat, dann kann man den Compiler sowieso gleich wegschmeißen, aber ich glaube das nicht, das steht in jedem Handbuch.
Hallo, 900ssd wählt die Arm-toolchain aus. Bei mir erscheint leider nur eine cygwin-toolchain (bei show all noch mehere: MinGw etc.) Wie bekomme ich die Arm-toolchain (G++lite) in eclipse? Danke und Gruss
Peterp schrieb: > Wie bekomme ich die Arm-toolchain (G++lite) in eclipse? In dem du das Plugin für die ARM-Toolchain installierst so wie es Karsten getan hat. Karsten Brandt schrieb: > Ich habe das Eclipse GNUARM Plugin von Wilfried Holzke gefunden > (http://sourceforge.net/projects/gnuarmeclipse/) und in Eclipse > installiert. Ein Project kann ich erstellen, aber beim Kompillieren gibt
900ss D. schrieb: > In dem du das Plugin für die ARM-Toolchain installierst so wie es > Karsten getan hat. Sorry hab ich doch glatt überlesen.. es funktioniert, Danke...
Thread beobachten
Seitenaufteilung abschaltenBitte 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.