for (s = 0; s<65535; s++) { ; } wie lange würde diese Schleife laufen bei 20MHz?
soll heißen die auf addierung von ein auf s bis 65535 braucht keine zeit?
Fall 1: s ist long Soll heissen, dass jeder Compiler, der etwas auf sich hält, diese Schleife komplett rausschmeist und durch die Zuweisung s = 65536; ersetzt Fall 2: s ist int Dann gibt es eine Warnung da 65535 nicht mehr in einen int passt (*) In allen Fällen ist natürlich angenommen, dass s nicht volatile ist.
Nein, aber der Compiler wird sowas vermutlich wegoptimieren ;) @Karl-Heinz: Zu deinem dritten Fall: Die Schleife bricht schon bei s = 65535 ab. Das passt aber in einen unsigned int.
Simon Küppers wrote: > Nein, aber der Compiler wird sowas vermutlich wegoptimieren ;) > > @Karl-Heinz: > > Zu deinem dritten Fall: Die Schleife bricht schon bei s = 65535 ab. Das > passt aber in einen unsigned int. Habs gemerkt :-) Du hast aber schneller geantwortet als ich das Posting berichtigen konnte. Er hat ja <65535, das geht im Falle unsigned int.
s ist unsigned int (mit 16 Bit) for (s = 0; s<65534; s++) { ; }
Immer noch das gleiche Problem: Ein normaler Optimierer wird diese Schleife rauswerfen, da sie nichts tut, ausser Zeit zu verbraten. Aufgabe eines Optimierers ist es nun mal ein Programm soweit zu optimieren, dass möglichst wenig Zeit verbraten wird. Die obige Schleife ist ein gefundenes Fressen für jeden Optimierer. Was willst du eigentlich bezwecken?
Wenn es dir nur darum geht eine (kurze) Zeitspanne zu warten, dann benutze die Funktionen in delay.h: _delay_ms() _delay_us() Lies aber unbedingt die Doku dazu durch (in delay.h). Es gibt Grenzen für die zu wartenden Zeitspannen.
und was dann? Nutze AVR Studio. Optimierung beim Code ist aus -O0. Wollte eigentlich nur wissen wieviel Zeit für die Schleife gebraucht wird das mit den 65534 war mein Fehler max dafür wäre ja (2 hoch 16) minus 2 gewesen. Danke! In AVR Studio läuft die Schleife braucht aber sehr lang bis wieder etwas anders getan wird. (der AVR soll mit 20 MHz laufen) Danke übrigens für die schnellen antworten.
die delay.h hatte ich auch schon verbraucht aber mehr Speicher als wenn ich mein ganzes Progrämmchen unoptimiert kompiliere.
stampfkern wrote: > In AVR Studio läuft die Schleife braucht aber sehr lang bis wieder etwas > anders getan wird. (der AVR soll mit 20 MHz laufen) Das kann viele Ursachen haben. Wie bereits gesagt: Für ein halbwegs genaues Timing und kurze Wartezeiten kann man die Funktionen aus delay.h benutzen. Oder aber man geht gleich auf einen Timer. Die meisten Programme bauen sowieso rund um einen Timer für den Basistakt des Programmes auf.
stampfkern wrote: > die delay.h hatte ich auch schon verbraucht aber mehr Speicher als wenn > ich mein ganzes Progrämmchen unoptimiert kompiliere. Das kann nicht sein. Wenn der Optimizer eingeschaltet ist, dann sind da ein paar bytes mehr drinn. Nichts dramatisches. Wenn du mit den delay.h Funktionen einen enormen Speicherverbrauch feststellst, dann hast du ganz einfach keinen Optimizer eingeschaltet. Der Grund dafür: In der Berechnung der Schleifenzahl in den delay Funktionen kommen Floating Point Ausdrücke vor. Bei eingeschaltetem Optimizer werden die vom Optimizer wegoptimiert. Nur wenn der Optimizer ausgeschaltet ist, dann bleiben die übrig und sorgen dafür, dass auch gleich noch die halbe Floating Point Library mit ins Boot kommt. Ganz abgesehen davon, dass dann auch die Zeiten nicht stimmen :-) delay.h -> Optimizer einschalten.
okay werde es nochmal mit delay.h versuchen. Trotzdem würde ich gerne wissen wieviele Taktzyklen die For Schleife pro Durchlauf braucht wenn s eine uint16_t ist. for (s = 0; s<1; s++) { ; }
stampfkern wrote: > okay werde es nochmal mit delay.h versuchen. > > Trotzdem würde ich gerne wissen wieviele Taktzyklen die For Schleife pro > Durchlauf braucht wenn s eine uint16_t ist. > > for (s = 0; s<1; s++) > { > ; > } Es gibt nur eine Möglichkeit das herauszufinden: Du lässt dir ein Assembler Listing vom Compiler erzeugen und zählst die Takte nach. * Bei jedem Compilerupdate * Bei unterschiedlichen Optimizereinstellungen kann und wird sich diese Anzahl aber verändern.
so danke mit dem Optimierungstipp die delay.h produziert jetzt keinen unnötigen Code mehr.
ja danke auf die Assembleridee hätte ich auch kommen können. Habs jetzt mit delay.h erfolgreich und auch platzsparend gemacht die -Os hat wirklich geholfen der code ist jetzt nochmal 0.3 prozent kleiner. Danke vielmals
Das hängt vom Compiler (inklusive dessen Version) und den Optimierungseinstellungen ab. Wenn du's unbedingt wissen mußt, schau dir den generierten Assembler-Code an und zähl die Taktzyklen zusammen. > die delay.h hatte ich auch schon verbraucht Hm? > aber mehr Speicher als wenn ich mein ganzes Progrämmchen unoptimiert > kompiliere. Den Satz zu parsen hat bei mir wegen des fehlenden Kommas etwas gedauert.
Rolf Magnus wrote: > Den Satz zu parsen hat bei mir wegen des fehlenden Kommas etwas > gedauert. > > Da war Karl Heinz wohl wieder mal schneller... Ich benutze einen heuristischen Parser :-)
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.