Announcement: there is an English version of this forum on Sehr geehrtes Forum, ich richte mir zurzeit das AVR Studio 4 auf meinem PC mit Windows 7 ein. Nun stehe ich vor einem Problem: Ich habe mir das AVR Studio 4 Version 4.19 installiert. Daraufhin habe ich ein C-Programm erstelt und wollte dieses auf meinen Controller (ATMega88) programmieren. Beim Ausführen des Befehls "Build Active Configuration" kommt jedoch stets eine Fehlermeldung: " gcc plug-in: No AVR Toolchain installation found. The AVR GCC plug-in can still be used if you set up your own build tools. " In einem anderen Forumsbeitrag habe ich gelesen, dass dieses Problem mit der AVR Toolchain zu tun hat. Ich habe mir daraufhin die AVR 8-Bit GNU Toolchain Version 3.4.3 heruntergeladen. Nun habe ich eine .sh Datei. Was muss ich jetzt mit dieser Datei tun? Muss ich diese in das AVR Studio "integrieren" und wenn ja wie? Es sei noch gesagt, dass ein Programm in Assembler-Sprache kompilliert und in den Controller geschrieben werden kann. Nur bei C-Programmen existiert dieser Fehler. Ich bin über jeden Tipp dankbar.
uC_gast schrieb: > Nun habe ich eine .sh Datei Die ist bestimmt für Linux. Installiere doch eine aktuelle Version vom Atmel Studio, da sind die Compiler dabei.
Fürs problemlose Installieren brauchst du diese Toolchain: https://sourceforge.net/projects/winavr/files/WinAVR/20100110/ zuerst dies installieren, dann das AVR Studio. Allerdinge haben schon viele die Erfahrungen gemacht dass AVR Studio 4.19 nicht problemlos funktioniert. Auch bei mir. Daher empfiehlt es sich im Zweifelsfall auf 4.18 zurückzugehen.
Vielen Dank für die schnellen Antworten. Ich habe nun sowohl das AVR Studio als auch die Toolchain komplett deinstalliert. Ich habe daraufhin die von Frickelfritze vorgeschlagene Toolchain installiert. Anschließend noch das AVR Studio v4.19 und es funktioniert immer noch nicht. Nun habe ich das AVR Studio v4.19 deinstalliert und die Version 4.18 installiert --> es kann trotzdem kein C-Programm kompilliert werden. Die Fehlermeldung bzgl. einer fehlenden AVR Toolchain ist nun verschwunden. Beim Kompillieren erscheint nun folgendes: make: Interrupt/Exception caught (code = 0xc00000fd, addr = 0x4217b3) Build failed with 1 errors and 0 warnings... make: Interrupt/Exception caught (code = 0xc00000fd, addr = 0x4217b3) Build failed with 1 errors and 0 warnings... Es wird folglich auch keine Hex-Datei erzeugt. Müssen zusätzlich noch Einstellungen vorgenommen werden? Was mach ich falsch? Bitte um Hilfe. Vielen Dank im Vorraus.
Bei mir funktioniert AVR Studio 4.18 unter Win7 Professional problemlos, sogar in Coexistenz mit Atmel Studio 7. uC_gast schrieb: > Was mach ich falsch? Nichts erst mal .... Zeige mal den Installationspfad deines Studio 4.18 und das deiner Winavr2010.
WinAVR befindet sich im folgenden Ordner: C:\Program Files (x86)\WinAVR Das AVR Studio befindet sich dort: C:\Program Files (x86)\Atmel Ich habe zusätzlich noch eine AVR Toolchain installiert. Diese ist direkt von Atmel und ist die Version 3.2.3 . Leider blieb dieser Versuch erfolglos.
Vielleicht noch wert zu erwähnen ist, dass im Ordner eines Projektes ein default Ordner angelegt wird. Ich bin gewohnt dass in diesem die entsprechende Hex-Datei abgelegt wird. Es befindet sich dort jedoch nur eine Makefile. Der Dateipfad zum Projektordner war ursprünglich ziemlich lang. Ich habe nun ein neues Projekt erstellt mit sehr kurzem Dateipfad. Leider blieb auch dieser Versuch ohne Erfolg. Gibt es weitere Vorschläge? Gruß
uC_gast schrieb: > WinAVR befindet sich im folgenden Ordner: > C:\Program Files (x86)\WinAVR Mach alles nochmal und lass dem Winavr sein Default- Installationsverzeichnis (das ist c:\WinAVR-20100110) uC_gast schrieb: > Es befindet sich dort jedoch nur eine Makefile. Klar, der Ablauf ist ja über das Starten des Make nicht hinausgekommen, das Make stürzt ja schon ab, nicht der Compiler. Könnte sein dass irgendein Teil nicht mit dem Windows-Programm- Pfad zurechtkomt (Zugriffsrechte oder Blanks in Pfaden).
Frickelfritze schrieb: > Mach alles nochmal und lass dem Winavr sein Default- > Installationsverzeichnis (das ist c:\WinAVR-20100110) Das war das Problem. Habs nochmal mit dem angegebenen Dateipfad neu installiert und es funktioniert. Besten Dank!
Hallo, das Problem hatte ich schon zu W2000 Zeiten als die 4.18 noch aktzelle war. Wenn WinAVR nicht in c:\WinAVR-20100110 lag ging nicht viel. Auch die probleme mit der 4,19 kann ich bestätigen. Ich habe die Konmbi auch hier unter Win7/64 für ein paar alte Projekte immernoch parat liegen. Gruß aus Berlin Michael
Angehängte Dateien:
Funktioniert auch moderner: ************************** Auf Win7/64 mit AVRStudio4 - v4.19 - Build 716 und AVR-GCC 8.2.0 for Windows 64 bit von http://blog.zakkemble.net/avr-gcc-builds/ Meine diversen AVR8 Toolchains sind immer in C:\Atmel_Toolchain\AVR8_GCC\... Im Gegensatz zu anderen Builds verfügt die oben verlinkte Version auch über ein make.exe. Getestet mit einem C-Minimalprogramm und avr-g++.exe und make.exe Nicht getestet mit einem C++-Programm unter AVRStudio 4.19
MitLeserin schrieb: > Meine diversen AVR8 Toolchains sind immer in > C:\Atmel_Toolchain\AVR8_GCC\... ^ ^ Das ist der springende Punkt, warum's funktioniert: Es sind keine Leerzeichen an diesen Stellen. Mit Leerzeichen in Pfaden kann der Schrott schlicht nicht vernünftig umgehen. Bei einem deutschsprachigen WindowsXP(32bit) hieß das Standard-Programmverzeichnis schlicht "Programme". Da konnte man also selbst diesen Schrott so installieren, wie Microsoft sich das gedacht hat. Bei allem ab Vista mit dieser unsäglichen lausigen "Virtualisierung" der Standard-Verzeichnisnamen (die nur im Explorer greift) heißt das Verzeichnis aber nicht mehr "Programme", sondern in Wirklichkeit "program files" bzw. "program files (x86)". Und da sind nunmal leider überall Leerzeichen drinne. Hier ergänzen sich also zwei lausige Implementierungen zu einer Kombination, die einfach nicht funktioniert.
c-hater schrieb: > MitLeserin schrieb: > >> Meine diversen AVR8 Toolchains sind immer in >> C:\Atmel_Toolchain\AVR8_GCC\... > ^ ^ > > Das ist der springende Punkt, warum's funktioniert: Es sind keine > Leerzeichen an diesen Stellen. Mit Leerzeichen in Pfaden kann der > Schrott schlicht nicht vernünftig umgehen. Dieser "Schrott" kann mit Leerzeichen in Pfaden sehr wohl umgehen, man muss sie eben per Escape als solche kenntlich machen. Angenommen man hat einen Unterordner "some dir" in dem sich eine Datei "script.sh" befindet, die man ausführen möchte, dann bekommt man mit
1 | ./some dir/script.sh |
die folgende Fehlermeldung (je nach Shell)
1 | bash: ./some: Datei oder Verzeichnis nicht gefunden |
Das ist auch völlig logisch und muss auch so sein, weil durch ein Leerzeichen Programmaufruf und Argumente getrennt werden und die shell in diesem Fall versucht das Programm "some" mit dem Argument "dir/script.sh" auszuführen, was eben nicht existiert. Hingegen kann man mit
1 | ./some\ dir/script.sh |
das Programm ganz normal ausführen. c-hater schrieb: > Hier ergänzen sich also zwei lausige Implementierungen zu einer > Kombination, die einfach nicht funktioniert. Die beiden lausigen Implementierungen sind die von AVR-Studio bzw. WinXP, Leerzeichen nicht zu escapen und die von Vista aufwärts, Leerzeichen in Standardpfade zu packen. Die Generation Mausschubser denkt halt das sei Fortschritt in seiner reinsten Form, wenn man Leerzeichen in Pfaden drin stecken hat. Aufgrund der oben dargelegten Problematik ist das aber eben nicht so prickelnd. Wenn ich mal unter Windows etwas mache, dann packe ich mir immer alle Programme, die nur ansatzweise per Skript ausgeführt werden sollen, wie etwa Compiler und dergleichen in C:\tools . Das tut nicht weh und ist zum Glück noch einfach so möglich.
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.