www.mikrocontroller.net

Forum: Compiler & IDEs WinARM einrichten


Autor: Andreas Weschenfelder (Firma: andreas-weschenfelder.de.vu) (rupplyn) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

bin gerade dabei winarm einzurichten.

hab das zip entpackt und den path eingetragen.

beim kompilieren erhalte ich folgende meldung:

> "make" all

-------- begin --------
process_begin: CreateProcess((null), arm-elf-gcc --version, ...) failed.
make (e=2): Das System kann die angegebene Datei nicht finden.

make: *** [gccversion] Error 2

> Process Exit Code: 2
> Time Taken: 00:00

habe ich noch etwas vergessen einzutragen?

(wollte zum testen das beipsiel aus winarm "pc2138_uart0" 
kompilieren...)

Gruß Andi

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arbeitest du bereits mit Vista?

Autor: Andreas Weschenfelder (Firma: andreas-weschenfelder.de.vu) (rupplyn) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nein, XP

Autor: Martin Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie ich im Readme an fast erster Stelle erwähnt habe, besteht die 
Installation auch darin die Pfade zu WinARM/bin und WinARM/utils/bin in 
die PATH Umgebungsvariable aufzunehmen. Falls zu kompliziert: yagarto 
(google findet) kommt mit setup-Programm. WinARM-Beispiele sollten auch 
mit den GNU-tools (arm-elf-gcc und "Zubehör") in yagarto erstellbar sein 
- habe es aber nicht ausprobiert. Viel Unterschied gibt es "unter der 
Haube" nicht.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pfadprobleme? Vielleicht hilft die Anleitung aus dem WinAVR Paket weiter 
(WinARM ist ähnlich). Und nach dem Setzen des Pfades würde ich einen 
Restart machen, damit der Pfad Windows auch garantiert bekannt ist.

2.3 PATH Environment Variable

There are two directories in WinAVR that contain executable programs. If 
<install> is your install directory then these two directories are:

<install>\bin
<install>\utils\bin

Anmerkung: <install> = c:\WinAVR oder ähnlich. Was hast du hier benutzt? 
Ich habe auch schon von Problemen mit () in Pfadnamen gelesen.

The <install>\bin directory contains the software development toolset 
proper. This includes GNU binutils, GCC, and other programs.

The <install>\utils\bin contains many miscellaneous Unix or GNU programs 
that are built for Windows. This includes sh (bash) and make among a 
host of other things.

For your operating system to easily locate these directories, they must 
be put at the beginning of the PATH environment variable. WinAVR can do 
this automatically upon installation, if you selected this option.

These programs are put into two seperate directories in case you want to 
use a different set of utility programs than the set that comes with 
WinAVR.

If you do not wish to use the utilities that comes with WinAVR, remove 
the <install>\utils\bin directory from your PATH environment variable.

For Windows 95 and 98 users, see the autoexec.bat file in the root drive 
where your OS is installed. This is usually in C:\.

For all other Windows users, the WinAVR installer modifies this registry 
key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session 
Manager\Environment\Path

IMPORTANT:

On Windows NT/2K/XP you must have Administrator priviledges for the 
installer to automatically put these directories in your PATH 
environment variable.

Autor: Andreas Weschenfelder (Firma: andreas-weschenfelder.de.vu) (rupplyn) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay, mein fehler...

n restart nach der pfad-eingabe ist zwingend erforderlich...

jetzt läufts...

Autor: guro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi,
warum gcc? ich hab' mich auch mal damit rumgeärgert. makefiles basteln 
etc. das taugt nix. openocd für flash-downloads ist ganz okay, aber 
spätestens wenn du debuggen willst (mit gdb oder insight) kriegste den 
horror.
ich benutze für arm-programmierung den iar (30 tage testversion).
integrierte ide, er kann elf-files oder flat binaries erzeugen und 
vieles mehr. ich hab' den iar in einer präparierten vmware maschine 
installiert, die immer mit dem gleichen datum startet, d.h. die zeit 
läuft nie ab :-)
die iar-testversion hat kaum beschränkungen, nur der misra-c checker 
geht nicht, aber das braucht normalerweise kein mensch.
debuggen auf dem target geht perfekt (über usb-jlink), da können die 
ganzen freeware-sachen wie 'insight' nicht gegen anstinken...

btw: die arm-tools von keil sollen auch ganz gut sein (keil wurde ja von 
arm aufgekauft und die setzen jetzt den original arm-compiler ein)...

noch was: von m$ gibt es !!kostenlos!! 'visual studio embedded' 
eigentlich für windows-ce, aber hat schon mal jemand den für andere 
arm-basierte targets eingesetzt? wäre vielleicht eine alternative...

Autor: Martin Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Normalerweise versuche ich solche Beitrage, die nah an der Grenze zum 
Getrolle (oder schon drueber hinweg) sind, zu ueberlesen. Diesmal 
dennoch:

>warum gcc?
War wohl nicht wirklich als Frage gemeint, sondern nur als Einstieg zum 
darauf folgenden abwettern.

Weil es ein guter Compiler ist und zudem auch "kostenguenstig". gcc 
steht eigentlich für die "GNU Compiler Collection", darin der 
gnu-c-Compiler (auch mit gcc abgekürzt) aber auch der GNU C++ compiler 
(g++) und diverse andere (Fortran, Java, Ada, D etc.). Der Compiler 
selbst (oder Sammlungen in den vorgefertige Binaries davon 
zusammengepackt wurden) hat nichts mit makefiles, IDE oder Debugger zu 
tun. Es gibt also keinen Grund das in einen Topf zu werfen. Und 
ausgehend davon die Trolltastatur anzustoepseln.

>ich hab' mich auch mal damit rumgeärgert. makefiles basteln
>etc. das taugt nix.
"gcc" und makefiles sind "zwei Paar Schuhe". Es gibt einige Software, 
die Teile der gcc im Hintergrund nutzen kann und bei der keine makefiles 
oder im Hintergrund ("unsichtbar") generierte makefiles genutzt werden. 
DevC++, Code:Blocks, AVRStudio, Crossworks um nur einige zu nennen. 
Nicht wenige Tools und Anwender nutzen einfach ein batch-File, ein 
shell-script oder einen "system()"-Aufruf statt make.

Ich finde ein makefile im Texteditor uebersichtlicher, v.a. wenn man 
viel Optionen oefter mal umstellen muss. Schicke IDEs mit 1001 
Dialogboxen sind eher unuebersichtlich. Welche Einstellung in welchem 
Dialog schaltet welche Option? - jedes Mal ein neuer "Spass" mit 
VStudio, bei Einstellung die man noch nie vorher gebraucht oder nur 
selten braucht). Aber gut, das ist genauso subjektiv wie "makefiles 
basteln taugt nix".

Ohne nähere Beschreibung des "taugt nix" kann man sich solche Aussagen 
auch gleich sparen. Subjektive Pauschalisierung und hilft nicht weiter.

> openocd für flash-downloads ist ganz okay, aber
> spätestens wenn du debuggen willst (mit gdb oder insight)
> kriegste den horror.

Debugger und gcc sind "zwei Paar Schuhe". Ohne nähere Beschreibung des 
"horror"s kann man sich solche Aussagen auch gleich sparen. Subjektive 
Pauschalisierung und hilft nicht weiter.

> ich benutze für arm-programmierung den iar
> (30 tage testversion). integrierte ide, er kann elf-files oder
> flat binaries erzeugen und vieles mehr. ich hab' den iar in
> einer präparierten vmware maschine installiert, die immer mit
> dem gleichen datum startet, d.h. die zeit läuft nie ab :-)

IDE und gcc sind "zwei Paar Schuhe". Datum zurücksetzen bei 
Trial-Versionen ist zumindest in einer rechtlichen Grauzone. Nicht 
wirklich geschickt sich mit solche "Tricks" in einem oeffentlichen Forum 
zu ruehmen. Ausserdem gibt es die auf 32kB(?) beschränkte 
Quickstart-Version von IAR, damit ist man zumindest aus der Grauzone. 
Eine kommerziell nutzbare unbeschränkte Version von 
IAR-Embedded-Workbench für ARM kostet allerdings auch "ein wenig".

> die iar-testversion hat kaum beschränkungen, nur der misra-c
> checker geht nicht, aber das braucht normalerweise kein mensch.
> debuggen auf dem target geht perfekt (über usb-jlink), da können
> die ganzen freeware-sachen wie 'insight' nicht gegen anstinken...

Welchen "ganzen freeware-sachen"? Es gibt ausser insight noch einige 
andere gdb-"Frontends". Auch das hat dennoch nichts mit dem Compiler zu 
tun und auch nichts mit einer Sammlung der "GNU-Toolchain". Ohne nähere 
Beschreibung des "nicht gegen anstinken" kann man sich solche Aussagen 
auch gleich sparen. Subjektive Pauschalisierung und hilft nicht weiter.

> btw: die arm-tools von keil sollen auch ganz gut sein
> (keil wurde ja von arm aufgekauft und die setzen jetzt den
> original arm-compiler ein)...

Keil uVision/Realview-Compiler habe ich ein wenig ausprobiert und jemand 
der die Absicht hat "kommerzielle" Enwicklungswerkzeuge zu kaufen, 
sollte auch diese Tools etwas testen. Eine kommerziell nutzbare 
unbeschränkte Version kostet allerdings auch "ein wenig".



Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Wenn man selbst geklaute Schnitzel frisst, kann man anderen gut in die 
Suppe spucken."

Autor: guro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Martin
ich hab' schon öfters frust mit gnu-tools gehabt, gcc, binutils, gdb 
etc. für ARM, v850, x86, und S12. entweder ich bin zu doof dazu oder das 
taugt alles nix!
vielleicht ist es toll unter unix und linux, aber für alle anderen 
prozessoren und plattformen gibt's wesentliche bessere tools, die 
stressfrei funzen...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> entweder ich bin zu doof

Du bist ja sogar zu doof, die Shifttaste zu finden.

SCNR.

Autor: guro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Du bist ja sogar zu doof, die Shifttaste zu finden.

eine ähnliche antwort hatte ich erwartet...

Autor: Wolfram (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wow,
Mausschiebergeneration vs Leute die auch wissen was unter der Oberfläche 
vorgeht...

Wartet ich muss nur noch das Popkorn holen...

Autor: guro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Mausschiebergeneration vs Leute die auch wissen was unter der Oberfläche
vorgeht...

das schliesst sich aber nicht aus.
wer einen klicki-bunti linux desktop benutzt, muss nicht zwangsläufig 
null plan von den eingeweiden haben.

Autor: Bebe Müller (Firma: Student) (bebe84)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi an alle,

Ich bin relativ neu mit dem freeRTOs,passen sie deshalb nicht an meinen 
dummen Fragen auf und helfen Sie mir bitte.
Meine Hauptaufgabe besteht darin den FreeRTOS auf dem LPC2368 mit der 
Keil IDE zu testen.Ich habe den projekt vom 
"freeRTOS.org/ARM7_LPC2368_Rowley"  genommen, dann habe ich den Kompiler 
auf GCC geändert (denn der vorherige kompiler war Realview) .Nach dem 
Kompilierung habe ich solche Fehler :
-arm-uclibc-as: unrecognized option `-gdwarf-2'.
-arm-uclibc-gcc: lpc2300.o: No such file or directory.

Bitte was muss ich tun,um diese Fehler los zu werden?bitte helfen sie 
mir,es ist dringend.

Autor: Bebe Müller (Firma: Student) (bebe84)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi an alle,

Ich bin relativ neu mit dem freeRTOs,passen sie deshalb nicht an meinen
dummen Fragen auf und helfen Sie mir bitte.
Meine Hauptaufgabe besteht darin den FreeRTOS auf dem LPC2368 mit der
Keil IDE zu testen.Ich habe den projekt vom
"freeRTOS.org/ARM7_LPC2368_Rowley"  genommen, dann habe ich den Kompiler
auf GCC geändert (denn der vorherige kompiler war Realview) .Nach dem
Kompilierung habe ich solche Fehler :
-arm-uclibc-as: unrecognized option `-gdwarf-2'.
-arm-uclibc-gcc: lpc2300.o: No such file or directory.

Bitte was muss ich tun,um diese Fehler los zu werden?bitte helfen sie
mir,es ist dringend.

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

Bewertung
0 lesenswert
nicht lesenswert
Da hat google ja mal wieder hervorragend verwiesen und in einen Thread 
geleitet, der genauso so aktuell wie passend zum Problem ist. Wie auch 
immer, ein paar Hinweise: Es handelt sich wohl um das GNU-packet vom 
Keil, kenne zumindest ein anderes mit arm-uclibc-Prefix. Das enthält 
sehr alte Version der GNU Tools und eine für "bare-metal"-Entwicklung 
eher unübliche libc (man beachte auch deren Lizenz).

1.) Abklären, ob der Aufgabensteller wirklich Code für GNU-Compiler 
haben will. Evtl. ist mit "Keil IDE" auch das Packet aus IDE mit 
dazugehörigen Realview-Tools gemeint. Wenn Realview: Einarbeiten und bei 
Problemen z.B. Forum auf keil.com oder Direkt beim Support von Keil/ARM.

Wenn nicht:
Wirklich nur "neu mit dem FreeRTOS" oder mit GNU tools im Allgemeinen? 
uVision ruft nur arm-*-as, arm-*-gcc mit den in den Dialogboxen 
ausgewählten Parametern. Kann man das Debug-Format nicht konfigurieren?

2.) Das uralte gcc-Packet, das Keil/ARM wohl immer noch auf der 
Eval-Download-Seite anbietet, um - wilde Vermutung - sicherzustellen, 
dass man ein möglichst schlechtes Bild von GNU tools bekommt und dann 
geschwind und umsatzfördernd auf Realview umschwenkt, in die Tonne 
treten (=deinstalliern).
(Der alte Kram wäre gar nicht nötig. Wer es sich leisten kann, kauft 
deren Produkt und erhält mit den Keil-Tools den guten Debugger und 
Simulator. Allein diese rechtfertigen der Kauf, von dem besseren - aber 
nicht viel besseren - Compiler mal abgesehen. Na ja, off-topic)

3.) Aktuelleres MDK-ARM kaufen oder Eval-Version herunterladen, falls 
nicht-kommerzielle Entwicklung. Unterstützung für aktuelle GNU Tools ist 
in neuen uVision stark verbessert (er auch immer diesen Thread wieder 
ausgräbt beachte bei "neu" das Schreibdatum).

4.) Aktuelle Version einer vorkompilierten GNU Toolchain besorgen. Z.B. 
Codesourcery G++ für ARM "bare-metal" lite. Lite-Version ist gratis und 
wenn es gar zu arg wird, kann man bei CS Support erkaufen und muss nicht 
auf Antworten in Foren hoffen. Einstellung für CS G++ wird auch in den 
Beispielen von Keil erläutert. Alternativen ohne "kommerziellen" 
Support: DevKitARM, Yagarto, WinARM u.v.a.m.

5.) Beispiele/Application-Note von keil.com für uVision + 
Codesourcery-Pakete herunterladen, egal für welchen Controller, erstmal 
damit etwas spielen und lernen was gemacht wird. Dazu braucht man 
erstmal keine passende Hardware. Damit vertraut machen, wie 
Linker-Script, Linker, Assembler, Startup-Code, Compiler und 
Anwendungscode zusammenhängen. Optionen in der Anleitung von gcc 
(gcc.gnu.org) und den binutils (linker-script) nachschlagen.

6.) Kleine Beispiele für LPC23xx schreiben und etwas mit der Hardware 
spielen.

Dann sollte das Eis gebrochen sein. Erst dann weiter mit dem RTOS Code, 
sind sonst m.M. etwas zu viele Baustellen auf einmal. Da hilft auch kein 
"es ist dringend".

Bei Problemen mit uVision, GNU-Tools und Assembler-File in 
Unterverzeichnissen: Keil-Suppot anschreiben, die haben bereit eine 
Lösung dafür.

Nun denn. Schon wieder eine Menge Geschreibsel. Hoffe, es hilft.

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.