Hallo ihr Lieben, ich habe gerade ein kleines Problem mit WinAVR. Von jetzt auf gleich macht ein Programm auf dem Atmega8535 nicht mehr das gleiche. Bevor der Fehler aufgetreten ist, ließ sich alles einwandfrei compileren und auf den Atmega8535 spielen. Doch dann beim nächsten Mal macht der Atmega nicht mehr das, was er vorher gemacht, ohne, dass etwas an dem Programm geändert wurde. Dennoch lässt es sich ohne Fehler compilieren. Wenn ich eine ältere Hex-file nehme, die vom Quelltext genauso ist, funktioniert es. Compiliere ich das Programm neu, funktioniert es nicht mehr. Ich habe nichts an den Einstellungen geändert, nichts im Quelltext verändert. Ich habe WinAVR schon neu installiert. Ich habe AVRStudio 4 schon neu installiert. Immernoch der gleiche Fehler. Habt ihr noch einen Rat? Vielen Dank :)
Der Fehler ist im Makefile, Zeile 142.
Arsch N. schrieb: > Habt ihr noch einen Rat? Ja. Ganz wirklich offen zeigen was du hast. Sonst bekommst du Hinweise dass in Zeile 42 deiner Source ein Fehler ist. Zweiter Rat: Einmal alle *.o Files in deinem Projektverzeichnis löschen und das Projekt komplett neu "builden". Dann könnten zumindest Warnings auftauchen die einen misstrauisch machen sollten.
Frickelfritze schrieb: > Arsch N. schrieb: >> Habt ihr noch einen Rat? > > Ja. > > Ganz wirklich offen zeigen was du hast. > Sonst bekommst du Hinweise dass in Zeile 42 deiner Source > ein Fehler ist. > > Zweiter Rat: > > Einmal alle *.o Files in deinem Projektverzeichnis löschen > und das Projekt komplett neu "builden". Dann könnten > zumindest Warnings auftauchen die einen misstrauisch machen > sollten. *.o Files löschen habe ich auch schon probiert. Was benötigst du denn? Was soll ich hochladen?
Arsch N. schrieb: > *.o Files löschen habe ich auch schon probiert. Und? Bekommst du dann Warnings beim übersetzen? Wenn du so weiter machst und dir jeden Popel einzeln aus der Nase ziehen lässt wird das nichts.
Frickelfritze schrieb: > Arsch N. schrieb: >> *.o Files löschen habe ich auch schon probiert. > > Und? Bekommst du dann Warnings beim übersetzen? > > Wenn du so weiter machst und dir jeden Popel einzeln aus der > Nase ziehen lässt wird das nichts. Ich bekomm keine Warnings. Alles wie vorher. Ich habe vorher mit -O2 compiliert. Das lief auch immer, bis auf den einen Moment, wo es nicht mehr ging. Stell ich die Optimierung nun auf -O0 dann klappt es wieder. Was möchtest soll ich denn hochladen? Benötigst du C-Files? Das Makefile?
Arsch N. schrieb: > Stell ich die Optimierung nun auf -O0 dann klappt es wieder. Dann wirst du vom Compiler eine oder mehrere Variablen wegoptimiert bekommen was dazu führt dass eine Variable im Interrupt-Kontext andere Werte annimmt als im Nicht-Interrupt-Kontext. Stichwort: volatile
Das Problem besteht nach wie vor. An einem anderen Rechner funktioniert es. Dort kann das Programm einwandfrei übertragen und ausgeführt werden. Ich frag nochmal. Was soll ich hochladen?
Arsch N. schrieb: > Das Problem besteht nach wie vor. An einem anderen Rechner funktioniert > es. Dort kann das Programm einwandfrei übertragen und ausgeführt werden. dann vergleiche doch mal das hex file. Dann vergleiche die gcc Version. > Was soll ich hochladen? alles was du hast.
Ich versteh es nicht. Ich habe nichts verändert. Von jetzt auf gleich geht einfach nichts mehr. Keine Kommentare über die Programmierung. Ich habe das nicht entwickelt. Ich soll es nur weitere betreuen. "Wieos fragst du dann nicht denjenigen der es entwickelt hat, wo der Fehler liegt?" Der ist nicht mehr da.
Arsch N. schrieb: > Ich versteh es nicht. Ich habe nichts verändert. Von jetzt auf gleich > geht einfach nichts mehr. Heute war Update-Tag bei Windows. Vielleicht hat das solche wilden Auswirkungen auf das Programm. MfG Paul
Nach
1 | //#include <avr/signal.h>
|
kommt immer noch
1 | ESJOG_3b_V_1.0.c:267:8: error: attempt to use poisoned "SIG_INTERRUPT0" |
Dies wird doch schon seit Ewigkeiten vom avr-gcc bemängelt.
Bssss.
1 | warning: #warning "F_CPU not defined for <util/delay.h>" |
Hameg schrieb: > Dies wird doch schon seit Ewigkeiten vom avr-gcc bemängelt. Naja, aber mit seinem jungsteinzeitlichen WinAVR von 2010 gerade noch nicht. Seltsam ist es schon, warum angeblich ohne jegliche Veränderungen sich das Verhalten des Compilers ändern sollte. Einzige Erklärung dafür wäre, dass der Compiler oder Assembler auf der Platte „einen Schuss bekommen“ hat. Dagegen würde natürlich eine erneute Installation dieser alten Toolchain helfen, jedoch hilft es nicht, wenn wir hier den Code irgendwo offline compilieren – dass das funktioniert, hat er ja selbst schon bestätigt („auf einem anderen Computer geht alles“).
Vielleicht parallel eine neuere/andere Version installiert, die nun unbeabsichtigt gefunden wird?
Steffen R. schrieb: > Vielleicht parallel eine neuere/andere Version installiert, die nun > unbeabsichtigt gefunden wird? Die würde vermutlich das SIG_INTERRUPT0 monieren. ;-)
Jörg W. schrieb: > Die würde vermutlich das SIG_INTERRUPT0 monieren. ;-) das fehlende F_CPU klingt aber auch merkwüdig
Arsch N. schrieb: > Ich bekomm keine Warnings. Alles wie vorher. Ich habe vorher mit -O2 > compiliert. Das lief auch immer, bis auf den einen Moment, wo es nicht > mehr ging. Stell ich die Optimierung nun auf -O0 dann klappt es wieder. Nimm mal -Os. Kann auch sein, dass bei -O2 zuviel RAM genutzt wird und nichts mehr für den Stack übrigbleibt. Sinnvoll wären auch mal die avr-gcc-Kommandos, die generiert werden, zu zeigen und auf beiden Windows-Rechnern zu vergleichen. P.S. Ja, man kann die ausgeführten Kommandos per Copy&Paste als reinen Text kopieren.
Vielleicht ist Dein Path zu lang. Viele Installationen tragen da allen unmöglichen Schrunz ein, der oft nichtmal benötigt wird. Ändern kannst Du ihn unter "Umgebungsvariablen".
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.