www.mikrocontroller.net

Forum: Compiler & IDEs Zeit die vergeht für diese Schleife???


Autor: stampfkern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
for (s = 0; s<65535; s++)
  {
    ;
  }

wie lange würde diese Schleife laufen bei 20MHz?

Autor: hams (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also so wies jetzt dasteht 0ms ;->

Autor: stampfkern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
soll heißen die auf addierung von ein auf s bis 65535 braucht keine 
zeit?

Autor: stampfkern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ist nur ein auszug.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.



Autor: stampfkern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
s ist unsigned int (mit 16 Bit)

for (s = 0; s<65534; s++)
  {
    ;
  }

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: stampfkern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: stampfkern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die delay.h hatte ich auch schon verbraucht aber mehr Speicher als wenn 
ich mein ganzes Progrämmchen unoptimiert kompiliere.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.


Autor: stampfkern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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++)
  {
    ;
  }

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: stampfkern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so danke mit dem Optimierungstipp die delay.h produziert jetzt keinen 
unnötigen Code mehr.

Autor: stampfkern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da war Karl Heinz wohl wieder mal schneller...

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)


Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.