Hallo Leute,
mir ist soeben ein seltsames Phonemen untergekommen:
Chip: Attiny85
Sprache/IDE: BASCOM
Programm, Holzklasse,:
$regfile = "ATtiny85.dat"
$crystal = 1000000
Config Portb.0 = Output
Do
Toggle Portb.0
Waitms 1000
Loop
End
Zum Problem:
Je höher ich die interne Kristallfrequenz definiere, desto langsamer
blinkt die LED - während bis ca. 50000Hz die LED-Blinkrate immer kleiner
wird. Ab dann diesem Grenzbereich dreht es sich wieder in Richtung des
Langsameren.
Hat dazu jemand eine Idee? Woran könnte das liegen?
Der Chip wird ohne externen Quarz und im Werkszustand genutzt.
Nette Grüße
Fabian
Mit der $crystal angabe gibst du an wie schnell der tiny läuft und nicht
wie schnell er laufen soll. Wenn du also 5000000 schreibst obwohl du den
internen 1MHz Quartz nutzt wartet der Tiny 5 Mal so lange
Matze schrieb:> Mit der $crystal angabe gibst du an wie schnell der tiny läuft
Da sollte man wohl besser sagen: "... wie schnell der tiny angeblich
läuft."
Für die tatsächlichen Taktfrequenz des Tiny ist die Angabe völlig
bedeutungslos. Die Angabe ist eine Berechnungsgrundlage für Zeiten im
Programm.
Verstehe, vielen Dank Leute.
Bin zwar auch an der UNI diverse Male mit der hardwarenahen
Programmierung in Kontakt gestoßen, nur habe ich mir bis dato nie
wirklich einen Gedanken um genau jene Definition gemacht. Dabei spielt
es keine Rolle, ob in C oder BASCOM. Man hat es einfach so hingenommen
:)
Ich wünsche schonmal ein schönes Wochenende.
Fabian schrieb:> Je höher ich die interne Kristallfrequenz definiere, desto langsamer> blinkt die LED
Wenn du die doppelte Quarzfrequenz angibst, wartet waitms auch doppelt
soviele Taktzyklen lang - logisch. Das stimmt natürlich nur, wenn
$crystal die tatsächliche Frequenz angibt. Das ist nur eine Konstante
für die Zeitberechnungen und hat auf den Quarz natürlich keinen
Einfluss.
Georg
georg schrieb:> und hat auf den Quarz natürlich keinen Einfluss.
Quarz ist hier nicht gefragt!
Fabian schrieb:> Der Chip wird ohne externen Quarz und im Werkszustand genutzt.
Also dürfte die Angabe von 1MHz im Programm goldrichtig sein.
Fabian schrieb:> Man hat es einfach so hingenommen :)
Du machst mir Angst!
Arduino Fanboy D. schrieb:> Also dürfte die Angabe von 1MHz im Programm goldrichtig sein.
Ok, dann existiert das Problem mit der langsamer blinkenden LED also
garnicht. Fall gelöst.
Georg
georg schrieb:> Ok, dann existiert das Problem mit der langsamer blinkenden LED also> garnicht. Fall gelöst.
Richtig!
Das ist nur ein künstliches Problem, welches auf einer
DokuLeseVerweigerung beruht.
Wenn die Einstellung, so wie im Eingangsposting, bleibt....
Dann ist alles gut.
Sofern es gestattet ist, würde ich dann doch noch eine Verständnisfrage
loswerden.
Die BASCOM-Dokumention liefert zum Befehl "wait" leider keine
Hintergrundinformationen, daher mein Gedankengang:
- Je höher die Taktfrequenz für das Programm mit §crystal gewählt wird,
desto kürzer läuft das Programm durch (also in der internen
Verarbeitung), oder anders ausgedrückt: desto schneller arbeitet der
Chip.
- Es hat sich gezeigt, dass "waitms" (oder von mir aus auch bloß "wait")
ausschließlich halbwegs exakte Werte für die Frequenz 1MHz liefert.
- Verdoppelt man die Eingabe auf meinetwegen 2MHz, blinkt die LED nun
auch mit einer halb so großen Frequenz.
- Zur Frage: Ist der "wait"-Befehl nicht dazu da, auch bei von
1Mhz-abweichenden Frequenzen stets eine zumindest halbwegs korrekte
Ablauf-Verzögerung im Bereich der angegebenen Millisekunden zu liefern?
Gemäß dem Fall, dass ein 16Mhz-Quarz an den µC angeschlossen wird, wäre
dann die LED-Blinkrate um das 16-fache größer (?)
Achso: @Arduino Fanboy D., danke für die kühne Unterstellung, die ist
aber nicht wahr :)
Arduino Fanboy D. schrieb:> Das ist nur ein künstliches Problem, welches auf einer> DokuLeseVerweigerung beruht.
Bitte nicht noch zusätzlich auf das Thema "Wait" nicht nehmen, "da
unsauber", oder "weil andere Methoden besser" etc. eingehen ;-)
Fabian schrieb:> - Zur Frage: Ist der "wait"-Befehl nicht dazu da, auch bei von> 1Mhz-abweichenden Frequenzen stets eine zumindest halbwegs korrekte> Ablauf-Verzögerung im Bereich der angegebenen Millisekunden zu liefern?
Ja!
Der WAIT Befehl wartet eine bestimmte Zeit, unabhängig welche Takt
Frequenz die CPU hat.
Aber!
Der Compiler muss WISSEN, welche CPU du verwendest und wie die getaktet
ist.
Und das teilst du im Sourcecode mit ...
Erklärung:
Jeder Befehl der CPU dauert eine bestimmte Zeit.
WAIT führt nur die richtige Anzahl an Befehle aus, um die Zeit zu
erreichen.
Eine schneller getaktete CPU muss weniger Befehle ausführen, um dieselbe
Wartezeit zu erreichen.
Mir scheint, du irrst.
Fabian schrieb:> Je höher die Taktfrequenz für das Programm mit §crystal gewählt wird,
Du kannst die Taktfrequenz nicht so bestimmen.
Bei AVR wird der Takt per Fuses ( plus dem evtl vorhandene Quarz)
festgelegt.
Im Programm, kannst du dann noch den Prescaler einstellen.
Die so generierte Frequenz, musst du in deiner $crystal Variable
eintragen.
Fabian schrieb:> - Es hat sich gezeigt, dass "waitms" (oder von mir aus auch bloß "wait")> ausschließlich halbwegs exakte Werte für die Frequenz 1MHz liefert.
Das ist vollkommen richtig!
Denn wenn der µC mit internem 1MHz läuft, macht es keinen Sinn da im
Programm was anderes einzustellen.
Nein, es wäre sogar dumm.
Fabian schrieb:> - Zur Frage: Ist der "wait"-Befehl nicht dazu da, auch bei von> 1Mhz-abweichenden Frequenzen stets eine zumindest halbwegs korrekte> Ablauf-Verzögerung im Bereich der angegebenen Millisekunden zu liefern?
Richtig!
Dafür ist die Variable $crystal zuständig!
Hier teilst du dem Programm die Taktfrequenz des Prozessors mit.
Fabian schrieb:> Gemäß dem Fall, dass ein 16Mhz-Quarz an den µC angeschlossen wird, wäre> dann die LED-Blinkrate um das 16-fache größer (?)
Nur wenn $crystal auf 1MHz stehen bleibt.
Das wäre aber dumm.
Fabian schrieb:> Achso: @Arduino Fanboy D., danke für die kühne Unterstellung, die ist> aber nicht wahr :)
Natürlich ist das Wahr!
Bisher meinst du noch, man könnte mit $crystal die Taktfrequenz
manipulieren.
Das ist ein Irrtum.
Und auf diesem Irrtum beruht dein Problem.
Irrtum weg, Problem weg.
Fabian schrieb:> - Verdoppelt man die Eingabe auf meinetwegen 2MHz, blinkt die LED nun> auch mit einer halb so großen Frequenz.
Das muß auch so sein.
Denn Du hast ja die Frequenz nicht geändert, der MC läuft weiterhin mit
1MHz. Allerdings hast Du den Compiler angelogen, indem Du ihm sagst, der
MC liefe mit 2MHz. Der Compiler ist also völlig unschuldig.
Stelle mal den MC auf externen Quarz um und schließe eine Quarzfassung
an.
Dann sage dem Compiler, der Takt beträgt 5MHz und stecke gleichzeitig
einen 5MHz Quarz in die Fassung.
Ergebnis: 1s dauert 1s.
Nun sage dem Compiler, der Takt beträgt 8MHz und stecke gleichzeitig
einen 8MHz Quarz in die Fassung.
Ergebnis: 1s dauert immer noch 1s.
Der Compiler kann nicht ablesen, was auf dem Quarz aufgedruckt ist, das
mußt Du tun.
Solange Du den Compiler nicht anlügst, ist alles in Butter.
Fabian schrieb:> Achso: @Arduino Fanboy D., danke für die kühne Unterstellung, die ist> aber nicht wahr :)>> Arduino Fanboy D. schrieb:>> Das ist nur ein künstliches Problem, welches auf einer>> DokuLeseVerweigerung beruht.https://avrhelp.mcselec.com/index.html?crystal_1.htm
Hier ist genau dein Problem beschrieben!
Dein µC und dein Programm verhält sich exakt so, wie spezifiziert
Eine lange und schwere Geburt!
Vielen Dank für eure Mühe. Der Groschen, der nun gefallen ist, wog
wahrscheinlich ´ne Tonne ;-)
Hätte ich gleich in der BASCOM-Hilfe mal unter dem $Crystal nachgeschaut
und nicht in wait etc....
[SOLVED]
Dann nun nochmal: ein schönes Wochenende euch :)
