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.
:
Bearbeitet durch User
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 :)
Thread beobachten
Seitenaufteilung abschaltenBitte 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.