Guten Morgen,
kurze Frage: wenn ich eine delay Funktion in meinem makefile habe und
diese sich auf die CPU Frequenz bezieht.
was passiert wenn ich jetzt eine LED blinken lasse mit 0,5 Hz und im
makefile die CPU Frequenz halbiere ?
- ist die LED Frequenz dann wirklich doppelt so groß, wenn ja warum?
und was passiert wenn ich im AVR - Studio die Frequenz halbiere, dann
hab ich ja die Hardware geändert, läuft die LED dann auch wieder mit der
doppelten Frequenz ?
Wäre echt super wenn ihr mir helfen könntet, bin grade echt verwirrt
davon
Gruß Tom
Tomus schrieb:> - ist die LED Frequenz dann wirklich doppelt so groß, wenn ja warum?
Weil du dem Compiler "vorgelogen" hast, einen halb so schnellen Takt
verwenden zu wollen. Das tust du aber nicht...
> was passiert wenn ich im AVR - Studio die Frequenz halbiere, dann hab> ich ja die Hardware geändert, läuft die LED dann auch wieder mit der> doppelten Frequenz ?
Ja, Grund siehe oben.
> Wäre echt super wenn ihr mir helfen könntet
Du solltest dem Compiler die Frequenz angeben, die du tatsächlich
verwendest. Sonst geht der von falschen Annahmen aus und berechnet Werte
falsch.
die Delay Funktion wartet intern keine Zeit sondern CPU-Takte. Die Zeit
die du als Parameter übergibst, wird vom Compiler in Takte umgerechnet.
Damit sollte klar sein, wenn die Takte schneller oder langsamer sind,
was dann mit der Delay Funktion passiert.
aber dann müsste doch die Frequenz doch halb so groß sein, da ja mehr
takte zum erreichen der gegebenen Zahl im Delay benötigt werden?
Oder täusch ich mich da?
Es besteht ja durchaus die Möglichkeit, dass die Frage ernst gemeint
ist, aber um Dich von einem Troll hinreichend abzuheben, wäre es
hilfreich, wenn Du
1. Eigene Versuche anstellst die Frage zu beantworten und diese
dokumentierst. Im Grunde äusserst simpel, falls Du mal versuchst von
Hand und auf dem Papier nachzuvollziehen in welcher Weise das delay
realisisiert wird.
2. Deine Ansicht begründest, in welcher Weise Du die Hardware änderst,
falls Du im AVRStudio "die Frequenz halbierst".
Tomus schrieb:> aber dann müsste doch die Frequenz doch halb so groß sein, da ja mehr> takte zum erreichen der gegebenen Zahl im Delay benötigt werden?
Wenn du dem Compiler die halbe Frequenz vorgaugelst, dann macht er für
eine gegebene Zeit halb so viele Takte zum Warten einer gegebenen Zeit.
Tatsächlich hast du aber eine höhere Taktfrequenz, somit ist die
Wartezeit schneller vorbei, denn an der Anzahl Takten, die er wartet,
ändert sich ja nichts.
Tomus schrieb:> aber dann müsste doch die Frequenz doch halb so groß sein, da ja mehr> takte zum erreichen der gegebenen Zahl im Delay benötigt werden?> Oder täusch ich mich da?
Denk nochmal nach. Wenn du dem Compiler sagst:
1. Taktfrequenz ist 10 MHz.
2. Warte eine Sekunde.
Dann rechnet der Compiler aus: 10000000 Takte warten.
Wenn du ihm sagst:
1. Taktfrequenz ist 5 MHz.
2. Warte eine Sekunde.
Dann wartet er 5000000 Takte.
Und wenn du diesen Controller dann aber trotzdem mit 10MHz betreibst,
dann ist er schon in der halben Zeit mit warten fertig. Er ist also
doppelt so schnell, du hast ihn mit 10MHz statt 5MHz quasi
"übertaktet"...
Hi,
es geht hier also um 2 Sachen :
1) wie schnell läuft der Mikrokontroller wirklich
2) von welcher Geschwindigkeit des Mikrokontrollers geht die Software
aus
Punkt 1 lässt sich nur durch ändern der Konfiguration der Takterzeugung
(irgendwelche Slow Modes zähle ich jetzt der Einfachheit halber dazu),
bzw. durch Austausch des Quarzes ändern. Dies dürfte mehr als das ändern
eines Defines oder ein paar Klicks in der IDE erfordern.
Punkt 2 ist schon eher in einem Define festgelegt, bzw. übergibt die IDE
dem Compiler ein Define mit dem bei ihr eingestellten Wert.
Ist dieser Wert zu hoch, läuft alles langsamer. Ist der Wert zu niedrig
läuft alles schneller.
Klar, denn delay() macht an diesem Wert fest, wieviele zu nichts anderem
nützende Befehle es abarbeiten lassen muß, bis die Zeit um ist. Gaukelst
Du nun dem Code vor Du hättest einen schnellen Mikrokontroller, sind es
mehr Befehle. Hast Du aber in Wirklichkeit gar keinen so schnellen
Mikrokontroller dauerts eben länger als geplant.
Um einen Knoten im Gehirn zu vermeiden, stellt man hier jedoch den
richtigen Wert ein und legt sich ein weiteres Define für die
Blinkgeschwindigkeit an.
Und irgendwann ist man auch so weit, dass die Software die Zeit besser
nutzt, als nur auf die nächste Flanke des Blinkens zu warten.
Im zweifelsfall schaue ich mir oft den Assembler-Code an, den der
Compiler erzeugtn hat.
Ich bin zwar kein Experte in Assembler, aber zumindest kann ich den
erzeugten Code lesen und verstehen. Das lernst man in wenigen Stunden
und ist gelegentlich hilfreich.
Falls du ein kleines bisschen AVR Assembler lernen möchtest, schau Dir
mein Tutorial an: http://stefanfrings.de/avr_workshop/index.html
Als C Programmierer muss man kein Assembler können, manchmal hilft es
aber. Eben weil C in Assembler übersetzt wird.
