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
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
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.
Hi, eine ziemlich genaue Auflistung der Feature-Unterschiede gibt's hier: http://www.atollic.com/index.php/truestudio/featurecomparison 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
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.
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
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/).
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
CodeSourcery gibt's auch für Linux. In dem Fall dürfte das die empfehlenswerte weil besser gepflegte Version sein.
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
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).
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?
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.
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
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.