Eclipse GNU ARM Plug-in für STM32

[Michael N. (much)]

Hallo,

ich versuche gerade mein STM32 Value line discovery board unter Linux 
zum Laufen zu bringen. Dazu würde ich gerne Eclipse verwenden da ich es 
schon für meine AVR-Projekte verwende.
Dazu habe ich jetzt das "GNU ARM Plug-in" installiert. Wenn ich ein 
neues Projekt erstelle wird der Compiler aber anscheinend nicht 
gefunden. In der Übersicht der installierten Pakete steht aber ein 
Eintrag "GNU ARM C/C++ Cross Compiler".
Muss ich den Compiler jetzt doch extra installieren oder muss ich nur 
den richtigen Pfad zum Compiler angeben? Wenn letzteres der Fall sein 
sollte: In welchem Verzeichnis liegt denn nun der Compiler?

[Christian K. (the_kirsch)]

Musste bei mir auch den Pfad zur Toolchain im Eclipse eintragen. Danach 
hat er die Tollchain erkannt und sie beim erzeugen eines neuen Projekt 
angeboten.

Das war bei mit aber unter Windows, und die Toolchain hatte ich auch nur 
aus einem ZIP-Archiv entpackt.

[Michael N. (much)]

Christian K. schrieb:
> Musste bei mir auch den Pfad zur Toolchain im Eclipse eintragen. Danach
> hat er die Tollchain erkannt und sie beim erzeugen eines neuen Projekt
> angeboten.

Ich hab den Compiler im System nirgends finden können. Deshalb hab ich 
mir diesen jetzt separat heruntergeladen und installiert. Dabei bin ich 
auf einen Hinweis gestoßen, dass der Compiler in keinen Systempfad aus 
der PATH-Variable installiert werden darf. Es scheint wohl Probleme zu 
geben wenn mehrere Versionen des Compilers installiert sind. Daher macht 
es durchaus Sinn, dass der Pfad manuell eingetragen werden muss.

Christian K. schrieb:
> Das war bei mit aber unter Windows, und die Toolchain hatte ich auch nur
> aus einem ZIP-Archiv entpackt.

Ich habs jetzt auch mal versucht unter Windows zum Laufen zu kriegen. 
Allerdings hab ich dort Probleme mit dem Treiber. Ich kann ihn zwar 
installieren, aber wenn ich das Discovery-Board einstecke wird es 
trotzdem nur als Massenspeichergerät erkannt. Darf man fragen mit 
welcher Windows Version du arbeitest? Der PC in meiner Werkstatt ist 
schon ein eitwas älteres Semester und läuft noch mit Windows XP. 
Vielleicht liegt es ja auch daran.

[Kirsch (Gast)]

Michael N. schrieb:
> Ich kann ihn zwar
> installieren, aber wenn ich das Discovery-Board einstecke wird es
> trotzdem nur als Massenspeichergerät erkannt. Darf man fragen mit
> welcher Windows Version du arbeitest?

Das ist wieder ein anderes Problem.
Ich Debugge und Flash über JTAG, nutze dazu ein Olimex ARM-USB-OCD. Und 
zum Debuggen den OpenOCD-Server, der als Bindeglied zwischen den GDB und 
dem JTAG-Tool dient.

[Bernd K. (prof7bit)]

Michael N. schrieb:
> Ich hab den Compiler im System nirgends finden können. Deshalb hab ich
> mir diesen jetzt separat heruntergeladen und installiert.

Ich hab bei mir einfach das offizielle Launchpad-Repository von 
gcc-arm-none-eabi zu den Paketquellen hinzugefügt und ganz normal über 
den Paketmanager installiert wie es sich gehört.

> Dabei bin ich
> auf einen Hinweis gestoßen, dass der Compiler in keinen Systempfad aus
> der PATH-Variable installiert werden darf.

Nein, der gehört natürlich in den Pfad wo er hingehört. Nach obiger 
Installation ist er dort auch.

> Es scheint wohl Probleme zu
> geben wenn mehrere Versionen des Compilers installiert sind.

Du willst ja nicht mehrere verschiedene Versionen davon installieren, 
wozu auch?

[Vincent H. (vinci)]

Bernd K. schrieb:
>> Dabei bin ich
>> auf einen Hinweis gestoßen, dass der Compiler in keinen Systempfad aus
>> der PATH-Variable installiert werden darf.
>
> Nein, der gehört natürlich in den Pfad wo er hingehört. Nach obiger
> Installation ist er dort auch.


Der Pfad sollte definitiv nicht global angegeben werden. Das kann bei 
Verwendung verschiedener Compiler nur zu Problemen führen. Z.B. 
CodeSourcery und GCC

[Bernd K. (prof7bit)]

Vincent H. schrieb:
> Z.B.
> CodeSourcery und GCC

Dann würde ich eher den selten gebrauchten Exoten (CodeSourcery) separat 
installieren und den offiziellen aktuellen arm-none-eabi-gcc in den 
Pfad. Das ist aber eh ein Sonderfall, die wenigsten brauchen wirklich 
zwei verschiedene Versionen des selben Compilers. Wie gesagt, unter 
Linux ist es üblich die Tools im Pfad zu haben und so verhält sich das 
auch hier. Alles andere erzeugt nur unnötige Komplikationen.