www.mikrocontroller.net

Forum: Compiler & IDEs GNU ARM vs. CodeSourcery


Autor: Lasse S. (cowz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich fange gerade an, mich in die Cortex-M3 Reihe einzuarbeiten. Unter 
Eclipse bin ich mittlerweile soweit, dass ich bei dem Projektwizard "ARM 
Cross Target Application" auswählen kann.

Dort habe ich jetzt die Auswahl zwischen
"ARM Linux GCC (GNU ARM)" und "ARM Linux GCC (CodeSourcery G++ Lite)".

Mal abgesehen davon, dass ich den CodeSourcery-Compiler noch nicht 
installiert habe, wo ist der Unterschied und welcher ist (wann) zu 
empfehlen?


Viele Grüße
Lasse

: Verschoben durch Admin
Autor: Seppel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

kannst Du mir ein paar Tipps bzw. Webadressen geben wo ich was dazu 
finde? Hab nen FTDI2232 JTAG und ein Board, aber das immer vor mir her 
geschoben, muss mal dringend dran gehen, aber OpenOCD hat mich etwas 
angeschreckt, vor allem das man die langsamen FTlib GNU Treiber direkt 
mit rein kompiliert, anstatt die schnelleren von FTDI

Vielen Dank.

Grüße

Seppel

Autor: J. V. (janvi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hat das Teil schon mal jemand ausprobiert ?

http://www.atollic.com/

Das Kabel zu 21 Euro scheint eine R-Link Spezialversion von Raissonance 
zu sein. Inkl. SWD (?) was OpenOCD noch nicht kann (?)
Der Compiler GCC, der Debugger (?)
Vor allem wird mal wieder nicht klar, was an der Demo Version fehlt.

Autor: Lasse S. (cowz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

eine ziemlich genaue Auflistung der Feature-Unterschiede gibt's hier:
http://www.atollic.com/index.php/truestudio/featur...

Würde mich nur ungern an die IDE binden, da das ganze nur STM32 zu 
unterstützen scheint. Das schöne an den anderen Lösungen (ARM GCC, 
OpenOCD) ist ja (auch), dass alle Cortex-M3 unterstützt werden.

Hat zu meiner Ausgangsfrage niemand ne Meinung?

Gruß
Lasse

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gab neben CodeSourcery auch andere Windows-Versionen von GCC für ARM, 
nämlich WinARM und GNUARM. Beide sind mittlerweile eingeschlafen, nur 
CodeSourcery wird weiterhin aktiv gepflegt.

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

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Es gab neben CodeSourcery auch andere Windows-Versionen von GCC für ARM,
> nämlich WinARM und GNUARM. Beide sind mittlerweile eingeschlafen, nur
> CodeSourcery wird weiterhin aktiv gepflegt.

Das stimmt nicht. Zumindest nicht für GNUARM, was YAGARTO ist wenn ich 
nicht irre ( Yet another GNU ARM toolchain ). Die ist aktuell. Der 
Compiler ist sogar eine Stufe weiter als der von Codesourcery.

Ob Codesourcery Lite (kostenlos) oder YAGARTO besser ist, kann ich nicht 
sagen. Ich habe mich für Codesourcery entschieden, da die die einzigen 
waren, die "damals" den Cortex-M3 unterstützten. YAGARTO kann das 
inzwischen auch, wenn ich nicht irre. YAGARTO unterstützt die newlib 
nicht mit reentrant stubs (steht dort geschrieben).
http://www.yagarto.de/index.html#download

Aber ich meine, das tut sich nicht viel.

just my 2 cents

Joachim

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
900ss D. schrieb:

> Das stimmt nicht. Zumindest nicht für GNUARM, was YAGARTO ist wenn ich
> nicht irre ( Yet another GNU ARM toolchain ). Die ist aktuell. Der
> Compiler ist sogar eine Stufe weiter als der von Codesourcery.

Ja, Yagarto hatte ich vergessen, möglicherweise meist Eclipse diese. Ich 
bezog mich auf die Toolchain mit dem Namen "GNU ARM", die 2006 
eingestellt wurde (http://www.gnuarm.com/).

Autor: Lasse S. (cowz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich nutze Linux (Ubuntu), daher fällt YAGARTO für mich weg.

Ich habe arm-elf-gcc Version 4.3.2. Das ist zwar nicht die ganz 
aktuelle, sollte aber noch ausreichend sein, oder?

Gruß
Lasse

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CodeSourcery gibt's auch für Linux. In dem Fall dürfte das die 
empfehlenswerte weil besser gepflegte Version sein.

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

Bewertung
0 lesenswert
nicht lesenswert
Autor: Lasse S. (cowz)
Datum: 30.11.2009 22:18
>ich fange gerade an, mich in die Cortex-M3 Reihe einzuarbeiten. Unter
>Eclipse bin ich mittlerweile soweit, dass ich bei dem Projektwizard "ARM
>Cross Target Application" auswählen kann.
>Dort habe ich jetzt die Auswahl zwischen
>"ARM Linux GCC (GNU ARM)" und "ARM Linux GCC (CodeSourcery G++ Lite)".
>Mal abgesehen davon, dass ich den CodeSourcery-Compiler noch nicht
>installiert habe, wo ist der Unterschied und welcher ist (wann) zu
>empfehlen?

Es kann durchaus sein, dass beide von Wizard gelisteten Toolchains dafür 
gedacht sind, Anwendungen zu erstellen, die unter Linux auf einem 
ARM-basierten Controller laufen sollen. Üblicherweise will man dies 
nicht, es wird eine "bare-metal" toolchain benötigt - Unterschied u.a. 
in der beliegenden libc.


Autor: Seppel (Gast) [IP:
Datum: 30.11.2009 23:20
>... aber OpenOCD hat mich etwas
>angeschreckt, vor allem das man die langsamen FTlib GNU Treiber direkt
>mit rein kompiliert, anstatt die schnelleren von FTDI ...

Die einzige traurige Folge der OpenOCD zugrundeliegendenden Lizenz, mit 
der zumindest einer der aktiven OpenOCD entwickler es sehr genau nimmt. 
Selbst kompilieren und damit er Lizenz Genüge leisten ist aber nicht 
allzu kompliziert, mit Cygwin/mingw-compiler auch unter MS Windows kein 
Hexenwerk.


Autor: 900ss D. (900ss)
Datum: 01.12.2009 08:57
>>A. K. schrieb:
>> Es gab neben CodeSourcery auch andere Windows-Versionen von GCC für ARM,
>> nämlich WinARM und GNUARM. Beide sind mittlerweile eingeschlafen, nur
>> CodeSourcery wird weiterhin aktiv gepflegt.

Ja WinARM ist im Kälteschlaf - vielleicht für immer. Zumindest solange, 
wie der WinARM-Packager in Codesourcey G++ lite ARM-eabi alles 
notwendige findet. Vielleicht gibt's mal ein "WinARM addon" für andere 
Packete mit einer Beispiel- und Toolsammlung...

>Das stimmt nicht. Zumindest nicht für GNUARM, was YAGARTO ist wenn ich
>nicht irre ( Yet another GNU ARM toolchain ). Die ist aktuell. Der
>Compiler ist sogar eine Stufe weiter als der von Codesourcery.

DevkitARM (sf.net DevkitPro) dürfte auch noch halbwegs aktuell sein. 
Enthält auch eine recht nütztliche libsysbase, ist für den Anfang aber 
nicht erforderlich (später evtl. auch nie).

>... YAGARTO unterstützt die newlib nicht mit reentrant stubs
>(steht dort geschrieben).

Kaum etwas mit Yagarto gemacht aber der Yagarto-Macher hat mir vor eine 
Weile in einer E-Mail geschrieben, dass die GNU tools bei Yagarto im 
Bezug auf syscalls nun genauso konfiguriert wird, wie ich das seinerzeit 
bei WinARM gemacht hatte, also ohne die vergekauten system-calls der 
libc (reent-sysc-provid, disab-newlib-suppl-syscalls).


Autor: A. K. (prx)
Datum: 01.12.2009 13:04
>CodeSourcery gibt's auch für Linux. In dem Fall dürfte das die
>empfehlenswerte weil besser gepflegte Version sein.

Sehe ich auch so.
Sourcery G++ Lite 2009q3-68 for ARM EABI -> IA32 GNU/Linux Installer

Autor: let (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yagarto ist arm-elf, Codesourcery ist gnu-eabi.

Die beiden unterscheiden sich im Stack-alignment (4 Bytes vs. 8 Bytes).
Die Linker-Scripts müssen das beim Codesourcery berücksichtigen,
sonst kommt es zu unerklärlichen Abstürzen.

C++ mit Codesourcery ist ein Krampf und funktioniert wenn man ein
Projekt entsprechend eingerichtet hat mit keinem anderen Compiler.

Ein Vorteil von EABI für 'Bare-metal systems' ist für mich nicht
ersichtlich. Irgendwo habe ich mal aufgeschnappt das die .dtors
Section bei EABI im ROM liegen darf. Habe ich nicht weiter
verfolgt da die dtors bei mir ohnehin stets leer ist (ctors in der
Regel auch).

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
let schrieb:

> C++ mit Codesourcery ist ein Krampf und funktioniert wenn man ein
> Projekt entsprechend eingerichtet hat mit keinem anderen Compiler.

Kannst du das etwas näher erklären?

Autor: let (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Linkerfehler wegen fehlender _sbrk(), _exit(), _atexit(), ...
Nachdem ich einen Stub geschrieben hatte kamen zwei neue Fehler
wegen fehlender Funktionen. Danach meckerte er fehlendes 'CS3' Gedöns
an - eine Spezialität der Codesourcery Compiler.

Mit Yagarto waren die Fehlermeldungen verschwunden. Die Stubs brauche
ich bei dem nicht. Bei C-Programmen waren die Compiler abgesehen vom
Stack-Alignment untereinander austauschbar. memcpy() scheint bei CS
aber schneller zu sein.

CS Version müsste die 2009-01 gewesen sein. Bin inzwischen auf Win7
und habe CS gar nicht erst installiert.

Autor: Lasse S. (cowz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

danke für die Antworten. Ich habe jetzt die von mthomas empfohle 
Toolchain runtergeladen (CodeSourcery) und kann das Beispielprojekt von 
ST auch mit dem Makefile compilieren.

Jetzt würd ich mich nur noch über ein Eclipse-Projektrahmen freuen, gibt 
es sowas (Das er mir zumindest das Makefile alleine erzeugt)? Ich kenne 
das halt von den AVRs, da kann man dann auch gleich 
Compilereinstellungen im Projektdialog setzen.

Gruß Lasse

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




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

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