|
Anzeige
|
Optimierung mit O0: Warnung bezüglich delay.h
Gast
#760846
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.
Gast
#760867
> 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.
Gast
#760868
Hallo Johannes, danke, habe ich wohl gelesen. Meine Frage war, warum das so ist. Hast Du dafür eine Erklärung? Gruss Wolf
Gast
#760874
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.
Gast
#760893
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.
Gast
#761211
hallo Jörg, werde versuchen, das herauszufinden. Enstweilen danke. Wolf Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
