Guten Tag, ich habe ein altes AVR Studio4 Projekt. Ich muss eine kleine Änderung machen. Habe das Avr Studio und das WinAVR-2010 installiert. Aber es wird mir kein Neues Hexfile generiert. Wie löse ich das Problem`?
Vimar schrieb: > Aber es wird mir > kein Neues Hexfile generiert. Dann muss es ja irgendwelche Fehlermeldungen geben.
Hallo, oder der Haken für HEX-File in den Projektoptionen ist nicht gesetzt. Gruß aus Berlin Michael
Hast du den gesamten Ordner als ZIP zur Verfügung oder nur die Quellfiles? - Ordner: in dem vorhandenen *.aps-File sind absolute Pfade drin, zumindest der Ordnername muss gleich sein. Anderfalls: vorgehen wie im nächsten Punkt. - nur die Quellen: neues Projekt erstellen, die Files hineinkopieren, die Files im AVR-Studio mit 'add existing files' einbinden. Welche Fehlermeldung gibt es, was zeigt das Build-Fenster?
Angehängte Dateien:
-
avr.JPG
92 KB
Diese Info gibt das AVR Studio4 aus. Das Hex ist immer noch aus dem Jahr 2008 HildeK schrieb: > Hast du den gesamten Ordner als ZIP zur Verfügung oder nur die > Quellfiles? > - Ordner: in dem vorhandenen *.aps-File sind absolute Pfade drin, > zumindest der Ordnername muss gleich sein. Anderfalls: vorgehen wie im > nächsten Punkt. > - nur die Quellen: neues Projekt erstellen, die Files hineinkopieren, > die Files im AVR-Studio mit 'add existing files' einbinden. > > Welche Fehlermeldung gibt es, was zeigt das Build-Fenster? Ja habe ein Zip des gerammten Projekt Ordner Ich vermute das das AVR Studio nicht richtig läuft
Angehängte Dateien:
-
avr.JPG
190 KB
HildeK schrieb: > neues Projekt erstellen, die Files hineinkopieren, > die Files im AVR-Studio mit 'add existing files' einbinden. Habe ein neues leeres Projekt erstellt aber selbst das wird nicht kompiliert.... WAS fehlt da noch?
Vimar schrieb: > Habe ein neues leeres Projekt erstellt aber selbst das wird nicht > kompiliert.... > > WAS fehlt da noch? Die Pfade zu den Tools, also zu avr-gcc und zu make. Einzustellen über die Projektoptionen->Custom options->externe Tools. Den Haken bei AVR-Toolchain raus und dann die beiden Pfade setzen. Achtung: Das WinAVR-Zeugs muss in einem Pfad installiert sein, der keine Leerzeichen enthält, sonst funktioniert's trotz korrekt gesetzter Pfade immer noch nicht...
c-hater schrieb: > Die Pfade zu den Tools, also zu avr-gcc und zu make. Einzustellen über > die Projektoptionen->Custom options->externe Tools. Den Haken bei > AVR-Toolchain raus und dann die beiden Pfade setzen. > > Achtung: Das WinAVR-Zeugs muss in einem Pfad installiert sein, der keine > Leerzeichen enthält, sonst funktioniert's trotz korrekt gesetzter Pfade > immer noch nicht... Danke für den Tipp aber auch das erzeugt einen Fehler
Also bei mir ist in den Custom Options ein Haken bei "Use AVR Toolchain". Ich verwende allerdings die 4.18 und hatte mit 4.19 an der Stelle auch Probleme. Bin dann zurück auf 4.18.
Vimar schrieb: > Danke für den Tipp aber > auch das erzeugt einen Fehler Ja, aber einen völlig anderen, der Compileraufruf funktioniert jetzt offensichtlich. Dein minimales Beispielprogramm läßt sich so auch übersetzen. Also: der neue Fehler steckt in dem Programm, was du uns nicht gezeigt hast. Wenn du uns das weiterhin nicht zeigen magst, musst du das Problem also alleine lösen. So einfach ist das... Tipp: Der Ausgabe läßt sich immerhin entnehmen, dass der Fehler vor oder in Zeile 20 von main.c stecken muss. Das schränkt den Suchraum doch vermutlich schon erheblich ein...
Angehängte Dateien:
-
beispiel.PNG
240 KB
c-hater schrieb: > Also: der neue Fehler steckt in dem Programm, was du uns nicht gezeigt > hast. Wenn du uns das weiterhin nicht zeigen magst, musst du das Problem > also alleine lösen. So einfach ist das... > > Tipp: Der Ausgabe läßt sich immerhin entnehmen, dass der Fehler vor oder > in Zeile 20 von main.c stecken muss. Das schränkt den Suchraum doch > vermutlich schon erheblich ein... Ich versuche immer noch das Beispiel Program zu compilieren und das funktioniert nicht.
Bitte mal die ganze Fehlermeldung zeigen, nicht nur das Ende! Sieht nicht nach einem Fehler im Code aus. Mehr nach einem Problem in make. Ich erinnere mich dunkel, dass da ein Neustart des PC hilft...
Angehängte Dateien:
-
er.PNG
150 KB
Dr. Sommer schrieb: > Bitte mal die ganze Fehlermeldung zeigen, nicht nur das Ende! Sieht > nicht nach einem Fehler im Code aus. Mehr nach einem Problem in make. > Ich erinnere mich dunkel, dass da ein Neustart des PC hilft... Guten Morgen der Neustart hat auch nichts gebracht..... Hier die gesamte Ausgabe
Google kennt diese Fehlermeldung. Beitrag "WinAVR unter Windows 8.1 (64 bit)" http://www.avrfreaks.net/forum/windows-81-compilation-error https://forum.pololu.com/t/sync-with-child-child-died-before-initialization/5577/3
Angehängte Dateien:
-
Studio4_-_AVR-GCC_8.3.0.png
410 KB
Da funktioniert etwas grundsätzlich nicht richtig mit der Toolchain. Studio 4.19 funktioniert auch mit einer aktuellen Toolchain von http://blog.zakkemble.net/avr-gcc-builds/ Diese Toolchain enthält auch ein make.exe. Toolchain downloaden und entpacken. Ein Verzeichnis erstellen, so dass im Pfad keine LEERSTELLEN existieren Beispiel: ******** C:\Atmel_Toolchain\AVR8_GCC\ Toolchain dort speichern: C:\Atmel_Toolchain\AVR8_GCC\avr-gcc-8.3.0-x64-mingw Studio4 (Minimal-)Projekt erstellen und unter *********************************** Projekt|Configuration Options|Custom Options den Pfad und den Compiler.exe bzw. den Pfad und Make.exe eintragen. Im Studio4 muss der richtige Compiler.exe explizit benannt werden. Nur Pfad eintragen reicht nicht. Dasselbe gilt für Make.exe [ ] use AVR Toolchain bleibt LEER
A. B. schrieb: > Im Studio4 muss der richtige Compiler.exe explizit benannt werden. > Nur Pfad eintragen reicht nicht. Dasselbe gilt für Make.exe Laut seinem Bild oben hat er das richtig gemacht. > [ ] use AVR Toolchain bleibt LEER Das hängt meiner Erfahrung nach von der verwendeten Version 4.x ab. Da gibt es auf jeden Fall einen Unterschied zwischen 4.18 und 4.19. Und möglicherweise auch von der verwendeten Windows-Version. Vielleicht erzählt Vimar noch diese Details.
Bei mir funktioniert alles, egal ob ich obige ZIP-Datei des TE verwende oder ob ich selbst ein neues Projekt erstelle und den C-Quellcode des TE im Editor eingebe. Ich benutze AVR-Studio 4.19 Build 730 und WINAVR-20100110. Evtl. ist wichtig, beim Erstellen eines neuen Projektes als Erstes im Menu Project\Configuration Options die nötigen Einstellungen vorzunehmen, damit die Projektdatei und das später generierte Makefile auf Anhieb die richtigen Angaben enthalten.
Rainer V. schrieb: > Bei mir funktioniert alles, egal ob ich obige ZIP-Datei des TE verwende > oder ob ich selbst ein neues Projekt erstelle und den C-Quellcode des TE > im Editor eingebe. Ich benutze AVR-Studio 4.19 Build 730 und > WINAVR-20100110. Evtl. ist wichtig, beim Erstellen eines neuen Projektes > als Erstes im Menu Project\Configuration Options die nötigen > Einstellungen vorzunehmen, damit die Projektdatei und das später > generierte Makefile auf Anhieb die richtigen Angaben enthalten. Nö, das dürfte hier nicht das Problem sein. Du hast vermutlich einfach nur nicht (genausowenig wie ich) "-MF dep/main.o.d" als Parameter an den Compiler übergeben. Wozu auch sollte man das tun? Warum auch immer nun Vimar das tut (weiß er vermutlich selber nicht), das ist jedenfalls der Kern des Problems. Denn wenn man dies mit der Tatsache zusammenführt, dass die Fehlermeldung auf Zeile 20 von main.c verweist und das offensichtlich die letzte Zeile von main.c ist, dann wird man nach logischem Abwägen aller Möglichkeiten unweigerlich zu dem Schluß kommen, dass wohl der Compiler irgendein Problem damit hat, diese doofe "bin/main.o.d" zu schreiben. Als mögliche Ursachen kommen in Frage: das Verzeichnis existiert nicht (wozu auch immer diese Pfadangabe relativ sein mag...) und/oder der Benutzer hat in diesem Verzeichnis oder dem übergeordneten (unbekannten) keine Schreibrechte. Der geneigte C-Frickler im Allgemeinen und der gcc-Frickler im Besonderen sollte also einfach mal rauskriegen, wo 1. der Compiler nun genau diesen Mist hinschreiben will und 2., warum ihm das nicht gelingt... Vorher sollte er sich aber fragen: wozu brauch' ich diesen "-MF"-Kram eigentlich? Brauch' ich den wirklich? Sicher ist: um das Minimalbeispiel erfolgreich zu kompilieren, braucht man das nicht.
c-hater schrieb: > Wozu auch sollte man das tun? Kannst du keine Doku lesen? Um Header-Abhängigkeiten zu tracken. c-hater schrieb: > das ist jedenfalls der Kern des Problems Das ist nur ein Folgefehler. Wie schon erwähnt ist es ein Problem mit der MSys Runtime welches das Starten des Compilers verhindert, der dann weder die .o noch die .d Datei erzeugt. Ohne -MF wird zwar gar nicht erst versucht die .d anzulegen, aber die .o entsteht dann immer noch nicht. Und natürlich hat der TO das -MF nicht angegeben, sondern die IDE hat es automatisch erzeugt. Lösungen würden bereits verlinkt. Die Fehlermeldung ist bekannt. Also, hör auf Unfug zu verbreiten. Dein Beitrag ist so aggressiv wie sinnfrei.
Angehängte Dateien:
-
Studioversion.png
50 KB -
Customoptions.png
36 KB -
Build.png
11 KB
Dr. Sommer schrieb: > Also, hör auf Unfug zu verbreiten. Du erzählst Unsinn, zumindest weit überwiegend. > Das ist nur ein Folgefehler. Wie schon erwähnt ist es ein Problem mit > der MSys Runtime welches das Starten des Compilers verhindert Offensichtlicher Vollquatsch. Da ja sowohl ich also auch Rainer V. (rudi994) das Minimalbeispiel mit exakt der gegebenen Konfiguration (AVR Studio 4.19+WINAVR-20100110) problemlos kompilieren können, kann das ja wohl offensichtlich nicht den Tatsachen entprechen. > Ohne -MF wird zwar gar nicht > erst versucht die .d anzulegen, aber die .o entsteht dann immer noch > nicht. Natürlich, ich erhalte ja sogar eine *.elf und eine *.hex. Das wäre wohl kaum möglich, wenn schon die *.o nicht erzeugt werden könnte... > Und natürlich hat der TO das -MF nicht angegeben, sondern die IDE > hat es automatisch erzeugt. Ja, das stimmt immerhin, wie ein Blick in den dritten Screenshot zeigt. Ich habe das nirgendwo explizit angegeben (warum auch), also muss es die IDE gewesen sein.
c-hater schrieb: > Offensichtlicher Vollquatsch. Da ja sowohl ich also auch Rainer V. > (rudi994) das Minimalbeispiel mit exakt der gegebenen Konfiguration (AVR > Studio 4.19+WINAVR-20100110) problemlos kompilieren können, kann das ja > wohl offensichtlich nicht den Tatsachen entprechen. Habt ihr denn exakt die gleiche Windows Version mit exakt der gleichen Software und insbesondere exakt den gleichen ggf. hinein pfuschenden MSYS DLL's oder make.exe aus anderen Compiler Toolchains? Ich vermute, dass wenn Vimar die "sh -c avr-gcc.exe" einfach so direkt auf der cmd.exe ausführt es direkt crasht, egal ob mit -MF oder ohne. Das mit der fehldenden .d Datei ist eine Nebelkerze. Wie du siehst, kommen erst schon Fehlermeldungen von der MSYS Runtime bevor irgendwelche Meldungen bezüglich .d kommen. Wie du Experte sicher weißt, sollte man immer die erste Meldung bearbeiten, da die weiteren Folgefehler sein können. c-hater schrieb: > Natürlich, ich erhalte ja sogar eine *.elf und eine *.hex. Das wäre wohl > kaum möglich, wenn schon die *.o nicht erzeugt werden könnte... Du ja, aber Vimar nicht.
c-hater schrieb:
[...]
Ergänzend:
Offensichtlich ist das ebenfalls in den Projektoptionen angebbare
Ausgabeverzeichnis das übergeordnete Verzeichnis für das
"dep"-Verzeichnis.
Und sehr wahrscheinlich ist das Projektverzeichnis selber wiederum das
übergeordnete Verzeichnis für das Ausgabeverzeichnis.
Da in allen diesen Verzeichnissen der User wohl Schreibrechte hat, da er
ja das Projektverzeichnis selber angelegt und befüllt hat, bleibt als
wahrscheinlichste Ursache des Problems mal wieder diese lächerliche
Sache mit den Leerzeichen in Pfaden...
Wenn's nicht so traurig wäre, könnte man darüber herzhaft lachen.
@Vimar
Verschiebe das ganze Projektverzeichnis mal in einen Pfad, der keine
Leerzeichen enthält und versuch' es dann noch einmal. Natürlich musst du
das Projekt von der neuen Position erneut öffnen und nicht das der IDE
bereits bekannte und im Open-Dialog gelistete!
Dr. Sommer schrieb: > Wie du siehst, kommen erst > schon Fehlermeldungen von der MSYS Runtime bevor irgendwelche > Meldungen bezüglich .d kommen. Nö, genau das kann man im von Vimar geposteten Log eben NICHT sehen. Da sieht man vielmehr, dass der avr-gcc korrekt AUSGEFÜHRT wurde. Sagte zumindest erstmal die IDE. Aber auch die Exe selber bestätigt, dass sie immerhin korrekt genug lief, um eine Fehlermeldung loswerden zu können. Und sie konnte sich in ihrer Meldung ja sogar auf ein konkretes Detail versteifen, ihr blieb also genug Zeit zum Nachdenken...
c-hater schrieb: > bleibt als > wahrscheinlichste Ursache des Problems mal wieder diese lächerliche > Sache mit den Leerzeichen in Pfaden... Nö, ich habe das jetzt mal absichtlich herbeigeführt. Kompiliert immer noch genauso problemlos, unter Windows7 und unter Windows10. Also das Problem mit den Leerzeichen ist es hier definitiv nicht. Bleiben eigentlich nur noch irgendwelche Pfade oder sonstige Variablen im Environment...
c-hater schrieb: > Nö, genau das kann man im von Vimar geposteten Log eben NICHT sehen. Da > sieht man vielmehr, dass der avr-gcc korrekt AUSGEFÜHRT wurde. Sagte > zumindest erstmal die IDE. Woher weißt du, dass der GCC sich nicht einfach unverrichteter Dinge wieder beendet hat? Oder dass die Shell ihn nicht gar nicht erst gestartet hat? Es sieht so aus als würde die Meldung von der Shell stammen, welche vom make gestartet wird. Diese hat ggf. den GCC gar nicht gestartet (es steht was von fork!). Wenn das makefile danach als erstes das .d file einliest, geht das schief. c-hater schrieb: > Bleiben eigentlich nur noch irgendwelche Pfade oder sonstige Variablen > im Environment... Genau. Welche z.B. eine unpassende MSYS DLL enthält.
c-hater schrieb: > Verschiebe das ganze Projektverzeichnis mal in einen Pfad, der keine > Leerzeichen enthält und versuch' es dann noch einmal. Natürlich musst du > das Projekt von der neuen Position erneut öffnen und nicht das der IDE > bereits bekannte und im Open-Dialog gelistete! Der Pfad ist C:\Users\peter\Documents\beregnung Ich bekomme das einfach nicht zum laufen:(
Vimar schrieb: > Ich bekomme das einfach nicht zum laufen:( Das schon durchgearbeitet? Dr. Sommer schrieb: > Google kennt diese Fehlermeldung. > > Beitrag "WinAVR unter Windows 8.1 (64 bit)" > http://www.avrfreaks.net/forum/windows-81-compilation-error > https://forum.pololu.com/t/sync-with-child-child-died-before-initialization/5577/3
Dr. Sommer schrieb: > Das schon durchgearbeitet? > > Dr. Sommer schrieb: Ich habe es zumindest versucht aber kann schon sein das durch die ganze Diskussion etwas überlesen habe.....
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.