AVR Studio WINAVR

42.

Vimar schrieb:
> Aber es wird mir
> kein Neues Hexfile generiert.

Dann muss es ja irgendwelche Fehlermeldungen geben.

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?

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

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?

Habe das Projekt mal eingestellt

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...

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...

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

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.

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.

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.....