ich verwende ATmega32, WinAVR 20071221, AVRStudio 4.13, build557. Zur Fehlersuche habe ich die Optimierung von Os in O0 geändert. Nun erhalte ich die Warnung "Compiler optimizations disabled; functions from <util/delay.h> won't work as designed". Was ist die Ursache? Was müsste ich tun, um delay.h auch mit Optimierung O0 verwenden zu können? Wolf
Die Ursache steht in der Meldung: Ohne Optimierung funktionieren die _delay_XX-Funktionen nicht (zumindest nicht so, wie sie sollen)! Übrigens steht das auch in der Dokumentation der AVR-libc
Wolf wrote: > Was müsste ich tun, um delay.h auch mit Optimierung O0 verwenden zu > können? <util/delay.h> nicht benutzen. Du kannst die zu Grunde liegenden Basisfunktionen aus <util/delay_basic.h> noch benutzen, aber dann musst du dir die notwendigen Schleifenanzahlen mit der Hand berechnen. Genau darin liegt nämlich der Mehrwert der Funktionen in <util/delay.h>, aber auch der Grund, warum sie nur mit Optimierung funktionieren.
> Nun erhalte ich die Warnung "Compiler optimizations disabled; functions > from <util/delay.h> won't work as designed". > Was ist die Ursache? Na daß du die Optimierungen ausgeschaltet hast. > Was müsste ich tun, um delay.h auch mit Optimierung O0 verwenden zu > können? Verwenden kannst du sie damit schon, nur wird sehr viel mehr Flash-Speicher verbraucht und die Delays sind länger.
Hallo Johannes, danke, habe ich wohl gelesen. Meine Frage war, warum das so ist. Hast Du dafür eine Erklärung? Gruss Wolf
Der Grund ist, daß die Funktion eine Gleitkomma-Berechnung verwendet, um aus der angegebenen Millisekunden-Zahl zu errechnen, wie viele Schleifendruchläufe nötig sind. Ohne Optimierungen wird diese Berechnung zur Laufzeit durchgeführt, was viel Rechenzeit kostet und die Gleitkomma-Bibliothek benötigt. Mit eingeschalteter Optimierung wird die ganze Rechnung schon im Compiler durchgeführt.
Der Beitrag von Rolf beantwortet meine Frage. Da ich auf delay.h nicht verzichten möchte, muss ich wohl auf andere Art herausfinden, warum in einer Funktion die Zeile ebuffer[31]=0xFF wegoptimiert wird.
Wolf wrote: > ..., warum in einer Funktion die Zeile > > ebuffer[31]=0xFF > > wegoptimiert wird. Mit -O0 hättest du das sowieso nicht herausgefunden. ;-) Ansonsten lässt sich das nur ermitteln, wenn du uns mehr von deinem Code zeigst. Sowas kann z. B. wegoptimiert werden, wenn der Compiler erkennt, dass im Programmfluss danach ebuffer[31] noch mit einem anderen Wert belegt wurde und dass zwischenzeitlich (nach seiner Analyse) niemand eine Chance hatte, den Wert von ebuffer[31] zu benutzen.
hallo Jörg, werde versuchen, das herauszufinden. Enstweilen danke. Wolf
Bitte 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.