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
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.
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.
Okay, mein fehler... n restart nach der pfad-eingabe ist zwingend erforderlich... jetzt läufts...
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...
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".
"Wenn man selbst geklaute Schnitzel frisst, kann man anderen gut in die Suppe spucken."
@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...
> entweder ich bin zu doof
Du bist ja sogar zu doof, die Shifttaste zu finden.
SCNR.
> Du bist ja sogar zu doof, die Shifttaste zu finden.
eine ähnliche antwort hatte ich erwartet...
Wow, Mausschiebergeneration vs Leute die auch wissen was unter der Oberfläche vorgeht... Wartet ich muss nur noch das Popkorn holen...
> 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.
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.
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.
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.
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.