www.mikrocontroller.net

Forum: Compiler & IDEs Zeitverzögerung mit delay FALSCH


Autor: Hsus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Atmega Fans!

Ich benutze delay.h und Atmega 644 mit 16 MHz Quarz.
Ich weiß, dass delay.h eine begrenzung hat. Deswegen benutze ich die 
Schleife
for (i=1; i<=1000, i++)
{
_delay_ms(1);
}

In der delay.h habe ich F_CPU = 16000000UL angegeben.

Mit der oberen Schleife, müsste ich eine Verzögerung von 1s erreichen. 
Das ist aber nicht so, die Zeitverzögerung ist viel viel kleiner! Ich 
denke, dass sind etwa 100ms oder so...

Warum stimmt, die delay Funktion nicht?
Hat jemand schon das gleiche Problem gehabt?


Danke!

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> In der delay.h habe ich F_CPU = 16000000UL angegeben.

Davon abgesehen, daß das da nicht* hingehört, hast Du auch die Fuses des 
Controllers entsprechend gesetzt?


*) Nie, niemals verändert man zum Compiler gehörende Headerdateien.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da der Controller wahrscheinlich nicht mit 160 MHz läuft, kann es
nicht an den Fuses liegen.

Der gelistete Code kann aber nicht der gleiche sein, der auf dem
Controller läuft, da er einen Syntaxfehler enthält. Vielleicht enthält
der Originalcode einen anderen Fehler.

Deswegen immer Originaldateien posten oder copy-paste machen, aber
nicht den Code abtippen oder (noch schlimmer) aus dem Kopf eingeben.

Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
16 mit 6 Nullen sind doch 16 MHz oder nicht ?

Zwischenfrage am Rande: Muß man wirklich auch "UL" bei den defines 
angeben?

Autor: Michael H* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lutz wrote:
> 16 mit 6 Nullen sind doch 16 MHz oder nicht ?
ich komm auch auf 16mhz

> Zwischenfrage am Rande: Muß man wirklich auch "UL" bei den defines
> angeben?
mein make-file-editor sagt mir:
Do NOT tack on a 'UL' at the end, this will be done
automatically to create a 32-bit value in your source code.
außerdem sollte ein compiler auch selbst wissen, wie er variablen am 
dümmsten anlegt ^^

und meiner meinung nach am geschicktesten gehts so:
#ifndef F_CPU
   #define F_CPU 16000000
#endif

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Zwischenfrage am Rande: Muß man wirklich auch "UL" bei den defines
> angeben?

Ja, sonst ist das ein int. Und der kann auf einem 8/16-Bit-System wie 
dem AVR nicht andeutungsweise so groß werden.

Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mein make-file-editor sagt mir:
Do NOT tack on a 'UL' at the end, this will be done
automatically

Ja, sonst ist das ein int. Und der kann auf einem 8/16-Bit-System wie
dem AVR nicht andeutungsweise so groß werden.


Danke. Grundsätzlich sieht C es also nicht automatisch vor und man muß 
sich selbst drum kümmern, es kann einem aber natürlich preprozessor- 
oder compilerabhängig auch abgenommen werden. Wieder was wichtiges 
gelernt.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus t. Firefly wrote:

>> Zwischenfrage am Rande: Muß man wirklich auch "UL" bei den defines
>> angeben?

> Ja, sonst ist das ein int.

Nein, weil's da nicht reinpasst, aber es wäre ein (signed) long,
denn da passt die Zahl rein.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ja, sonst ist das ein int.

Nein.

> Und der kann auf einem 8/16-Bit-System wie dem AVR nicht
> andeutungsweise so groß werden.

Eben, und das merkt der Compiler und wählt deshalb automatisch long als 
Typ, so wie es die C-Norm vorschreibt.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na gut. Dann behaupte ich fortan munter das Gegenteil.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lutz schrieb:
> 16 mit 6 Nullen sind doch 16 MHz oder nicht ?

Michael H* schrieb:
> ich komm auch auf 16mhz

Falls das auf meine Aussage von oben

> Da der Controller wahrscheinlich nicht mit 160 MHz läuft, kann es
> nicht an den Fuses liegen.

bezogen sein sollte:

> F_CPU = 16000000UL

ist natürlich richtig, wenn tatsächlich ein 16MHz-Quarz verwendet
wird.

Hsus schreibt aber:

> Mit der oberen Schleife, müsste ich eine Verzögerung von 1s
> erreichen. Das ist aber nicht so, die Zeitverzögerung ist viel viel
> kleiner! Ich denke, dass sind etwa 100ms oder so...

Die Zeitverzögerung ist also um den Faktor 10 zu kurz. Bei korrekter
Software könnte dies nur durch einen um den Faktor 10 erhöhten
CPU-Takt erklärt werden. Da ein CPU-Takt von 16MHz*10 = 160MHz aber
praktisch unmöglich ist, ist auf jeden Fall ein Softwareproblem
vorhanden, das man erst beseitigen sollte, bevor man Fehler in den
Fuses sucht.

Der Softwarefehler kann von uns aber schlecht gefunden werden, weil
Hsus nicht seinen Originalcode gepostet hat. Nur falls es jemand noch
nicht entdeckt haben sollte: Das Komma nach der 1000 sollte ein
Semikolon sein.

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hatte das auch mal,

musste die optimierung beim compilieren anschalten, mindestens -O1 am 
besten aber sowieso -Os, dann gings bei mir, sogar vergleichsweise so 
genau wie mit einem timer...

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist natürlich richtig und wichtig, die Optimierung einzuschalten.
Allerdings ist das keine Erklärung für das beschriebene Phänomen: Das
Einschalten der Optimierung, falls es tatsächlich vergessen wurde,
würde die Delay-Schleife nicht langsamer (was gewünscht wird), sondern
noch viel schneller machen.

Autor: Hsus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei mir im Code stand es so:

#ifndef F_CPU
/* prevent compiler error by supplying a default */
# warning "F_CPU not defined for <util/delay.h>"
# define F_CPU 16000000UL
#endif

Komisch ist, dass zwischen # und define ein Leerzeichen ist, und define 
nicht in blau angezeigt ist.

Könnte das der Fehler sein? Ich habe das geändert und werde heute 
Nachmittag es ausprobieren und euch berichten.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hsus wrote:

> Bei mir im Code stand es so:

Nicht bei dir, sondern im Headerfile der Bibliothek.  Wie Rufus dir
schon im Beitrag "Re: Zeitverzögerung mit delay FALSCH" schrieb,
sind diese Dateien für dich erstmal tabu (zumindest, solange du noch
gar nicht verstehst, was du da tust, weil dir noch nichtmal die
Syntax wirklich klar ist).

> Komisch ist, dass zwischen # und define ein Leerzeichen ist,

Das dient der optischen Verdeutlichung dessen, was zum #if-Block
gehört, er ist gewissermaßen eingerückt.  Ein Leerzeichen zwischen
dem # und der eigentlichen Direktive ist ausdrücklich zulässig.

> und define
> nicht in blau angezeigt ist.

Das ist eine Macke deines Editors und hat mit dem C-Code nichts zu
tun.

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.